Error 2004 en VeriFactu: FechaHoraHusoGenRegistro fuera de sincronización
 

Hola a todos,

Estoy teniendo dificultades con el siguiente error de validación por parte de la AEAT:

2004 - El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 240 segundos.

Contexto de la implementación:
- Es un sistema C# .NET
- Utilizamos un sistema encolado que envía los registros cada 60 segundos, y en el caso concreto que generó este error, el envío al WebService ocurrió solo unos segundos después.
- El valor de `FechaHoraHusoGenRegistro` se genera justo en el momento de la creación del registro
- El valor enviado tenía este formato (ISO 8601 con zona horaria): 2025-06-18T12:51:58+02:00

Según la documentación official:
Dudas:
1. ¿Debemos enviar siempre la hora exacta del momento del envío a AEAT y no la del momento de creación del registro?
2. ¿Es más seguro convertir la hora a UTC (`+00:00`) para evitar malinterpretaciones con el huso horario?
3. ¿Alguien ha solucionado este error sincronizando el servidor NTP o ajustando manualmente el margen?

Agradezco cualquier sugerencia o experiencia relacionada con este problema

Gracias por adelantado

Casualmente, ese es el único error que se excepciona de ser subsanado.


De todas maneras, estaría bien saber porque te da. En el ejemplo que pones, el registro se crea a las 12:51:58. ¿realmente no era esa hora? ¿la hora del pc estaba atrasada o adelantada? Porque sino no debería darte.

Gracias por tu respuesta, justo por eso me desconcierta más este error.

La hora del sistema es totalmente correcta. El valor de FechaHoraHusoGenRegistro era:
2025-06-18T12:51:58+02:00
y fue generado literalmente segundos antes de ser enviado a la AEAT (mi sistema tiene una cola que lo transmite automáticamente en menos de 10 segundos).

Lo que más me confunde es la diferencia entre:

vs.

Lo que dice la documentación técnica, es decir:

y también:

Así que no me queda claro si:

el WebService realmente respeta el huso horario informado (como +02:00)

o si internamente espera que se le envíe el valor en UTC (con sufijo Z) o huso horario +1:00.

Estoy considerando hacer una prueba forzando UtcNow con zona Z para descartar eso, pero no me parece consistente con lo que la documentación dice.

¿A ti te ha pasado algo parecido? ¿Tienes idea de cómo lo interpreta realmente la AEAT?

Revisa si en este hilo encuentras alguna información que pueda ayudarte.

https://www.clubdelphi.com/foros/showthread.php?t=97445

Es raro ese error nunca me ha dado sin haber xometido un error en la programación del control de flujos.
Revisa que la hora de tu sistema esté correctamente sincronizada con un servicio fiable. Algunos servicios de sincronizacion juegan malas pasadas y te ponen horas +-2 horas de diferencia en tu sistema. Supongo que además la hora que has puesto no le habrás quitado las 2 horas, que es una función que te la tal que así.

Hola, ese error en c# se origina al enviarle el DateTime, incluye los milisegundos, hemos posteado bastante al respecto, revisa lo.


Esto quita los milisegundos.

Si es cierto lo que puso en el primer post y el XML realmente llevaba el valor que dice, lo tiene bien (y siempre que realmente fuese esa hora, claro... que también confirmó que si):



Por ejemplo, este es el último registro que envié hoy, llevaba este valor y entró sin problemas:

2025-06-18T18:08:09+02:00

Si tienes el registro de la respuesta se puede analizar y si eso es así se lo puedes mandar a verifactu que miren donde tienen el problema

A mí este error me sale cuando tengo un número grande de facturas para subir (p.e. 300) y el tiempo entre la primera y la última es mayor de los famosos 240 segundos, así que he tenido que hacer "paquetes" de hasta 180 segundos, dedicar el minuto restante a generar el xml con las facturas, subirlo y recoger la respuesta.


Y a partir de ahí esperar hasta el siguiente ciclo.

Error
 

Si da este error como se subsana ?

No se subsana.