VeriFactu contra la AEAT: los tres errores que nos frenaron y cómo se arreglan

Por qué escribimos esto

VeriFactu se puede resumir en una frase: cada factura que emites deja una huella SHA-256 encadenada con la anterior, y el sistema que la emite tiene que identificarse ante la Agencia Tributaria. Suena sencillo. La documentación oficial son varios PDF y un catálogo de validaciones, y el camino habitual es descubrir las reglas de una en una, a base de que te rechacen el envío.

Nosotros lo hemos implementado desde cero para nuestro ERP, en Dart, y lo hemos enviado a la preproducción de la AEAT. Este artículo es la lista de lo que nos frenó, con el número de error delante, porque es lo que nos habría ahorrado tiempo encontrar escrito en algún sitio.

Aviso de honestidad: preproducción no es producción. Es el entorno de pruebas de la AEAT, sin efectos fiscales. Todo lo que sigue está comprobado ahí.

El montaje, en cuatro piezas

Antes de los errores, lo que hay que tener montado:

1. El registro (RegistroAlta): la factura en XML, con su desglose de IVA.
2. La huella: SHA-256 en 64 caracteres hexadecimales en mayúsculas, calculada sobre unos campos concretos en un orden concreto, y encadenada con la huella de la factura anterior. Esto es lo que hace que no puedas borrar una factura del medio sin que se note.
3. El envío: SOAP sobre mTLS. El certificado no es solo para cifrar: es tu identificación. En modo VeriFactu no hay firma XAdES; la autenticación es el certificado del envío y la integridad la da la cadena de huellas.
4. El QR de cotejo: el cuadradito que va impreso en el ticket y que permite a cualquiera comprobar la factura contra la AEAT.

La huella es la parte que más miedo da y la que menos problemas nos dio: se puede validar en local contra vectores de prueba conocidos antes de hablar con nadie. Recomendación: hacedlo. Llegar a la AEAT con la huella ya validada te quita una variable de encima cuando empiecen los rechazos.

Error 4104 — «NIF de ObligadoEmisión no identificado»

El primero, y el más desconcertante, porque el NIF estaba bien.

La regla es que el NIF del obligado a emitir tiene que estar identificado en el censo de la AEAT, y la identificación va con el nombre: no basta con mandar el número correcto, tiene que cuadrar con la razón social que Hacienda tiene registrada para ese NIF.

Qué lo arregló: usar como NombreRazonEmisor exactamente el nombre que figura en el certificado. El certificado ya lleva dentro el par NIF + nombre tal y como la AEAT lo conoce; cualquier variación tuya —una S.L. abreviada, un acento de más— y no cuadra.

Error 1189 — «Faltan Destinatarios»

Este es de reglas cruzadas, y es el típico que te hace perder una tarde.

El bloque Destinatarios no es opcional a tu gusto: depende del tipo de factura.

• Las F1, F3 y las rectificativas R1–R4 exigen al menos un destinatario.
• Las F2 (simplificada) y R5 no pueden llevarlo. Si lo mandas, te rechaza.

O sea que el mismo campo es obligatorio o está prohibido según una letra que va tres niveles más arriba en el XML.

Qué lo arregló: para la prueba, emitir como F2, la simplificada, que es el ticket de toda la vida y no lleva destinatario. Para las facturas nominativas hay que mandar el bloque, y ahí aparece el siguiente escalón: según la clave de régimen, el NIF del cliente también tiene que estar identificado en el censo. Es decir, el problema del 4104 otra vez, pero ahora con el NIF de tu cliente, que tú no controlas.

Error 1110 — «NIF de SistemaInformatico no identificado»

El más fácil de entender mal, y por eso el que merece el artículo entero.

En el registro hay un bloque SistemaInformatico que no habla de tu empresa ni de la de tu cliente: habla del programa. Quién lo fabrica. Si tú vendes software de facturación, ese bloque lleva tu NIF como productor, no el del comercio que está emitiendo la factura.

Y lleva unos cuantos campos obligatorios que es fácil dejarse:

• IdSistemaInformatico: exactamente 2 caracteres [A-Z0-9].
• NombreSistemaInformatico.
• TipoUsoPosibleSoloVerifactu y TipoUsoPosibleMultiOT: los dos obligatorios.
• El NIF del productor, identificado en censo — con su nombre, igual que en el 4104.

Qué lo arregló: lo mismo que el 4104. El nombre, tal y como está en el certificado.

Las reglas que sí conviene leerse antes

Después del tercer rechazo dejamos de ir a ciegas y nos leímos el catálogo oficial de validaciones de la AEAT entero. Fue la decisión más rentable de todo el proceso: a partir de ahí, la factura pasó todas las validaciones aplicables a la primera. Las que más fácil es incumplir sin enterarte:

• Fecha de expedición: no puede ser futura ni anterior al 28/10/2024.
• Número de serie: ASCII 32–126, y prohibidos los caracteres " ' < > =.
• F2 simplificada: la suma de base + cuota no puede pasar de 3.000 €.
• Tipo impositivo: solo se aceptan los del catálogo (0, 2, 4, 5, 7,5, 10 y 21).
• Cuadres: la cuota repercutida tiene que ser base × tipo, la cuota total la suma de las repercutidas y el importe total la suma de todo. Con margen de céntimos, pero se comprueba.
• Fecha y hora de generación del registro: si se te va al futuro respecto al reloj de la AEAT es aviso, no rechazo. Conviene saber cuáles son avisos y cuáles te tumban el envío.

Lo que nos llevamos

Tres conclusiones, por si os sirven:

1. Casi todos los rechazos iniciales son de identidad, no de contenido. El XML estaba bien; lo que fallaba era quién decía ser cada uno. Empezad por ahí.
2. Validad la huella en local antes de enviar nada. Es la única parte que podéis dar por buena sin depender de la AEAT.
3. Leed el catálogo de validaciones antes de la cuarta ronda, no después. Ir corrigiendo error por error es lento y encima te da una falsa sensación de avance.

Todo esto lo hemos hecho para llevarlo a Atellum, nuestro programa de gestión para tiendas y talleres pequeños: la idea es que quien lo use no tenga que saber nada de lo anterior, que es exactamente el motivo por el que nos hemos comido nosotros los tres errores.

Si estáis con la misma pelea y os atascáis en un código concreto, escribidnos y os decimos qué era en nuestro caso.