XRechnung o ZUGFeRD: cómo elegir el formato correcto (y los perfiles que fallan)
La obligación alemana acepta XRechnung y ZUGFeRD, pero no todo ZUGFeRD. Los perfiles Minimum y Basic-WL no cumplen EN 16931. Cómo elegir y cómo validar antes de enviar.
XRechnung o ZUGFeRD: cómo elegir el formato correcto (y los perfiles que fallan)
La obligación alemana de factura electrónica no prescribe un único formato. Prescribe un estándar: EN 16931. Dos formatos dominan el espacio conforme. Elegir entre ellos es una decisión de flujo de trabajo, no de cumplimiento. Elegir el perfil de ZUGFeRD equivocado es un fallo de cumplimiento.
Los dos formatos
XRechnung
El estándar oficial alemán: un archivo XML puramente estructurado, definido como la especificación de uso núcleo (CIUS) alemana de EN 16931. Disponible en dos sintaxis, ambas igual de válidas:
- UBL (Universal Business Language)
- UN/CEFACT CII (Cross Industry Invoice)
XRechnung es máquina primero. No hay capa legible para personas; la visualización la genera el software del receptor. Es obligatorio para facturación B2G a la administración federal desde 2020, lo que lo convierte en el formato por defecto en sectores que trabajan con el sector público.
ZUGFeRD
Un formato híbrido: un PDF/A-3 legible con el XML estructurado incrustado dentro. El destinatario ve una factura normal; su software extrae el XML.
Para cumplir la obligación, ZUGFeRD debe ser versión 2.0.1 o posterior con un perfil conforme a EN 16931:
- Perfil EN 16931 (Comfort): totalmente conforme
- Perfil Extended: conforme, con datos adicionales sobre el estándar
- Perfil XRechnung: el modelo de datos de XRechnung dentro del contenedor híbrido
La trampa de los perfiles
ZUGFeRD se distribuye en perfiles con distinto contenido de datos. Dos de ellos no cumplen la obligación:
| Perfil | ¿Conforme? | Motivo |
|---|---|---|
| Minimum | No | Contenido de datos insuficiente para EN 16931 |
| Basic-WL | No | Contenido de datos insuficiente para EN 16931 |
| Basic | No | Por debajo de los requisitos de EN 16931 |
| EN 16931 (Comfort) | Sí | Conformidad plena con el estándar |
| Extended | Sí | EN 16931 más extensiones |
Una factura emitida como ZUGFeRD Minimum o Basic-WL es una "sonstige Rechnung": legalmente no es una factura electrónica. Pasados los períodos transitorios, no da derecho a deducción del IVA soportado al comprador. La trampa: el archivo sigue pareciendo una factura PDF normal. Nadie lo nota hasta una validación o una auditoría.
El marco de decisión
| Su situación | Formato adecuado |
|---|---|
| Máxima automatización; clientes grandes o sector público | XRechnung |
| Destinatarios también pequeños negocios que leen facturas a mano | ZUGFeRD (perfil EN 16931) |
| Factura a administraciones públicas | XRechnung (ya obligatorio en B2G) |
| Interoperabilidad con muchos socios y países | XRechnung UBL o Peppol BIS 3.0 |
| Relaciones EDI existentes con volumen | Mapeo EDI alineado con EN 16931 (transitorio) |
La naturaleza híbrida de ZUGFeRD es su verdadera ventaja: un archivo sirve al ojo del contable y a su software. El XML puro de XRechnung es su ventaja: sin ambigüedad sobre qué capa es la autoritativa. Tenga en cuenta que según la GoBD, la parte estructurada es el registro autoritativo en ambos casos.
Validar antes de enviar
La taxonomía de errores del mandato distingue dos tipos de fallo:
- Errores de formato: el archivo viola la sintaxis o las especificaciones técnicas. Una factura electrónica formalmente defectuosa no es una factura electrónica según el artículo 14 (1) frase 6 UStG; la deducción del IVA sobrevive solo durante los períodos transitorios.
- Errores de reglas de negocio: el XML está bien formado pero viola reglas lógicas. El caso clásico: el campo obligatorio BT-10 (referencia del comprador) vacío en una XRechnung. Otro: el importe de impuesto declarado no coincide con el calculado. Los validadores los detectan como errores críticos.
El validador KoSIT es la herramienta de referencia. El flujo:
- Genere una factura de muestra desde su sistema de producción, no desde una plantilla de prueba.
- Pásela por el validador KoSIT.
- Corrija en la fuente de datos (datos maestros, lógica del formulario), nunca editando el XML a mano.
- Revalide y envíe.
La BStBK recomienda a los receptores validar igualmente cada factura electrónica entrante: sintaxis, semántica y conformidad con las extensiones nacionales. Una factura inválida recibida es un asunto para plantear al emisor de inmediato, no para contabilizar y descubrir después.
Errores habituales
Asumir que "ZUGFeRD" significa conforme. El perfil decide. Compruebe qué perfil genera realmente su software.
Editar a mano la capa PDF de un ZUGFeRD. La capa visual y el XML deben coincidir. Editar una desincroniza el archivo; la parte estructurada es la legalmente relevante.
Tratar la validación como problema del receptor. Un error de formato en una factura que usted emite tras su fecha de obligación es su fallo de cumplimiento y el problema de IVA de su cliente.
Olvidar el BT-10. Las grandes empresas y el sector público enrutan las facturas por la referencia del comprador. Si falta, hay rechazos aunque el XML sea técnicamente válido.
Este material es información de carácter general y no constituye asesoramiento legal ni fiscal. Para una situación concreta, verifique la normativa vigente o consulte a un asesor cualificado.