Lo que la AEAT ha cambiado en su documentación técnica desde diciembre

La norma de VeriFactu lleva sin cambiar desde diciembre de 2025. La documentación técnica sobre la que trabaja tu programa, en cambio, se mueve por su cuenta, va por versiones y no aparece en ningún boletín oficial.

El documento de validaciones y errores es el archivo en el que la Agencia Tributaria detalla, regla a regla, qué comprueba cuando recibe un registro de facturación y con qué código numérico responde si algo no cuadra. No es el reglamento: es el detalle de cómo se comprueba lo que el reglamento ya exige. Su versión vigente es la 1.2.2, de 8 de abril de 2026.

Este artículo es el registro fechado de en qué punto está esa documentación y dónde lo publicado sobre ella se ha quedado atrás. El catálogo de códigos, código a código, está en errores de la AEAT en VeriFactu.

¿Qué documentos publica la AEAT y cuál manda?

Manda el reglamento, y por debajo hay tres capas más. El RD 1007/2023 fija qué debe hacer un sistema de facturación. La Orden HAC/1177/2024 concreta las especificaciones técnicas. Y la sede electrónica publica los esquemas XSD, el listado de errores y el documento de validaciones, que es el que va por versiones.

• Reglamento y orden. Solo cambian por BOE. Son la fuente de tus obligaciones.
• Esquemas XSD. Definen la estructura del mensaje: qué campos existen y con qué formato.
• Listado de errores de la sede. Los códigos y su descripción corta.
• Documento de validaciones y errores. La regla que hay detrás de cada código. Es el que hay que citar con versión y fecha.

La jerarquía importa cuando dos fuentes dicen cosas distintas. Si una guía de internet contradice al documento de validaciones, gana el documento. Y si el documento y el comportamiento real del servicio no coinciden, lo que rechaza tu factura es el servicio.

¿Qué dice cada rango de códigos sobre tu factura?

El rango decide si la factura consta en la Agencia Tributaria, que es la única pregunta que cambia lo que hay que hacer después. La Agencia Tributaria organiza sus códigos en tres bloques y cada uno responde de forma distinta. El código concreto explica la causa; el rango explica la consecuencia.

Esa excepción del 3000 es la que más tiempo ahorra. Un 3000 llega dentro de un rechazo y no deja la factura sin registrar: significa que ese par de serie y número ya constaba de un envío anterior. Lo que corresponde es leer el estado del registro duplicado que viene en la respuesta y reconciliar con él el estado local, en lugar de reintentar el envío.

¿Qué errores no obligan a subsanar?

Dos: el 2004 y el 2009. El documento de validaciones los exceptúa expresamente de la obligación de subsanación. El resto de avisos del rango 2000-2009 sí deben subsanarse, aunque la norma no fije plazo para hacerlo. Que no haya plazo no los vuelve opcionales.

El 2004 salta cuando la fecha y hora de generación del registro cae fuera del margen que admite la Agencia Tributaria, y en la práctica es un reloj desincronizado. El 2009 avisa de que falta la clave de régimen en una operación con IPSI, que son Ceuta y Melilla. En ninguno de los dos hay nada que corregir.

De aquí sale una comprobación útil sobre el panel que uses. Si marca como pendientes de subsanar todos los avisos del rango 2000-2009, dos de ellos no se cerrarán nunca, y alguien acabará generando un registro de subsanación que no hacía falta.

¿Qué dos códigos se explican mal casi en todas partes?

El 2003 y el 1152, y los dos mandan al comerciante a mirar donde no es. El 2003 aparece documentado a menudo como un fallo del NIF del emisor. El 1152 se traduce como fecha de operación incoherente. Ninguna de las dos lecturas coincide con lo que hemos observado al enviar registros de verdad.

El 2003 es un error de encadenamiento. Señala que la huella del registro anterior no coincide con la que espera la Agencia Tributaria, y ese cálculo lo hace el sistema de facturación. La consecuencia práctica es directa: no hay ningún dato que el negocio pueda corregir en su panel para resolverlo. La corrección es del proveedor del software, y si el código se repite, es motivo para abrir una incidencia con él.

El 1152 no rechaza una fecha de operación incoherente: rechaza una fecha de expedición anterior al 28 de octubre de 2024, que es el arranque del sistema VERI*FACTU en las validaciones de la Agencia Tributaria. Quien lo interprete como un problema de la fecha de operación revisará un campo que está bien mientras el que causa el rechazo sigue igual.

¿Cómo afecta esto a una tienda que ya está facturando?

Menos de lo que parece, siempre que tu sistema traduzca los códigos. Seguir las versiones de la documentación técnica es trabajo del proveedor del software. Lo que sí te toca a ti es exigir que el panel te diga tres cosas por cada incidencia: si la factura consta, de quién es la corrección y qué hay que hacer.

Un número a secas obliga a buscarlo fuera, y ahí es donde entran los catálogos desactualizados. Entre un 3000 y un 1150 hay un abismo: con el primero la factura ya está registrada y con el segundo no existe registro alguno. Tratarlos igual produce en un caso un bucle de reenvíos y en el otro una factura emitida sin su registro. Los dos están desarrollados, con el resto del catálogo, en la página de errores de la AEAT.

Si integras por API, el mismo criterio aplica a lo que devuelve el endpoint. La respuesta debería traer el código, el estado del registro y a quién corresponde la corrección, no solo un fallo genérico. El contrato público de Factulit es https://api.factulit.es/api/v1 y lo describimos en la API de VeriFactu de Factulit.

Y una última cosa que ninguna documentación técnica resuelve. Que la Agencia Tributaria acepte un registro significa que ese registro es formalmente correcto, y no que la factura fuera la que tocaba expedir. Las validaciones comprueban formato, importes y encadenamiento; no comprueban si el documento que has emitido era el adecuado para esa venta.