Conocimiento · Factura electrónica
Validar la factura electrónica y leer correctamente el informe de validación
Cuando una factura electrónica de su software es rechazada, su equipo debe averiguar a partir del informe de validación qué campo ha provocado el mensaje y quién puede corregirlo.
Mostramos cómo leer un informe de validación y en qué puntos de su software debe integrarse la validación.
Qué se comprueba al validar una factura electrónica
Un validador comprueba una factura electrónica sucesivamente frente a tres conjuntos de reglas y registra cada desviación en un informe de validación.
Esquema XML de la sintaxis
Una factura electrónica conforme a la EN 16931 se presenta en una de dos sintaxis, UBL o UN/CEFACT CII. Todas las especificaciones de uso habituales se basan en estas dos sintaxis, como XRechnung, ZUGFeRD y Peppol BIS Billing 3.0.
El esquema XML de la sintaxis establece qué elementos están permitidos, en qué orden aparecen y qué tipo de dato tienen.
Los errores de esquema no tienen ID de regla. El analizador XML los notifica con códigos propios, por ejemplo cvc-complex-type.2.4.a para un elemento situado en un lugar donde el esquema no lo espera.
En ZUGFeRD, un archivo CII está incrustado en un PDF. El validador comprueba la parte XML. En caso de discrepancias con la parte visual, esta parte es la determinante, según la circular del Ministerio Federal de Finanzas (BMF) de 15 de octubre de 2025 sobre la introducción de la factura electrónica obligatoria.
Reglas de negocio de la EN 16931
Las reglas de negocio controlan los datos de una factura electrónica en busca de errores lógicos, por ejemplo si los campos obligatorios están rellenados y si los totales cuadran entre sí. El Comité Europeo de Normalización (CEN) publica estas reglas como archivos Schematron en GitHub, respectivamente para UBL y para CII.
Por el prefijo del ID de regla se reconoce el tipo de comprobación. Las reglas con BR y un número comprueban los campos obligatorios y su cantidad, BR-CO comprueba cálculos y dependencias entre campos, BR-CL comprueba listas de códigos y BR-DEC los decimales de los importes. Reglas como BR-S, BR-AE o BR-IC comprueban los datos de las distintas categorías de IVA.
Los archivos del CEN contienen además reglas específicas de la sintaxis. Las reglas con el prefijo UBL-CR emiten, por ejemplo, una advertencia cuando un archivo UBL contiene elementos que no pertenecen al modelo de datos de la EN 16931.
Reglas de XRechnung y Peppol BIS Billing 3.0
XRechnung y Peppol BIS Billing 3.0 son especificaciones de uso de la EN 16931, denominadas técnicamente CIUS (Core Invoice Usage Specification). Prescriben campos adicionales y completan la EN 16931 con reglas propias. Una CIUS no puede introducir nuevos campos de datos.
Las reglas de XRechnung empiezan por BR-DE y proceden de la Oficina de Coordinación de Estándares TI de Alemania (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 añade reglas con los prefijos PEPPOL-EN16931 y PEPPOL-COMMON, así como reglas específicas de cada país.
El identificador de especificación en BT-24 determina qué especificación de uso se aplica al archivo. El validador de la KoSIT selecciona el escenario de comprobación adecuado a partir de este identificador. Por ello, un identificador incorrecto u obsoleto puede hacer que el archivo se compruebe frente a otras reglas o sea rechazado.
Lo que una validación no comprueba
Un validador no reconoce si el tipo impositivo corresponde a la prestación ni si la descripción de la prestación es suficiente.
Según el Ministerio Federal de Finanzas de Alemania, todos los datos obligatorios a efectos del IVA deben figurar en la parte estructurada de la factura electrónica. Una mera referencia a un anexo con la descripción de la prestación no basta. Aun así, un nombre de artículo como «ver anexo» en BT-153 supera la validación, porque ninguna regla evalúa el contenido de este campo.
La KoSIT y el Foro alemán de factura electrónica (Forum elektronische Rechnung Deutschland, FeRD) han publicado una tabla que asigna a los datos obligatorios según la Ley alemana del IVA los campos BT correspondientes. Con esta tabla puede determinar qué datos obligatorios debería asegurar su software con comprobaciones de plausibilidad propias.
Estructura de un informe de validación
Cada entrada del informe de validación contiene por lo general cuatro datos.
ID de regla
El ID de regla, como BR-CO-15 o BR-DE-2, remite a la regla en la documentación del conjunto de reglas correspondiente.
Nivel de gravedad
Un validador marca cada mensaje como error o como advertencia. En las reglas de Peppol, los errores se denominan fatal. Una advertencia por sí sola no suele provocar el rechazo. Algunos validadores emiten además indicaciones, es decir, recomendaciones para una implementación limpia sin influencia en el resultado. Al final de su informe, el validador de la KoSIT recomienda aceptar o rechazar el documento.
Peppol suele introducir las nuevas reglas primero como advertencia y las eleva a error en una versión posterior. Con la versión 3.0.21, por ejemplo, las reglas PEPPOL-COMMON-R052 y PEPPOL-COMMON-R053 pasaron de advertencias a errores, según consta en las notas de versión de Peppol BIS Billing 3.0.
Ubicación
La ubicación es una expresión XPath que apunta al elemento afectado en el XML. El mismo número BT se encuentra en lugares distintos en UBL y en CII. El importe de la factura con IVA (BT-112) figura en UBL en el elemento cbc:TaxInclusiveAmount bajo cac:LegalMonetaryTotal y en CII en el elemento ram:GrandTotalAmount bajo ram:SpecifiedTradeSettlementHeaderMonetarySummation.
En las reglas que comparan varios campos, la ubicación suele apuntar a un elemento superior. El valor que provoca el mensaje lo encontrará entonces a través del texto del mensaje.
Texto del mensaje
El texto del mensaje describe la regla y suele indicar los números BT implicados. El mensaje de BR-CO-15 indica, por ejemplo, que el importe de la factura con IVA (BT-112) debe corresponder a la suma del importe de la factura sin IVA (BT-109) y el importe del IVA (BT-110).
Desde la versión 3.0.21, los textos de las reglas de Peppol empiezan por el ID de regla.
Evaluar los informes de validación en el orden correcto
Un informe de validación largo suele deberse a pocas causas.
-
Corregir los errores de esquema
Mientras el archivo no cumpla el esquema, los resultados de las reglas de negocio son poco significativos o faltan por completo. Por ello, corrija primero los errores de esquema en la exportación y vuelva a validar el archivo a continuación.
-
Agrupar las entradas por ID de regla
Un error en el mapeo puede aparecer en cada línea de la factura. Una factura con 40 líneas genera entonces 40 entradas de la misma regla que se deben a una única causa. Por ello, evalúe el informe por ID de regla.
-
Reconocer errores derivados
Un elemento ausente puede infringir varias reglas a la vez. Si falta el desglose del IVA (BG-23), el validador notifica, por ejemplo, BR-CO-18 y además reglas de la categoría de IVA afectada, como BR-S-01. Corrija primero la causa y vuelva a validar antes de tratar los demás mensajes uno por uno.
-
Del número BT a su propio modelo de datos
El número BT conecta el informe de validación con su software. Mantenga una asignación de cada número BT al campo de la base de datos, al campo del formulario en su interfaz y a la responsabilidad. La responsabilidad determina si un error lo corrige su equipo o su cliente, por ejemplo cuando faltan datos maestros.
-
Evaluar y registrar las advertencias
Decida para cada advertencia si la corrige o la acepta conscientemente, y registre la decisión. Compruebe en cada nueva versión si una advertencia aceptada pasa a ser un error.
Causas de error típicas por grupo de reglas
El grupo de reglas suele mostrar ya en qué punto de su software debe aplicarse la corrección.
Errores de esquema sin ID de regla
La causa está en el orden de los elementos, en el espacio de nombres o en un tipo de dato incorrecto en la exportación. La corrección se aplica en la función de exportación, una sola vez para todos los clientes.
BR con número
La causa es un campo obligatorio que no está mapeado o que está vacío en los datos maestros. La corrección se aplica en el mapeo o en el campo obligatorio de la interfaz.
BR-CO y BR-DEC
La causa está en los totales, el redondeo, los descuentos y los recargos a nivel de documento. La corrección se aplica en la lógica de cálculo de la emisión de facturas.
BR-CL
La causa es un código obsoleto o propio, por ejemplo para unidades de medida o países. La corrección se aplica en las listas de códigos de su software.
BR-S, BR-AE, BR-IC y otras categorías
La categoría de IVA, el tipo impositivo y el motivo de exención no concuerdan. La corrección se aplica en la lógica fiscal y en los datos maestros de los artículos.
UBL-CR
La exportación contiene elementos UBL fuera del modelo de datos de la EN 16931. La corrección se aplica en la función de exportación.
BR-DE
Faltan los datos de contacto del vendedor, los datos de pago o la referencia del comprador. La corrección se aplica normalmente en los datos maestros de sus clientes.
PEPPOL-EN16931 y PEPPOL-COMMON
Falta la dirección electrónica o un identificador tiene un formato incorrecto. La corrección se aplica en los datos maestros y en la gestión de los ID Peppol.
Falta la referencia del comprador en XRechnung (BR-DE-15)
La regla BR-DE-15 notifica que falta la referencia del comprador en BT-10. En las facturas a la Administración pública, allí figura el Leitweg-ID (identificador de enrutamiento) del organismo. Para las facturas B2B, según el Ministerio Federal de Finanzas de Alemania, a efectos del IVA basta un marcador de posición como «-» si el destinatario de la factura no indica un identificador propio. Por ello, su software puede rellenar previamente el campo en las facturas B2B con un marcador de posición que sus clientes pueden sobrescribir.
Diferencias de redondeo en el IVA (BR-S-09)
La regla BR-S-09 compara el importe del IVA de la categoría de tipo general con el producto de la base imponible y el tipo impositivo. Si su software redondea el IVA por línea y suma los importes, el total puede diferir. Con muchas líneas, la diferencia puede superar la tolerancia que admite la regla. Por ello, calcule el importe del impuesto por categoría a partir de la base imponible y el tipo impositivo, tal como prescribe la regla.
Integrar la validación en su software
La validación debe integrarse en cinco puntos de su software y de su proceso de desarrollo.
Antes del envío
Su software debería validar cada factura electrónica inmediatamente después de crearla y detener el envío si hay errores. Sus clientes poco pueden hacer con un ID de regla o una expresión XPath. Por ello, traduzca las reglas que sus clientes pueden corregir por sí mismos en una indicación junto al campo del formulario afectado. La indicación sobre BR-DE-6, el número de teléfono del contacto del vendedor en BT-42, puede decir, por ejemplo: «Indique un número de teléfono para consultas».
Su cliente no puede corregir los errores que se deben a su mapeo o a su lógica de cálculo. Esos errores deberían llegar a su equipo como aviso interno.
En la recepción
Su software debería validar también las facturas electrónicas entrantes y mostrar el resultado junto al documento. Guarde el archivo original sin modificar y el informe de validación como documento propio junto a él. El Ministerio Federal de Finanzas de Alemania exige que al menos la parte estructurada de una factura electrónica se conserve íntegra en su forma original.
Si una factura recibida contiene errores, su cliente puede solicitar al emisor una factura rectificada. Su software puede facilitar este paso, por ejemplo con una consulta preparada al emisor que incluya el informe de validación.
En pruebas automatizadas
Cree una colección de facturas de prueba que cubra sus tipos de factura con sus códigos, por ejemplo 380 para una factura y 384 para una factura rectificativa. Cubra además cada categoría de IVA que utilicen sus clientes. A ello se suman los descuentos y recargos, así como cada sintaxis que genere su software. Incluya también archivos deliberadamente erróneos y compruebe que el validador los rechaza.
El validador de la KoSIT es un programa de código abierto para la línea de comandos y puede integrarse en un pipeline de compilación. La KoSIT ofrece además un conjunto de pruebas con facturas de ejemplo que sirve como punto de partida para su propia colección.
Después de cada actualización de los conjuntos de reglas
Los conjuntos de reglas cambian también sin un nuevo número de versión. La KoSIT publica regularmente para XRechnung 3.0.2 paquetes con correcciones de errores, el último en la versión de 31 de agosto de 2026. XRechnung 3.0 seguirá vigente al menos hasta el 31 de julio de 2027.
La versión preliminar de la especificación XRechnung 4.0 se publicó el 15 de septiembre de 2026. No está destinada expresamente al uso productivo, sino que le ofrece una visión temprana de las funcionalidades nuevas y modificadas. La versión final se publicará previsiblemente en la primavera de 2027 junto con los componentes técnicos.
OpenPeppol publica regularmente nuevas versiones de Peppol BIS Billing 3.0, en los últimos años en mayo y en noviembre. La versión 3.0.21 se publicó el 20 de mayo de 2026 y es obligatoria desde el 17 de agosto de 2026.
Planifique para cada versión una fecha fija en la que valide su colección de pruebas frente a las nuevas reglas. Registre en cada informe de validación con qué versión del validador y del conjunto de reglas se generó. Así podrá reconstruir un resultado incluso si las reglas han cambiado entretanto. Para el cambio a XRechnung 4.0, su entorno de pruebas debería poder comprobar ambas versiones en paralelo.
Evaluar los informes de validación de todos los clientes
Si su software genera facturas electrónicas para muchos clientes, merece la pena evaluar los informes de validación de todos los clientes en conjunto. Si el mismo ID de regla aparece de repente en muchos clientes, la causa está probablemente en el mapeo o en un nuevo conjunto de reglas. Si solo aparece en un cliente, la causa está más bien en sus datos maestros.
Validación con InvoiceRails
Puede implementar usted mismo todos los pasos de este artículo. El esfuerzo inicial es razonable, el continuo no: los conjuntos de reglas, las listas de códigos y las configuraciones de comprobación cambian varias veces al año, y cada cambio debe llegar a sus pruebas, a su envío y a su planificación de versiones.
Por eso, la validación, el envío y el mantenimiento de los conjuntos de reglas también pueden delegarse en un Peppol Access Point certificado como InvoiceRails.
Validador de facturas electrónicas para comprobaciones individuales
El validador de facturas electrónicas de InvoiceRails, gratuito, comprueba archivos XML en UBL y CII, así como facturas PDF híbridas, sin necesidad de registrarse. Reconoce automáticamente la sintaxis, la versión y el perfil, entre ellos XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X y otros perfiles de la EN 16931. A continuación valida el archivo frente al esquema XML y frente a las reglas Schematron y de negocio del perfil reconocido. Puede descargar el informe de validación como PDF o compartirlo mediante un enlace, por ejemplo cuando su equipo de soporte analiza con un cliente una factura rechazada.
API de InvoiceRails en su software
InvoiceRails es el Peppol Access Point certificado por OpenPeppol de fino data services. Su software se conecta a InvoiceRails mediante una API REST y envía y recibe a través de ella facturas electrónicas para cualquier número de clientes, si lo desea en marca blanca.
La API ofrece la validación como endpoint propio, también con reconocimiento automático del perfil. Así, su software puede comprobar las facturas electrónicas inmediatamente después de crearlas. Cada mensaje de la respuesta contiene el ID de regla, el nivel de gravedad, el texto del mensaje y la ubicación como XPath. Su software puede guardar el ID de validación junto con la factura y volver a consultar el resultado durante al menos 90 días.
InvoiceRails valida cada archivo que su software envía a través de Peppol, incluso sin esta llamada. Su software debe comprobar de antemano qué formatos admite un destinatario.
InvoiceRails comprueba también las facturas electrónicas entrantes y entrega a su software el archivo original junto con los datos de factura extraídos. Un webhook notifica a su software cada cambio en el estado de entrega.
Su software sigue encargándose de la asignación de los campos de su modelo de datos, de las indicaciones comprensibles en su interfaz y de las comprobaciones de plausibilidad de los datos obligatorios que ninguna regla cubre.
