Skip to main content
VeriFactu

VeriFactu error 2004: your record's timestamp is ahead of the AEAT clock

Every invoicing record carries the exact moment it was generated, with its time zone. The AEAT, the Spanish tax agency, compares it with the time on its own systems and, if yours comes from the future beyond a margin, answers with 2004. It is one of the few errors the AEAT accepts without asking for a correction, but it says something about your server.

FlexigoTech · Editor in charge: Víctor Gómez · Updated 4 November 2026

Key facts

Module
VeriFactu
Versions
Odoo 17, 18, 19 and 20
Checked
in the module's source code, version 20.0 · against the sources linked at the end
Reading time
3 min

The field and what the AEAT checks

The field is called FechaHoraHusoGenRegistro and stores the date, time and time zone of the moment the system generated the record, in the form YYYY-MM-DDThh:mm:ss plus the UTC offset. The AEAT validation document says it must be lower than or equal to the date on the AEAT system, allowing a margin of error. If it goes beyond that, the AEAT returns a warning without rejection.

The text of 2004 in the AEAT list is El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: and it stops right there: the list does not publish how many seconds or minutes that margin is.

Card for code 2004 and codes 1243, 1244 and 1268
Code 2004, in blue because the AEAT accepts the record, and the three codes for the same field that do reject it, in amber.

The four codes for this field

CodeAEAT text, in shortEffect
2004Date and time must be the AEAT's current time, with a margin.Accepted; the AEAT does not ask for a correction.
1243Error técnico al obtener el cálculo de la fecha del huso horario.Rejects the record because of an AEAT technical fault.
1244El campo FechaHoraHusoGenRegistro tiene un formato incorrecto.Rejects the record: wrong format.
1268La longitud del campo FechaHoraHusoGenRegistro no cumple con las especificaciones.Rejects the record: wrong length.

In its list of admissible errors, the AEAT marks this case as one of the two that do not need a correction. The other one is an empty ClaveRegimen with the IPSI tax.

Where Odoo takes the time from

The module takes the moment it generated the invoicing record, when the invoice was posted, with its UTC offset. That moment is stored and cannot be changed afterwards, just like the hash, because it is part of what gets chained. The module always builds the format the same way, so a 1244 or a 1268 should not appear with a submission from our module: if you see one, send it to us.

For 2004, the question is whether the Odoo server clock was running fast when the invoice was posted. The module has a cron, Verifactu: Clock Drift Check, that every 1 hour compares Odoo's time with the time of its PostgreSQL database, and a button to do it whenever you want. It does not compare with any outside clock: if Odoo and the database run on the same machine, or both run fast, it gives no warning. The real time is checked against an NTP server.

Chain state in Odoo with the Verify Integrity and Check Clock Drift buttons
In Chain State you have both buttons: Verify Integrity and Check Clock Drift, the one that compares Odoo's time with the database's. Odoo 20 screenshot with demo data.

What to do in each case

  • With a 2004, nothing about the invoice: it is registered. Ask whoever manages the server to compare its time with an NTP server and synchronise it if it runs fast. Check Clock Drift does not help here: it only compares Odoo with its database.
  • With a 1243, wait: it is a technical error on the AEAT side and the queue already retries on its own, with waits from 2 minutes to 12 hours, until the sixth attempt.
  • With a 1244 or a 1268, write to comercial@flexigobe.com with the submission's answer.

In Odoo, a 2004 leaves the record as «Aceptado con errores (subsanar)», the same label as every 2xxx code. For this particular code the AEAT says no correction is needed: you can leave it as it is.

Does a clock that runs slow cause an error?

The AEAT rule only checks whether your time is greater than theirs plus the margin. A record whose time is behind does not trip this check.

Keep reading

VeriFactu error 2000: the AEAT recalculates your hash and it does not matchVeriFactu error 2000: the Spanish tax agency recalculates the SHA-256 hash and gets a different one. Why the invoice is registered anyway and what to do in Odoo 17 to 20.VeriFactu error 2007: the AEAT already had your invoices and receives another «first record»VeriFactu error 2007: the AEAT already has invoices from your tax ID made with the same system and gets another first record. Why, in Odoo 17 to 20.VeriFactu technical errors: when the problem is in the AEAT systemsVeriFactu technical errors on the AEAT side (4108, 4110, 4111, 4118, 4128, 3500, 3501, 1129, 1256, 1288): which ones Odoo retries on its own and which ones you resend.
Checked in the module's source code (version 20.0) and the linked sources

Sources