La E-Rechnung obligatoria en Alemania: emitir facturas estructuradas desde tus propios sistemas antes del 1 de enero de 2027

Desde el 1 de enero de 2027, una empresa alemana cuyo volumen de negocio en 2026 haya superado los 800.000 € ya no puede enviar una factura en papel o en PDF a otra empresa alemana. La factura tiene que ser una factura electrónica estructurada: un fichero de datos construido según la norma europea EN 16931. Desde el 1 de enero de 2028 desaparece el umbral y la regla se aplica a todas las empresas, salvo unas pocas excepciones muy concretas.

Para una empresa pequeña, esto llega como una actualización de software. Para una empresa cuyas facturas salen de su propio sistema de facturación, de un paquete sectorial o de un ERP personalizado durante quince años, es un proyecto de software, y quedan unas trece semanas. Este artículo es para el segundo grupo.

Qué dice la ley

La definición está en el § 14 UStG: una factura «die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht». El formato tiene que ajustarse a la norma europea prevista en la Directiva 2014/55/UE (en la práctica, la EN 16931), o haberse acordado entre las partes, siempre que los datos exigidos puedan extraerse de forma correcta y completa a un formato compatible con esa norma. Un PDF no cumple, por muy ordenado que esté.

La obligación cubre las entregas y prestaciones a otra empresa cuando ambas partes están establecidas en Alemania. El régimen transitorio está en el § 27 Abs. 38 UStG:

• Las operaciones realizadas en 2025 y 2026 pueden seguir facturándose en papel, o en otro formato electrónico si el cliente lo acepta, siempre que la factura se envíe a más tardar el 31 de diciembre de 2026.
• Las operaciones realizadas en 2027 disfrutan del mismo margen hasta el 31 de diciembre de 2027, pero solo si el volumen de negocio total del emisor en el año natural anterior no superó los 800.000 €.
• El EDI que no cumpla la norma puede seguir usándose para operaciones realizadas en 2027, con el acuerdo del cliente, sea cual sea tu tamaño.

Hay tres detalles que importan más de lo que parece.

El umbral se mide sobre el volumen de negocio del año anterior. Tu situación en 2027 depende de tu cifra de 2026, que nadie conocerá con exactitud hasta el cierre contable. Si estás cerca de los 800.000 €, desarrolla como si estuvieras por encima.

El margen termina en una fecha de envío. Leída literalmente, la primera regla transitoria deja de amparar el papel y el PDF el 31 de diciembre de 2026, incluso para trabajos realizados en 2026. Si estás por encima del umbral y facturas a mes vencido, la factura que envías la primera semana de enero por el trabajo de diciembre ya tiene que ser estructurada. Confírmalo con tu asesor fiscal, pero no planifiques el arranque para mediados de enero.

Algunas facturas quedan fuera del ámbito: las facturas a consumidores, las facturas transfronterizas, las facturas de pequeño importe de hasta 250 € brutos, los billetes que valen como factura, las facturas de Kleinunternehmer (el régimen alemán de franquicia para pequeños empresarios) y las operaciones exentas según el § 4 Nr. 8 a 29 UStG.

No nos consta ningún proyecto de ley para mover estas fechas. Planifica como si se mantuvieran.

Recibir es obligatorio desde 2025. Emitir es lo nuevo.

Desde el 1 de enero de 2025, toda empresa alemana tiene que poder recibir facturas electrónicas. Las preguntas frecuentes sobre la factura electrónica del Ministerio Federal de Hacienda son tajantes sobre lo que hace falta: «Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.» Basta con un buzón de correo.

Fíjate en una línea del propio § 14: cuando se aplica la obligación de factura electrónica, no hace falta el consentimiento del destinatario. Un cliente empresarial alemán no puede rechazar tu factura estructurada.

Emitir es otro problema. Cuando recibes, una herramienta lee el fichero de otro. Cuando emites, tu sistema es el autor: si los datos están mal en origen, nadie más adelante en la cadena puede repararlos, y una factura que no supera la validación de tu cliente se queda sin cobrar.

A quién le llega esto con una actualización

Sin rodeos: si eres una empresa pequeña que factura con DATEV, lexoffice, sevDesk o un paquete parecido, tu proveedor de software te da el formato. Revisa tus datos maestros (NIF-IVA, direcciones de clientes, datos bancarios), activa la función y envía una factura de prueba. No necesitas un proyecto ni una empresa de software.

Algo muy parecido ocurre con un ERP de los grandes que siga cerca del estándar: el fabricante o tu partner aporta la salida, y el trabajo es configuración y pruebas.

El resto de este artículo es para empresas cuyas facturas salen de código propio, o de código que ya nadie mantiene:

• motores de facturación de plataformas de suscripción, marketplaces y empresas de suministros, que emiten facturas por programa y en volumen;
• software sectorial de distribución mayorista, construcción, logística o servicio técnico, cuyo proveedor es pequeño, lento o ya no existe;
• ERP cuya salida de facturas se reescribió hace años como programas de impresión a medida, plantillas de informe o una combinación de correspondencia a fin de mes.

Los formatos: EN 16931, XRechnung y ZUGFeRD

EN 16931 es la norma europea. Define el modelo semántico de una factura (los campos, su significado, cuáles son obligatorios y las reglas de negocio entre ellos) y lo vincula a dos sintaxis XML, UBL 2.1 y UN/CEFACT CII.

XRechnung es la especificación alemana construida sobre la EN 16931 y mantenida por KoSIT: XML puro en cualquiera de las dos sintaxis, exigido por las administraciones públicas e igual de válido entre empresas. Según la página de XRechnung de KoSIT, la versión 3.0 está vigente desde el 1 de febrero de 2024 y lo seguirá estando al menos hasta el 31 de julio de 2027. En septiembre de 2026 se publicó una versión preliminar de la 4.0, y la versión definitiva se espera para la primavera de 2027. Arrancarás con la 3.0 y actualizarás dentro de tu primer año.

ZUGFeRD es un formato híbrido: un fichero PDF/A-3 con XML CII incrustado. Las personas leen el PDF; las máquinas leen el XML. En Francia el mismo formato se llama Factur-X, y técnicamente son idénticos. FeRD publicó la versión 2.5.2 el 4 de agosto de 2026. ZUGFeRD se presenta en perfiles (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), y las preguntas frecuentes del Ministerio aceptan ZUGFeRD a partir de la versión 2.0.1 «mit Ausnahme der Profile MINIMUM und BASIC-WL».

En una factura híbrida manda el XML. Las preguntas frecuentes llaman a la parte estructurada «führender Teil», la parte que prevalece. Si el PDF y el XML no coinciden, el que está mal es el PDF.

Para la mayoría de los emisores B2B alemanes, la opción por defecto sensata es ZUGFeRD con el perfil EN 16931, para que los clientes que siguen leyendo las facturas a ojo puedan continuar haciéndolo, más XRechnung para las administraciones públicas y para quien lo pida. Ambos deberían salir de un único objeto de factura interno, no de dos ramas de código.

Qué tiene que cambiar en tu sistema

La factura pasa a ser datos, no una maquetación

Muchos sistemas antiguos construyen la factura al imprimirla: texto concatenado en una plantilla, totales sumados dentro del informe y la mención del IVA como un párrafo fijo en el código. Nada de eso sobrevive a la EN 16931. Necesitas un objeto de factura almacenado que contenga todos los campos, y que tanto el XML como el PDF se generen a partir de él.

Los campos que suelen faltar o estar mal:

• Datos de las partes. Direcciones estructuradas con códigos de país ISO, y un NIF-IVA o número fiscal. Los bloques de dirección en texto libre hay que separarlos.
• Fecha de la entrega o periodo de la prestación, guardados como datos y no como una frase en la cabecera.
• Unidades. Cada cantidad necesita un código de la Recomendación 20 de la CEPE/ONU (H87 para pieza, KGM para kilogramo, DAY para día). «Stk.» y «pauschal» hay que mapearlos.
• IVA. Cada línea lleva una categoría y un tipo de IVA. La factura lleva un desglose de IVA por cada combinación de categoría y tipo, y los totales tienen que cuadrar exactamente a dos decimales. Los sistemas que redondean el IVA por línea fallan aquí.
• Menciones de exención e inversión del sujeto pasivo. La frase al pie del PDF pasa a ser un código de categoría de IVA más un motivo de exención.
• Pago. Medio de pago, IBAN y condiciones en forma estructurada.
• Referencias. El número de pedido o la referencia del comprador con la que concilia el departamento de cuentas a pagar de tu cliente. Si nunca la guardaste, empieza a recogerla ya.

Las líneas que solo contienen texto («entrega según lo acordado») son un tropiezo habitual. En una factura estructurada, una línea es una línea facturable, así que ese texto va en una nota.

Correcciones, notas de abono y autofacturación

Las preguntas frecuentes lo dicen expresamente: cuando se aplica la obligación de factura electrónica, una corrección también tiene que ser una factura electrónica, con el tipo de factura propio de una corrección. En la EN 16931 remite a la factura anterior por número y fecha de emisión, así que tu sistema tiene que conservar ese vínculo como dato.

Cuidado con el vocabulario. En la normativa alemana del IVA, una «Gutschrift» es una autofactura: la emite el cliente, previo acuerdo (§ 14 Abs. 2 UStG). Lo que en español llamaríamos una nota de abono (una rebaja de precio o una anulación) es una corrección. Muchos sistemas usan un mismo tipo de documento para ambas cosas. Sepáralos antes de mapearlos y, si autofacturas a proveedores, trata esos documentos como facturas que emite tu sistema.

Una factura final puede relacionar los pagos parciales anteriores en un anexo, siempre que la parte estructurada haga referencia a él; las preguntas frecuentes confirman que esto sigue siendo así después de 2027.

Validar antes de que salga nada

KoSIT publica un validador de código abierto que comprueba el XML contra esquemas y reglas Schematron, con una configuración pública para XRechnung. Se ejecuta desde la línea de comandos, como demonio HTTP o como biblioteca. Ponlo en la ruta de envío: cada factura se valida antes de salir, y un fallo va a una cola de la que es responsable una persona con nombre y apellidos, indicando qué campo ha incumplido qué regla.

Para ZUGFeRD, valida el XML incrustado contra las reglas de tu perfil, comprueba por separado el contenedor PDF/A-3 y confirma que el PDF muestra los mismos totales que el XML.

Transmisión

La ley, según las preguntas frecuentes, «sieht keinen bestimmten Weg vor»: no impone ningún canal. El correo electrónico con el fichero adjunto vale. También una API, un portal de descarga, un almacenamiento compartido dentro de un grupo o (el ejemplo del propio Ministerio) una memoria USB. Peppol no es obligatorio para el B2B nacional en Alemania.

El trabajo de ingeniería es por cliente: una dirección de facturación, un formato preferido y un registro de qué se envió adónde. Un reintento tras un envío fallido lleva el mismo documento con el mismo número de factura. Dos números para una misma operación son un problema fiscal, no de software.

Archivo

Al menos la parte estructurada tiene que conservarse «unversehrt in seiner ursprünglichen Form», íntegra en su forma original, y el § 14b UStG fija la conservación en ocho años desde el final del año de emisión. Guarda exactamente los bytes que enviaste, con un hash. No cuentes con regenerar las facturas desde la base de datos más adelante: para entonces los datos y el código habrán cambiado. Lo mismo vale para las facturas electrónicas que recibes.

Un plan para octubre a diciembre de 2026

Trece semanas bastan para un desarrollo bien acotado si los datos de origen están en un estado razonable. No bastan para sustituir el sistema de facturación.

Semanas 1 y 2: inventario y decisiones. Haz una lista de todos los puntos donde se genera una factura, incluidas las notas de abono manuales, las facturas finales de proyecto y la hoja de cálculo de ese gran cliente. Compara el volumen de negocio de 2026 con el umbral. Elige el formato por defecto y decide si desarrollas el generador o envías los datos de factura a la API de un proveedor de facturación electrónica.

Semanas 2 a 4: análisis de carencias en los datos. Mapea campo a campo tres meses de facturas reales contra la EN 16931. Marca lo que falta, lo que tiene que convertirse en código y lo que se calcula de otra manera. Aquí es donde se ve el tamaño real del proyecto.

Semanas 4 a 9: desarrollo. El objeto de factura, el mapeo, la generación de XML y de PDF/A-3, el validador en la ruta de envío, la cola de errores y el archivo. En paralelo, alguien depura los datos maestros y recoge de los clientes sus direcciones de facturación.

Semanas 9 a 11: reproducción y piloto. Pasa las facturas de los últimos tres meses por el nuevo generador y valídalas todas. Después haz un piloto con algunos clientes dispuestos y pregúntales si sus sistemas leen los ficheros.

Semanas 11 a 13: congelación y procedimiento operativo. Congela los cambios en diciembre. Deja por escrito quién es responsable de la cola de errores, cómo se emite una corrección y qué ocurre cuando un cliente rechaza una factura. Las facturas de enero por trabajos de diciembre ya entran en el ámbito.

Enero de 2027. Arranca, y vigila la cola a diario durante el primer cierre de mes y la primera declaración de IVA.

A lo largo de 2027. Planifica la actualización a XRechnung 4.0 antes de que la 3.0 deje de ser válida, y pasa al nuevo sistema a las empresas del grupo que estén por debajo del umbral antes del 1 de enero de 2028.

Si empiezas tarde, recorta la automatización, no la validez de lo que sale: automatiza primero los tipos de factura de mayor volumen y envía los documentos poco frecuentes a mano con una herramienta de facturación electrónica durante unas semanas.

Dónde conseguir ayuda

Construimos la conexión entre el sistema que genera tus facturas y el formato que exige la ley: cambios en el modelo de datos, mapeo, validación, transmisión y archivo, en tu código y junto a tu equipo. Nuestro servicio de integración de facturación electrónica explica cómo funcionan esos proyectos; si la obligación te llega en mitad de un cambio de ERP, consulta modernización de ERP. El calendario completo está en nuestra guía de cumplimiento digital de la UE 2026.

Somos ingenieros, no asesores fiscales: las preguntas de alcance le corresponden a tu Steuerberater, y nosotros desarrollamos según su respuesta. Cuéntanos qué genera hoy tus facturas y cuántas salen aproximadamente cada mes: escribe a office@c9group.dev.