Documentación

Errores de la AEAT en VeriFactu: qué significa cada código y qué hacer con él

Catálogo de errores VeriFactu explicados: 3000, 1150, 1152, 2001, 2003, 2004 y 2009. Si la factura consta o no en la AEAT, quién lo corrige y qué hacer.

Respuesta directa

Cuando envías un registro de facturación a la Agencia Tributaria, la respuesta no es un "sí" o un "no": es un estado —correcto, aceptado con errores, incorrecto o parcialmente correcto— acompañado de un código numérico y una descripción técnica.

Esta página es el catálogo de errores que usamos internamente, publicado. Está construido sobre el "Documento de validaciones y errores" de la AEAT (versión 1.2.2, de 08/04/2026) y el listado oficial de errores de la sede electrónica, contrastado con el comportamiento real observado al enviar registros. Los flujos de alta, subsanación, anulación y rectificativa descritos aquí están probados en el entorno de pruebas de la AEAT (Preportal), con última ejecución el 27/07/2026.

¿Por qué el código de error por sí solo no basta?

Porque el código dice qué regla se ha incumplido, pero no dice si la factura consta en la Agencia Tributaria. Y esa es la pregunta que decide todo lo demás: si consta, la corrección es una subsanación sobre un registro que ya existe; si no consta, hay una factura emitida sin su registro de facturación.

Un ejemplo: el error 3000 llega dentro de un rechazo, pero la factura sí consta. El 1150 también es un rechazo y la factura no consta. Tratarlos igual produce en un caso un bucle inútil y en el otro un incumplimiento abierto.

¿Cómo se clasifican los errores de VeriFactu?

Por rangos numéricos, y el rango determina qué ha pasado con tu factura. No es una convención nuestra: son los tres bloques en los que la AEAT organiza su listado oficial de errores.

ClasificaciónRangosQué significa para tu factura
Rechazo del envío completo4102-4141, 3500-3503Ningún registro del envío consta. El problema está en la cabecera, el certificado o el apoderamiento, no en los datos de una factura concreta.
Rechazo del registro1100-1293, 3000-3004La factura no consta en la AEAT (con una excepción importante: el 3000). Hay que corregir y volver a enviar.
Aceptado con errores2000-2009El registro consta. Los errores "deberán ser subsanados", salvo dos códigos expresamente exceptuados.
  • Rechazo del envío. No hay nada que corregir en la factura: es configuración (certificado caducado, apoderamiento no vigente, datos del emisor). La corrección es del proveedor del software o de la configuración fiscal del negocio, nunca del dato de una venta.
  • Rechazo del registro. La factura existe en tu contabilidad, pero su registro no llegó a anotarse. El camino normativo es un alta de subsanación: un registro nuevo, con la misma clave de factura (NIF del emisor, serie y número, y fecha de expedición), marcado como subsanación y como corrección de un rechazo previo. El registro rechazado no se borra ni se modifica.
  • Aceptado con errores. La factura ya consta. Se corrige con un alta de subsanación que mantiene la clave de factura, pero sin la marca de rechazo previo, porque no hubo rechazo. La norma no fija plazo, lo que no lo hace opcional.

Y un detalle importante: un rechazo no rompe la cadena de huellas, porque el siguiente registro se encadena contra el último generado, aceptado o rechazado. Borrar un rechazo para "limpiarlo" es lo que sí la rompe.

Error 3000: ¿por qué la AEAT dice que la factura ya consta?

Porque el registro ya se anotó en un envío anterior y este era un duplicado. El 3000 llega como rechazo, pero no deja la factura sin registrar: el registro original sigue vigente.

La AEAT identifica cada registro por la combinación de NIF del emisor, número de serie y fecha de expedición. Si recibe otra vez esa combinación, responde 3000 y añade un bloque de registro duplicado con el estado del registro ya anotado —correcta, aceptada con errores o anulada—, que es el que describe la situación real de tu factura.

  • Consta en la AEAT: sí, con el registro original.
  • Corrección: ninguna. No es subsanable porque no hay nada que subsanar.
  • Qué hacer: leer el estado del registro duplicado y reconciliar con él el estado local. Lo que no se debe hacer es reintentar el envío en bucle ni generar una corrección nueva "por si acaso".

Causas habituales: dos sistemas facturando bajo el mismo NIF con la misma serie, un reintento tras un corte de comunicación o una renumeración manual. De ahí la regla que ahorra disgustos: nunca reutilizar numeración. Si convives con otro programa bajo el mismo NIF, cada sistema debe usar series distintas (guía de coexistencia).

En Factulit la numeración es única por NIF de emisor, con bloqueo transaccional, y la verificación previa detecta y avisa de una identidad ya registrada antes de enviar.

Error 1150: ¿por qué se rechaza mi factura simplificada?

Porque supera el importe máximo que la AEAT admite para una factura simplificada (tipo F2): 3.000,00 euros sumando base y cuota. Es un rechazo de registro, así que la factura no consta.

  • Consta en la AEAT: no.
  • Corrección: del comerciante.
  • Qué hacer: emitir una factura completa (F1) con el NIF del cliente para ese importe.

Hay que deshacer una confusión de mercado: esos 3.000 euros son el techo de una validación técnica, no el límite legal de la simplificada. Coinciden con el tope que el artículo 4.2.a) del reglamento de facturación fija para las ventas al por menor, pero son dos cosas distintas: el límite general del artículo 4.1 son 400 euros, y hay operaciones donde la simplificada no cabe a ningún importe. Que un registro entre sin error no significa que la factura esté bien expedida: lo desarrollamos en la guía de la factura simplificada.

Error 1152: ¿por qué rechaza una fecha de expedición correcta?

Porque la fecha de expedición es anterior al 28 de octubre de 2024, inicio del sistema VERI*FACTU. La AEAT no admite registros anteriores a esa fecha, aunque la factura sea válida en tu contabilidad.

  • Consta en la AEAT: no.
  • Corrección: del comerciante.
  • Qué hacer: revisar la fecha de la factura. Suele aparecer al migrar históricos o al retrodatar más de lo previsto.

Este código se explica a menudo como "fecha de operación incoherente". No lo es: en la práctica hemos observado que el 1152 responde exclusivamente a la fecha de expedición anterior al arranque del sistema. Confundirlo lleva a revisar la fecha de operación, que no es la que causa el rechazo.

Error 2001: mi cliente existe, ¿por qué dice que su NIF no consta?

Porque el NIF del destinatario no figura en el censo de la Agencia Tributaria. Es un error admisible: el registro sí consta, pero hay que subsanarlo.

  • Consta en la AEAT: sí, aceptado con errores.
  • Corrección: del comerciante.
  • Qué hacer: comprobar el NIF con el cliente y corregirlo, o —si es un particular español con DNI o NIE válido pero no censado— identificarlo con el tipo de identificación "otro documento" para españoles no censados. Ese es el camino de subsanación previsto, y no significa dejar el documento vacío.

Este error solo puede detectarse al recibir la factura, porque la comprobación censal la hace la Agencia Tributaria: ningún sistema puede anticiparlo con certeza antes de enviar.

Errores 2000, 2002, 2003, 2007 y 2008: la familia del encadenamiento

Son cinco códigos que dicen lo mismo desde ángulos distintos: la huella que enlaza este registro con el anterior no cuadra con lo que espera la AEAT. Todos son admisibles, así que el registro sí consta, y en todos la corrección es del proveedor del software.

CódigoQué señala
2000El cálculo de la huella del registro no es correcto.
2002La huella del registro anterior no tiene la longitud esperada.
2003El encadenamiento con el registro anterior no coincide.
2007El registro se declara como primero de la cadena, pero ya constan facturas anteriores con este sistema.
2008Dos registros consecutivos comparten la misma huella de encadenamiento.
  • Consta en la AEAT: sí, aceptado con errores.
  • Corrección: del proveedor del software.
  • Qué hacer: nada por parte del comerciante. Si aparece de forma repetida, es motivo para hablar con soporte: indica un problema real en la cadena.

Sobre el 2003, una corrección importante. Es frecuente encontrarlo documentado como un problema del NIF del emisor. En la práctica hemos observado que el 2003 es un fallo del encadenamiento con el registro anterior, no del NIF. La diferencia no es académica: interpretarlo como un problema de NIF manda al comerciante a "corregir" un dato que está bien mientras el fallo real, que solo puede resolver el software, sigue ahí.

Errores 2005 y 2006: ¿por qué dice que los importes no cuadran?

Porque el total declarado no coincide con la suma de sus partes. El 2005 se refiere al importe total (base más cuota de IVA más recargo de equivalencia) y el 2006, a la cuota total (suma de cuotas de IVA y de recargo). Son admisibles: el registro sí consta.

  • Consta en la AEAT: sí, aceptado con errores.
  • Corrección: del comerciante.
  • Qué hacer: revisar líneas, bases, cuotas y tipos de IVA hasta que cuadren, y enviar la corrección. Suelen venir de redondeos por línea o de descuentos aplicados después del cálculo.

Errores 2004 y 2009: los dos que no hay que subsanar

Son los dos códigos que la AEAT exceptúa expresamente de la obligación de subsanación (Documento de validaciones y errores v1.2.2, apartado 4.3.1). El registro consta, aparece un aviso y no hay nada que corregir.

  • 2004: la fecha y hora de generación del registro está fuera del margen que admite la AEAT; en la práctica, relojes desincronizados.
  • 2009: falta la clave de régimen en una operación con IPSI (Ceuta y Melilla).
  • Consta en la AEAT: sí, en ambos.
  • Corrección: ninguna exigible.
  • Qué hacer: dejar constancia y seguir. Un sistema que te pida "corregir ante Hacienda" un 2004 te hace generar un registro innecesario.

Si tu panel marca todos los avisos del rango 2000-2009 como pendientes de subsanar, dos de ellos nunca se cerrarán. Para operaciones con IPSI e IGIC, ver la guía de Canarias, Ceuta, Melilla y OSS.

Errores 1112, 1133 y 1100: rechazos de registro habituales

Tres códigos de rechazo: la factura no consta y hay que corregir y volver a enviar.

  • 1112 — la fecha de expedición no es válida o es futura. Corrección del comerciante.
  • 1133 — la fecha de expedición está fuera del rango admitido. No se aceptan fechas de más de veinte años atrás. Corrección del comerciante.
  • 1100 — datos del sistema informático incorrectos. La identificación del sistema de facturación no es válida. Corrección del proveedor del software: no es un dato del negocio ni de la venta.

Error 1275: el rechazo previo mal referenciado

Se produce cuando existe un rechazo previo de ese registro y la nueva operación no lo referencia como corresponde. La factura no consta y la corrección es del proveedor del software.

Hay un detalle fino que solo aparece al probar contra el entorno de pruebas de la AEAT: la marca de rechazo previo del alta y la de la anulación no admiten los mismos valores. En la práctica hemos observado que propagar a una anulación la marca propia de una subsanación de alta provoca un rechazo real por 1275. Son dos marcas distintas para dos operaciones distintas, y confundirlas rompe la anulación aunque el resto del registro sea correcto.

Otros códigos documentados que conviene reconocer

Validaciones de detalle, todas en el rango de rechazo del registro: la factura no consta en ninguna de ellas.

CódigoQué valida
1125La fecha de operación no puede ser posterior al año siguiente.
1134La fecha de operación no puede ser anterior a hoy menos veinte años.
1130 y 1287El número de serie solo admite caracteres ASCII imprimibles y prohíbe comillas, ángulos y el signo igual.
1138 y 1139Marca de "macrodato", obligatoria cuando el importe total alcanza los 100.000.000 de euros.
1252En ventas de península a Canarias, Ceuta y Melilla con clave de régimen 08, la calificación de la operación es obligatoria.

Si tu respuesta trae un código que no aparece aquí, mira en qué rango cae: el rango ya te dice si la factura consta y quién tiene que arreglarlo.

¿Qué pasa si la Agencia Tributaria no responde?

Que la facturación no se detiene. Las facturas se siguen emitiendo y numerando con normalidad, sus registros se encolan y se reenvían con espera progresiva hasta que la AEAT vuelva a responder.

  • El reenvío se marca como incidencia. Cuando un registro se reenvía tras un fallo de comunicación, la cabecera del envío lleva la marca de incidencia prevista en las especificaciones técnicas desarrolladas por la Orden HAC/1177/2024. Es la forma normativa de declarar que ese envío llega tarde por un problema de comunicación.
  • El ritmo lo marca la AEAT. Su respuesta incluye un tiempo de espera antes del siguiente envío, y un sistema correcto lo respeta en lugar de martillear el servicio.
  • Los reintentos no son infinitos. Cuando se agotan, el registro queda señalado para que alguien lo mire: aparece como incidencia con acción de reintento.

Lo que nunca debe pasar es que un corte de comunicación acabe en una factura sin registro que nadie vuelve a mirar. La misma lógica se aplica al integrar por API.

¿Cómo se evitan estos errores antes de enviar?

Con verificación previa: la capa que revisa cada factura antes de que salga hacia la Agencia Tributaria y avisa de lo que la AEAT rechazaría. Es la diferencia entre corregir un dato en tu panel y subsanar un registro ya presentado. Actúa en dos momentos:

  • Al preparar la factura. Un conjunto de reglas fiscales revisa el borrador y señala lo que impediría un registro válido: destinatario incompleto, importes que no cuadran, fechas fuera de rango o rectificativa sin factura original. Se ejecuta al crear o editar la factura, a petición desde la propia ficha y en un barrido diario de las facturas aún sin enviar.
  • Justo antes del envío. Tres comprobaciones anticipan los rechazos más caros: la validación contra el esquema oficial de la AEAT, la detección de duplicados —una identidad de factura ya registrada, que es exactamente lo que produciría un 3000— y la verificación del encadenamiento con el registro anterior.

Con precisión, porque importa: hoy la detección de duplicados avisa, no bloquea el envío. Está deliberadamente en modo de observación, porque un falso positivo que impidiera enviar convertiría una alerta en un incumplimiento de la obligación de remisión.

Todo lo que encuentra la verificación previa, y todo lo que devuelve la AEAT, aterriza traducido a lenguaje llano en un único sitio: qué ha pasado, si la factura consta, qué hay que tocar y de quién es la corrección. Ver el flujo completo en cómo funciona Factulit.

Preguntas frecuentes

Dudas rápidas sobre los errores de la AEAT en VeriFactu. Hay más en las preguntas frecuentes sobre VeriFactu.

Contactar
No necesariamente. Los errores del rango 2000-2009 son avisos sobre un registro que sí consta. Los del rango 1100-1293 rechazan el registro: la factura está emitida pero su registro de facturación no está anotado, y eso se resuelve con un alta de subsanación.
La norma no fija plazo para los errores del rango 2000-2009: dice que "deberán ser subsanados". Que no haya plazo no lo convierte en opcional. Los códigos 2004 y 2009 están expresamente exceptuados de esa obligación.
Una subsanación corrige el registro enviado a la Agencia Tributaria manteniendo la misma factura y la misma clave de factura. Una rectificativa corrige la factura y crea un documento nuevo con su propio número. Si el error es de datos del registro, se subsana; si el reglamento de facturación exige rectificar el documento, se emite rectificativa: lo vemos en devoluciones y rectificativas.
No. Ese registro ya consta en la Agencia Tributaria. Lo correcto es leer el estado del registro duplicado que viene en la respuesta —correcta, aceptada con errores o anulada— y actualizar el estado en tu sistema. Reenviarlo solo produce otro 3000.
Del proveedor del software, no del comerciante. Los códigos 2000, 2002, 2003, 2007 y 2008 se refieren a la huella que enlaza cada registro con el anterior, un cálculo que hace el sistema de facturación. No hay ningún dato que el negocio pueda corregir en su panel para resolverlos.

Enlaces relacionados: preguntas frecuentes sobre VeriFactu · VeriFactu para tiendas online · ejemplo de factura VeriFactu · la factura simplificada · convivir con otro sistema · integración por API

Última actualización 15/08/2026. Esta página es documentación técnica divulgativa y no constituye asesoramiento fiscal ni jurídico individual. Las fuentes normativas citadas son el "Documento de validaciones y errores" de la Agencia Tributaria (v1.2.2, 08/04/2026) y su listado oficial de errores; ante cualquier duda sobre un caso concreto, consulta con tu asesoría.

¿Prefieres que preparemos el alta contigo?

Déjanos tu email y te acompañamos con la conexión, la serie, el certificado y, cuando abra Producción el 1 de enero de 2027, el paso seguro de Modo Pruebas a Producción.

Sin tarjeta · Primero configuramos en Modo Pruebas