XRechnung, ZUGFeRD y BIS Billing 3.0: qué formatos de factura electrónica debería admitir su software

La EN 16931 describe un modelo de datos semántico. Establece qué datos contiene una factura y cómo se relacionan entre sí, por ejemplo el número de factura como BT-1 o la referencia del comprador como BT-10. La norma en sí no es un formato de archivo.

Para la representación técnica admite dos sintaxis: UBL y UN/CEFACT CII. Ambas representan el mismo modelo semántico, pero se diferencian en los nombres de los elementos y en la estructura. Un software que solo lee UBL no puede procesar automáticamente una factura CII, aunque esta sea conforme a la norma.

Para la implementación, esto determina el esfuerzo de mantenimiento. Dos mapeos paralelos significan que cada cambio de reglas debe aplicarse en dos lugares. Quien, en cambio, mapea una sola vez al modelo semántico de la norma y genera a partir de él ambas sintaxis, solo toca un lugar por cada cambio.

En la recepción, a la inversa, el archivo entrante se mapea primero al modelo semántico y desde ahí se traslada a su modelo de datos.

Por encima de la norma se sitúan las especificaciones nacionales y específicas de cada red, denominadas en el estándar Core Invoice Usage Specification, abreviado CIUS. Una CIUS restringe la norma. Hace obligatorios campos opcionales, excluye otros y aporta reglas Schematron propias. Las especificaciones que van más allá del alcance de la norma se denominan Extension.

Independientemente de la sintaxis y la especificación, una factura electrónica se presenta o bien como archivo XML puro, o bien como PDF/A-3 con un archivo XML incrustado. Para el segundo caso se ha impuesto la expresión formato híbrido.

XRechnung es una CIUS de la EN 16931 y la mantiene la Oficina de Coordinación de Estándares TI de Alemania (Koordinierungsstelle für IT-Standards), abreviada KoSIT. Existe en ambas sintaxis. No tiene componente visual; el archivo es XML puro.

XRechnung se exige para las facturas a la Administración federal. La factura se direcciona mediante el Leitweg-ID, que se indica en el conjunto de datos como referencia del comprador.

La vía de presentación depende del destinatario. Entran en consideración los portales ZRE y OZG-RE o un Peppol Access Point. En el B2B, el Leitweg-ID no desempeña ningún papel. Allí, XRechnung es solo uno de varios perfiles admitidos.

Actualmente rige la versión 3.0.2. Para XRechnung 4.0, la implementación de la EN 16931 en su versión de 2026, ya existe una versión preliminar. La versión final de XRechnung 4.0 se publicará previsiblemente en la primavera de 2027.

ZUGFeRD empaqueta un archivo XML según CII en un PDF/A-3. La persona ve el PDF, mientras que el software lee el XML.

La especificación contempla varios perfiles con distinto volumen de datos, de MINIMUM a EXTENDED.

MINIMUM y BASIC WL no contienen una factura completa y no cumplen la norma. A partir del perfil EN 16931, denominado COMFORT en versiones anteriores, la parte estructurada es conforme a la norma. Su software debería leer el perfil al importar y tratar por separado los archivos con MINIMUM o BASIC WL, por ejemplo mediante una revisión manual.

Factur-X es técnicamente casi idéntico a ZUGFeRD.

ZUGFeRD tiene sentido sobre todo cuando sus clientes facturan a destinatarios que siguen revisando las facturas visualmente. En ese caso, solo el XML incrustado es jurídicamente determinante. Si el PDF y el XML difieren, prevalecen los datos de la parte estructurada, según la circular del Ministerio Federal de Finanzas (BMF) de 15 de octubre de 2025.

Por ello, un proceso de aprobación que solo revisa el PDF puede aprobar una factura cuyo contenido determinante es distinto.

En el envío, su software debería generar el PDF y el XML a partir del mismo conjunto de datos, para que no diverjan. En la recepción, debería construir para la revisión una vista propia a partir del XML, en lugar de mostrar el PDF adjunto. El Ministerio Federal de Finanzas de Alemania también recomienda visualizar uno mismo la parte XML.

Peppol BIS Billing 3.0 es también una CIUS de la EN 16931, definida sobre UBL 2.1. OpenPeppol la ha especificado como formato propio para el intercambio de facturas y notas de crédito a través de la red.

Además de las reglas de la norma, aporta reglas Schematron propias. Un archivo puede superar la validación frente a la EN 16931 y fallar en una regla de Peppol. A menudo se trata de listas de códigos o de campos que la red define de forma más estricta que la norma.

La especificación se sigue desarrollando por versiones. Quien valida por su cuenta debería comprobar si sus conjuntos de reglas están actualizados.

A más largo plazo, Peppol avanza hacia PINT, una base armonizada a escala internacional para perfiles de factura fuera de Europa. Para la implementación en Alemania, esto no cambia nada por ahora.

Para estas facturas, su software debe poder generar XRechnung. El Leitweg-ID del destinatario pertenece como campo obligatorio al conjunto de datos de la factura y se emite en la XRechnung como referencia del comprador (BT-10). Si falta o figura en el campo equivocado, el portal de recepción rechaza la factura.

La ley exige una factura conforme a la EN 16931 y deja abierto el formato. Se admiten XRechnung, ZUGFeRD a partir del perfil EN 16931 y también Peppol BIS Billing. El XML incrustado sigue siendo el jurídicamente determinante. Si el PDF y el XML difieren, es posible que el destinatario revise datos distintos de los que tienen validez jurídica.

Desde el 1 de enero de 2025, las empresas nacionales deben poder recibir facturas electrónicas conformes a la EN 16931. Por ello, para una factura electrónica conforme a la norma, el emisor no necesita el consentimiento del destinatario, aunque este prefiera un formato determinado.

Ambas partes solo tienen que ponerse de acuerdo sobre la vía de transmisión y sobre los formatos fuera de la norma. En la práctica, la vía acordada debe figurar por ello en los datos maestros de cada socio comercial.

Además de Peppol BIS Billing 3.0, a través de la red Peppol también pueden transmitirse XRechnung y, desde marzo de 2025, ZUGFeRD como archivo híbrido. Los tipos de documento que un destinatario ha registrado en el servicio de directorio muestran qué formatos acepta. Antes del envío, su software debe consultar este registro y elegir el formato adecuado. Para comprobaciones individuales, la búsqueda de ID Peppol lo muestra sin necesidad de registrarse.

En la operación diaria, su software debería realizar esta consulta automáticamente antes del envío, ya sea directamente a través de los servicios de directorio SML y SMP o a través de la API de su Peppol Access Point. A partir de ello se determina un formato admitido por ambas partes y se genera la factura electrónica en ese formato.

Las facturas entrantes llegan en el formato que ha elegido el emisor. Por ello, su software debería poder leer ambas sintaxis, UBL y CII, y con ello también XRechnung en ambas variantes. A esto se suman ZUGFeRD y Factur-X como archivos híbridos y, en cuanto sus clientes reciban facturas del extranjero, los perfiles habituales allí.

Cada archivo entrante contiene un identificador de la especificación que utiliza. En UBL figura en el elemento cbc:CustomizationID; en CII, en el parámetro de contexto de la directriz. Su software debería leer primero este identificador, porque de él depende qué reglas de validación se aplican y cómo se traslada el archivo a su modelo de datos.

Algunos Peppol Access Points le ahorran este paso. Comprueban el archivo entrante, extraen los datos de la factura y los entregan junto con el archivo original como un conjunto de datos uniforme.

Su software debería cubrir por completo la recepción antes que el envío, es decir, ambas sintaxis y los formatos híbridos, porque sus clientes ya deben poder recibir facturas electrónicas hoy.

El envío será obligatorio para sus clientes en dos fases. A partir del 1 de enero de 2027, con una facturación total superior a 800.000 euros en el año anterior, y a partir del 1 de enero de 2028 para todas las demás operaciones B2B nacionales.

Quien empieza con la sintaxis CII puede generar con ella XRechnung en la variante CII y ZUGFeRD. UBL será necesario en cuanto los destinatarios de la red Peppol esperen Peppol BIS Billing 3.0, porque este formato requiere UBL.

Todos los datos obligatorios a efectos del IVA deben figurar de forma legible por máquina en la parte estructurada de la factura electrónica. Esto incluye también la descripción de la prestación. Una referencia a un anexo, a un albarán o a un enlace no sustituye a un campo obligatorio. La base son las preguntas frecuentes del Ministerio Federal de Finanzas de Alemania sobre la factura electrónica y la circular del BMF de 15 de octubre de 2025.

La razón está en la estructura de la factura electrónica. En los formatos híbridos como ZUGFeRD, los datos del XML son los que prevalecen; el PDF es solo una vista. Por ello, un dato que solo es visible en el PDF no cuenta.

Si falta un dato obligatorio en la parte estructurada, la factura se considera incorrecta y la deducción del IVA soportado del destinatario puede verse comprometida. Sus clientes lo notarán, a más tardar, cuando los socios comerciales rechacen las facturas por este motivo.

Muchas plantillas de factura transmiten datos obligatorios como bloques de texto que solo aparecen en el PDF. A menudo esto afecta a la descripción de la prestación, por ejemplo «según la oferta 2026-114», al período de prestación en el pie de la factura y a la indicación de inversión del sujeto pasivo.

En el modelo de datos, cada uno de estos datos debería tener un campo propio a partir del cual se rellene el XML. El período de prestación corresponde a los campos del período de facturación (BG-14) y la indicación de inversión del sujeto pasivo, a la categoría fiscal con motivo de exención (BT-120 y BT-121).

La validación técnica comprueba si los campos obligatorios de la norma están presentes y rellenados de forma formalmente correcta. No detecta si una descripción de la prestación es suficiente a efectos del IVA. Por tanto, una factura puede superar la validación y aun así contener un dato obligatorio de forma insuficiente.

Los albaranes, los partes de horas y otra documentación que acompaña a la factura pueden incrustarse como anexo en la factura electrónica, en la EN 16931 mediante el grupo de documentos justificativos adicionales (BG-24). Esto sustituye al envío por separado y mantiene la factura y el justificante juntos en un solo archivo.

Una XRechnung se valida frente a dos conjuntos de reglas: las reglas de la EN 16931 y las reglas adicionales de la KoSIT. Para Peppol BIS Billing 3.0 ocurre lo mismo con las reglas de OpenPeppol. Por ello, una validación únicamente frente a la norma dice poco sobre si el destinatario aceptará el archivo. Su software debería validar frente al conjunto de reglas de la especificación que espera el destinatario.

La KoSIT y OpenPeppol publican regularmente nuevas versiones de sus conjuntos de reglas con listas de códigos y reglas Schematron adaptadas. Si su software no mantiene actualizados los conjuntos de reglas, pueden rechazarse facturas que hasta ahora se aceptaban. El rechazo viene entonces del destinatario, pero la causa está en el propio conjunto de reglas obsoleto.

Para las pruebas durante el desarrollo, pueden comprobarse archivos individuales con el validador de facturas electrónicas gratuito frente a la EN 16931 y las reglas de Peppol. Para la comprobación automática en producción, InvoiceRails ofrece la validación también a través de una API, frente a la EN 16931 y perfiles como XRechnung, ZUGFeRD y Peppol BIS Billing. El informe de validación indica por separado los errores, las advertencias y las indicaciones.

Un mapeo se construye una vez; las reglas de validación que hay detrás pueden cambiar varias veces al año. El próximo gran cambio ya está a la vista con XRechnung 4.0 y la EN 16931 en su versión de 2026.

La versión de 2026 se basa en UBL 2.5. En las implementaciones conformes, UBL 2.5 solo podrá utilizarse cuando el CEN haya publicado un binding de sintaxis actualizado. Hasta entonces se aplican los bindings existentes basados en UBL 2.1. Por tanto, los proveedores pueden preparar el cambio, pero todavía no implementarlo.

Quien construye la conexión por su cuenta asume este mantenimiento de forma permanente. Esto incluye mantener actualizados los mapeos para ambas sintaxis, las listas de códigos y las reglas Schematron, y seguir los calendarios de versiones de la KoSIT, el FeRD, OpenPeppol y el CEN. Es factible, pero consume tiempo de desarrollo que falta en el propio producto.

Como alternativa, el mantenimiento de formatos puede externalizarse a un Peppol Access Point. InvoiceRails, el Access Point certificado por OpenPeppol de fino data services, cubre a través de una API más de 60 formatos, entre ellos XRechnung, ZUGFeRD y Factur-X, y mantiene de forma continua las reglas de validación y las actualizaciones de formato.

Los proveedores conectan el envío y la recepción una sola vez y ponen la función a disposición de cualquier número de sus clientes, si lo desean con su propia marca. El mapeo de los propios datos de factura a la interfaz sigue en manos del proveedor, al igual que los campos obligatorios en el propio modelo de datos.

Cómo incorporan los proveedores de software la factura electrónica a su propio producto se explica en el artículo sobre la factura electrónica para proveedores de software.