Su mensaje ha sido enviado.
Procesaremos su solicitud y nos pondremos en contacto con usted lo antes posible.
El formulario se ha enviado correctamente.
Encontrará más información en su buzón.
Seleccionar idioma
24 de agosto de 2026
10 minutos de lectura

Los requisitos alemanes en materia de facturación electrónica pueden hacer que un proceso de facturación con el que ya estás familiarizado parezca, de repente, un proyecto IT mucho más complejo. Si tu ERP ya funciona bien, lo último que quieres es tener que reestructurarlo solo para que admita otro formato de factura.
Por eso yo empezaría por lo que ya tienes. Algunos sistemas ERP pueden generar facturas electrónicas estructuradas mediante módulos integrados, API o componentes específicos para cada país. Otros siguen generando archivos PDF estándar y requieren un paso de conversión adicional. Una vez que sepas en qué situación se encuentra tu sistema, resultará mucho más fácil elegir una configuración ZUGFeRD que cumpla los requisitos sin introducir cambios innecesarios en el proceso central de facturación.

Arquitecto visionario, Dmitry tiende puentes entre la innovación bruta y la viabilidad comercial. Supervisa la hoja de ruta tecnológica de la empresa y se asegura de que cada solución se construya sobre una pila que resuelva problemas empresariales inmediatos.
ZUGFeRD es un formato híbrido de factura electrónica. Una factura ZUGFeRD combina un documento PDF/A-3 legible para el ser humano con código XML estructurado incrustado que los programas de contabilidad pueden procesar directamente.
El archivo XML contiene datos de factura definidos, como la información del vendedor y del comprador, las líneas de factura, los códigos taxe, los totales, los datos de pago y las referencias. En el caso de la facturación electrónica alemana, la versión y el perfil de ZUGFeRD seleccionados son tan importantes como el propio archivo.
ZUGFeRD cuenta con cinco perfiles principales, además del perfil de referencia XRECHNUNG, y estos difieren tanto en el alcance de los datos como en su uso normativo. Para una implementación B2B alemana típica basada en la norma EN 16931, yo solería empezar con el perfil EN 16931 y pasar al EXTENDED cuando el proceso empresarial requiriera datos estructurados adicionales.
| Perfil | Qué incluye | Situación en Alemania |
|---|---|---|
| MÍNIMO | Información básica sobre el comprador, el vendedor, los totales y los impuestos | No se reconoce como una factura UStG completa |
| BASIC WL | Información contable del encabezado sin partidas de factura | No se reconoce como una factura UStG completa |
| BÁSICO | Subconjunto de la norma EN 16931 para facturas más sencillas | Reconocida como una factura completa conforme a la UStG |
| EN 16931, anteriormente COMFORT | Modelo completo de factura básica según la norma EN 16931 | Reconocida como una factura UStG completa y la opción principal para la facturación electrónica conforme a la normativa de la UE |
| AMPLIADO | EN 16931, además de datos adicionales para procesos empresariales más complejos | Reconocida como una factura completa conforme a la UStG |
| XRECHNUNG | Perfil de referencia basado en los requisitos de XRechnung de KoSIT | Es especialmente relevante en los casos en los que se aplican los requisitos de XRechnung, en particular en el ámbito B2G |
FeRD recomienda expresamente la norma EN 16931 para las facturas electrónicas conformes con la normativa de la UE. El Ministerio Federal de Hacienda alemán también afirma que ZUGFeRD, a partir de la versión 2.0.1, puede cumplir los requisitos alemanes en materia de facturación electrónica, con la excepción de los niveles «MINIMUM» y «BASIC-WL».
Por lo tanto, la selección del perfil debe realizarse en una fase temprana. Elegir «MÍNIMO» porque contiene los importes básicos, por ejemplo, no convierte el documento en una factura electrónica alemana conforme a la normativa.
Yo no consideraría esto como una norma según la cual todas las facturas alemanas deban utilizar ZUGFeRD. El ámbito de aplicación sigue dependiendo de la operación. Las facturas B2C, algunas operaciones exentas, las facturas de escaso valor y otros casos especiales pueden regirse por normas diferentes.
Un PDF estándar contiene información destinada principalmente a la lectura humana. Una factura electrónica estructurada también proporciona al software de contabilidad campos definidos que pueden leerse automáticamente.
Una persona podría ver:
Una factura estructurada desglosa los importes que la componen, de modo que el programa informático pueda distinguir qué importe corresponde a la base imponible, al IVA, al total bruto y al importe a pagar.
Esa distinción permite que los sistemas ERP y de contabilidad procesen las facturas sin tener que reconstruir su significado a partir del texto o el diseño de página del PDF.
Antes de implementar un conversor, comprueba si el ERP ya ofrece funciones de facturación electrónica específicas para cada país, API o módulos de documentos.
Normalmente hay tres rutas:
Los entornos SAP, por ejemplo, pueden utilizar funcionalidades específicas de cada país a través de SAP Document and Reporting Compliance. Otros sistemas ERP o personalizados pueden requerir middleware o un servicio de conversión independiente.
Por lo tanto, un conversor independiente es la opción más acertada cuando no existe una compatibilidad nativa adecuada o cuando modificar la aplicación principal de facturación supondría un riesgo innecesario para el proyecto.
En el caso de un proceso basado en PDF, el flujo de conversión podría ser el siguiente:
Siempre que sea posible, los datos estructurados de un sistema ERP son una fuente más fiable que los valores reconstruidos a partir del PDF. Los formatos JSON, XML y CSV, así como los registros de bases de datos o los datos de API, conservan el significado de los campos de las facturas y reducen los errores de interpretación.
La creación del XML requiere una asignación semántica correcta. El conversor debe identificar qué representa cada valor de la factura y colocarlo en el campo estructurado correspondiente.
El precio es sencillo. Otros campos requieren más contexto: los identificadores del vendedor y del comprador, el tipo de factura, las categorías fiscales, los códigos de unidad, las bonificaciones, los recargos, las referencias, las condiciones de pago, la información de entrega y el desglose del IVA pueden influir en el XML.
| Importe de la factura | Término de la norma EN 16931 |
|---|---|
| Número de factura | BT-1 |
| Fecha de emisión | BT-2 |
| Moneda | BT-5 |
| Nombre del vendedor | BT-27 |
| Nombre del comprador | BT-44 |
| Importe neto de la línea | BT-131 |
| Total sin IVA | BT-109 |
| Total del IVA | BT-110 |
| Total, IVA incluido | BT-112 |
| Importe a pagar | BT-115 |
La mayor parte del trabajo de implementación se centra en este modelo de datos y en su validación. El sistema debe mapear correctamente los datos de origen, generar un XML válido, empaquetarlo en formato PDF/A-3 y mantener la coherencia entre ambas representaciones.
Yo revisaría la factura en varias etapas:
Por ejemplo:
El conversor debería calcular y comparar estos valores, en lugar de copiar cadenas formateadas del PDF.
También comprobaría el archivo PDF/A-3 final una vez que se haya incrustado el XML. El proceso de empaquetado modifica el documento, por lo que limitarse a comprobar el PDF original no garantiza que el resultado final sea el esperado.
Antes de enviarlo, compararía el número de factura, las fechas, las partes, la moneda, los importes de las partidas, la información fiscal, los totales, los datos de pago y las referencias entre los archivos PDF y XML.
Podemos ayudarte a evaluar tu configuración actual de ERP, definir el flujo de datos de facturación adecuado e implementar la facturación electrónica en los sistemas que ya utilizas.
Su mensaje ha sido enviado.
Procesaremos su solicitud y nos pondremos en contacto con usted lo antes posible.