Las rectificativas ya no van en BG-ES-1: lo que ha contestado la AEAT sobre el anexo nuevo

Quien esté programando las facturas rectificativas para la solución pública con el anexo de abril delante está escribiendo contra un grupo que ya se sabe que no va a existir. Lo dijo la Agencia por escrito, y dijo también cómo se van a escribir. No lo dijo todo.

Cómo era en el borrador de abril

En la Solución Pública de Facturación Electrónica (SPFE), una rectificativa es una factura de tipo 384, o 471 si la expide el destinatario. Lo que rectifica no va en ningún campo de la norma europea: el anexo I del proyecto de orden, de 16 de abril, lo metía en una extensión española, el grupo BG-ES-1, con tres datos:

• el tipo, de la lista L2.A: R1 a R4;
• la modalidad, de la lista L2.B: I, por diferencias, o S, por sustitución;
• y, si se informaban los importes rectificados, la base rectificada.

Una extensión nacional es justo lo que un programa de otro país no sabe leer. Ese es el problema que la respuesta de septiembre dice querer resolver.

El 22 de septiembre: la extensión desaparece

Se preguntó por escrito si BG-ES-1 desaparecía al pasar los datos rectificados a un grupo de la norma. La respuesta llegó el 22 de septiembre de 2026:

el grupo de extensión nacional BG-ES-1 para datos rectificados (presente en el borrador de abril) deja de existir de forma definitiva

Las rectificativas se estructuran, dice, con el grupo estándar BG-24 de la EN 16931, el de los documentos justificativos adicionales, haciendo uso de los calificadores de las listas L10 (Documentos justificativos adicionales) y L2. La finalidad que declara es quitar extensiones nacionales para que las facturas sean interoperables.

El detalle que importa: el anexo de abril tiene las listas de L1 a L8. Ni L9 ni L10. La lista con la que se escriben ahora las rectificativas no estaba en ningún texto publicado hasta la orden del 5 de octubre, que sí trae L10.

El 23 de septiembre: la lista L10

Así que se preguntó qué lleva esa lista. Contestaron al día siguiente. Son cinco calificadores, bajo el esquema urn:aeat:names:specification:schema::

Los códigos del tipo y de la modalidad no cambian: son palabra por palabra los de L2.A y L2.B del borrador de abril. Lo que cambia es el envase, de una extensión española a un grupo de la norma europea.

Y viene con una regla que es más estricta que la de abril:

Todas deben llevar tipo y modalidad, y las rectificativas por sustitución (S) deben llevar importe rectificados

En abril, los importes eran opcionales y solo obligaban a la base si se informaban. Con esta respuesta, en una rectificativa por sustitución dejaban de ser opcionales. La orden no llega tan lejos, y está en el aviso de arriba.

Lo que no estaba escrito

Con la lista en la mano parecía que ya se podía programar. Faltaba decidir dos cosas, y ninguna de las dos se podía deducir. La orden ha escrito las dos, y lo que dice está en el aviso de arriba; lo que sigue es cómo estaban el 28 de septiembre.

El esquema del identificador. La respuesta escribe urn:aeat:names:specification:schema:, sin ubl:. El anexo de abril escribe urn:aeat:names:specification:ubl:schema:QR para el QR, que es la primera entrada de esa misma lista. Los dos textos se contradicen en el único valor que se puede comprobar, así que uno de los dos estaba mal, y no se sabía cuál. Era el de abril: la orden escribe el esquema de L10 sin ubl:.

En qué campo va el valor. Un BG-24 tiene un identificador (BT-122) y una descripción (BT-123). Los dos BG-24 que el anexo de abril sí describe los usan de forma distinta:

Un ejemplo: una rectificativa de tipo R4. Si el calificador, RECT:TIPO, ocupa el identificador, el R4 tiene que ir a otro campo, y la respuesta no dice a cuál. Lo razonable sería la descripción, como en el QR. Pero entonces el número de la autorización, que en abril iba en el identificador, se queda sin sitio. Razonable no es publicado. Las dos preguntas se hicieron por escrito el 23 de septiembre y, al escribir esto, siguen sin respuesta de fondo.

El abono 381 y la categoría K, fuera por escrito

La misma respuesta del 23 confirmó algo que ya se leía en el borrador y que conviene tener delante al programar rectificativas:

No se aceptan InvoiceType de tipo 381 en L1. Tampoco se aceptará la categoría K en L4.

El 381 es el abono de la norma europea. Quien venga de Peppol, o de un programa pensado para Europa, está acostumbrado a corregir una factura con un abono 381. En la solución pública eso no existe: la corrección es una factura 384 con sus datos rectificados. Y la K es la categoría de IVA de la entrega intracomunitaria. Una factura que cumple la EN 16931 puede, por tanto, no pasar el anexo español, y ahora lo dice la Agencia y no una deducción.

La respuesta añade que la cuestión se ha elevado a los departamentos de gestión para que reevalúen el criterio. Así que está confirmado y, a la vez, puede cambiar.

Qué documentos de validación vendrán, y cuándo

Dos respuestas más que ayudan a planificar:

• Los documentos de validación del portal de desarrolladores describirán las reglas de forma escrita y simplificada (con un formato similar al de la norma EN 16931), sin incluir ficheros ejecutables Schematron. No va a haber un fichero oficial que ejecutar: cada uno tendrá que convertir la prosa en reglas.
• A cambio, en el entorno de pruebas habrá un servicio específico de validación de facturas individuales. En cuanto a cuándo, la respuesta dice que será durante el mes de Octubre pero dependerá de la publicación de la Orden Ministerial y el texto final con el que se publique.

Qué hacer hoy, si estás programando rectificativas

• No construyas sobre la extensión de abril, BG-ES-1. La orden no la tiene, y en ella BG-ES-1 es otro grupo, el de los datos del tercero.
• Escribe la rectificativa como BG-24 con calificadores de L10, con el esquema sin ubl: y el valor en cbc:DocumentTypeCode, como dice la orden. Deja configurable lo único que no dice: si el identificador lleva el esquema delante o va solo.
• Tipo y modalidad siempre, e importes cuando sustituyas con una única factura con los importes correctos, que es el caso para el que la orden los prevé.
• Corrige con 384, no con 381, aunque tu programa lo haga así para el resto de Europa.
• Contrasta con la orden, no con estas respuestas. El anexo ya está en el BOE, y en los importes rectificados dice menos que ellas.

Qué hace Glosa-e con esto, hoy

Actualizado el 13 de octubre de 2026. Desde el 11 de octubre las rectificativas se miden con la orden. Una rectificativa (384 o 471) tiene que traer un BG-24 con el tipo (RECT:TIPO) y otro con la modalidad (RECT:MODALIDAD), y si no los trae es un ERROR, también cuando llega con la extensión de abril, que la orden no tiene. El identificador se reconoce con el valor solo o con el esquema de la orden delante; con el de abril, el que lleva ubl:, no se lee como dato de la rectificativa. El tipo y la modalidad se leen en cbc:DocumentTypeCode y se comparan con L2.A y L2.B: si el código falta o no está en su lista, también es ERROR. De los importes rectificados se comprueba la forma: cada uno con un código de L2.C y su importe en la descripción, cinco como mucho, y en una sustitución. Con un código repetido sale un AVISO: la AEAT contestó el 13 de octubre que va uno por código; y con la modalidad I, otro AVISO. Que la cifra sea la buena no se comprueba. Y si la modalidad es S y no trae importes, sale una NOTA y no un fallo: la orden solo los pide cuando se opta por una única factura con los importes correctos, y eso no se ve en la factura. La ficha SPFE-RECTIFICATIVA lo explica, y la del tipo de factura explica por qué el 381 no pasa.

Es gratis, es código abierto (AGPL-3.0-only) y corre entero en tu navegador: el motor se descarga a tu ordenador y la factura no sale de él.

Está en desarrollo y en pruebas. Si encuentras algo mal, o si sabes cómo se junta el esquema con el valor, escríbeme.