Factura ZUGFeRD con n8n: así la generás con PDF4me

En pocas palabras: Desde el 1 de enero de 2025, Alemania exige facturas electrónicas B2B con XML. La forma más simple de generarlas es con el nodo ‘Create ZUGFeRD Invoice’ de PDF4me en n8n: produce un PDF/A-3 con datos estructurados en XML según la norma EN 16931.

Si facturás a empresas alemanas, tu PDF bonito con membrete ya no alcanza. Desde el 1 de enero de 2025, la legislación alemana exige que las facturas B2B sean procesables por software sin intervención humana. La solución es ZUGFeRD: un PDF que muestra la factura normalmente pero trae adentro un XML con todos los datos estructurados. Y la forma más directa de generarlo sin meter mano en código es usando el nodo Create ZUGFeRD Invoice de PDF4me dentro de n8n. Un solo archivo, dos lecturas posibles, cero fricción con el compliance alemán.

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) es un formato de factura electrónica híbrido que cumple con la norma europea EN 16931: un PDF/A-3 visible para humanos que contiene, como archivo adjunto incrustado, un XML estructurado con los mismos datos que cualquier sistema contable puede parsear automáticamente. PDF4me, el servicio cloud de manipulación de PDFs, integró un nodo dedicado en n8n para crear estas facturas sin necesidad de escribir una línea de código.

n8n es un sistema de automatización de flujos de trabajo de código abierto, desarrollado por N8n GmbH, que permite conectar aplicaciones y servicios web sin necesidad de escribir código, facilitando la integración y automatización de procesos empresariales.

¿Qué es ZUGFeRD y por qué es obligatorio en Alemania desde 2025?

ZUGFeRD es la implementación alemana de la norma europea EN 16931 para facturación electrónica, con un hermano casi gemelo en Francia llamado Factur‑X. La legislación alemana lo volvió obligatorio para todas las transacciones B2B a partir del 1 de enero de 2025. Si tu empresa emite facturas a clientes alemanes, el formato no se negocia: el PDF híbrido con XML incrustado es el piso.

Ojo, acá hay una distinción que en la práctica se pasa por alto: la ley no prohíbe mandar un PDF legible por humanos (todo lo contrario, lo exige), sino que obliga a que además ese PDF lleve una versión estructurada de sí mismo. El receptor elige cómo leerlo. La máquina parsea el XML; la persona mira el PDF. El mismo archivo, dos públicos, un solo envío.

La versión que corre hoy es ZUGFeRD 2.x (la 1.0 está obsoleta y ningún sistema moderno debería aceptarla). Si estás arrancando, apuntá directo al perfil EN16931 —es el que cubre el 95% de los casos— y dejá XRECHNUNG solo si facturás al sector público alemán, que tiene requisitos adicionales bastante quisquillosos. Ya lo cubrimos antes en integrar n8n con Airtable.

¿Cómo funciona una factura que es PDF y XML al mismo tiempo?

Pensalo como un sobre de dos caras: el frente es el PDF/A‑3b que vos ves con el logo, los totales, los plazos de pago y todo lo que esperás de una factura común. El dorso es un archivo XML —generalmente llamado invoice‑data.xml— que viaja como attachment dentro del mismo documento PDF, con cada campo tipado y estructurado según el esquema de ZUGFeRD: número de factura, líneas de ítem, tasas de IVA, totales, datos del comprador y vendedor, y un larguísimo etcétera.

La clave técnica es el estándar PDF/A‑3, que a diferencia de PDF/A‑1 o PDF/A‑2 permite incrustar archivos de cualquier formato (en este caso, XML) sin romper la conformidad con el estándar de archivo. El PDF se abre en cualquier lector; el XML lo extraen los sistemas contables automatizados. Lo que para un humano es un documento que “se ve bien”, para el ERP del comprador es un paquete de datos que se ingesta en segundos, sin retipeo, sin errores de interpretación, sin un administrativo alemán maldiciendo en voz baja mientras copia números de un PDF escaneado (sí, en 2026 todavía pasa).

¿Y qué pasa si abrís el PDF en Acrobat y vas a la pestaña de adjuntos? Exacto: ahí aparece el XML metido adentro. No es magia, es ingeniería bien pensada.

¿Qué niveles de conformidad existen y cuál te conviene elegir?

ZUGFeRD no es un estándar monolítico: tiene varios niveles de conformidad que van de “cumplo con lo mínimo” a “facturo al Bundestag”. Elegir mal es uno de los errores más comunes cuando automatizás facturas con factura ZUGFeRD n8n; creés que con BASIC estás cubierto y después el cliente alemán te pide el XML con datos completos de IVA que no incluiste.

Nivel	Campos incluidos	¿Para quién es?
BASIC	Datos mínimos: totales, emisor, receptor, número de factura	Pymes con requisitos simples, B2B de bajo volumen. No aceptado en sector público.
COMFORT	BASIC + líneas de ítem, desglose de IVA por tipo impositivo	Mayoría de transacciones B2B comerciales. El piso real para la mayoría de las empresas.
EXTENDED	COMFORT + datos adicionales de pago, descuentos, referencias a pedidos	Empresas con procesos contables complejos que necesitan trazabilidad completa.
EN16931	Perfil completo de la norma europea, validable automáticamente contra el esquema oficial	Recomendado como estándar base. Cumple con la legislación alemana y es interoperable con Factur‑X en Francia.
XRECHNUNG	EN16931 + extensiones específicas del sector público alemán (campos de referencia a contratos, órdenes de compra gubernamentales)	Solo para facturación a entidades públicas alemanas (Bund, Länder). Obligatorio en ese ámbito desde 2020.

La regla de oro que surge de la documentación de PDF4me y de la experiencia en campo es: si no tenés un motivo específico para usar otro, elegí EN16931. Es el que valida contra el esquema europeo, es interoperable entre países, y cubre tanto los requisitos comerciales como los de auditoría sin meter complejidad innecesaria. XRECHNUNG lo dejás para ese contrato puntual con el gobierno alemán que probablemente ya sabés que tenés. En el nodo HTTP Request de n8n profundizamos sobre esto.

¿Cómo se integra PDF4me con n8n para generar facturas ZUGFeRD?

PDF4me puso a disposición un nodo llamado “Create ZUGFeRD Invoice” dentro de n8n que hace todo en un solo paso: tomás los datos de la factura, los pasás como XML, JSON o CSV, configurás el nivel de conformidad y el modo de salida, y el nodo te devuelve un PDF/A‑3b con el XML incrustado, listo para mandar. Sin scripts, sin manipular headers HTTP, sin pelearte con la estructura del PDF/A‑3.

Para los que necesitan más control —ponele que querés generar primero el PDF/A‑3 base y después adjuntarle el XML manualmente—, PDF4me expone dos acciones REST separadas: Create PDF/A y Add Attachment to PDF. Las encadenás en un workflow de n8n con llamadas HTTP secuenciales, y tenés control granular sobre cada paso del proceso. La verdad es que el 90% de los casos se resuelven con el nodo único, pero saber que existe la alternativa con dos pasos te da margen si el cliente pide algún ajuste fino en el PDF visible que el nodo estándar no expone.

Un dato importante: el nodo de n8n acepta datos en XML, JSON o CSV indistintamente. Si tu sistema de facturación ya exporta en alguno de esos formatos, conectás la salida directo al nodo, seteás el “Conformance Level” a EN16931 y en segundos tenés la factura híbrida generada —es, literalmente, un flujo de tres nodos que podés armar en menos de diez minutos si ya conocés n8n—.

¿Qué parámetros necesita el nodo Create ZUGFeRD Invoice en n8n?

Al insertar el nodo en tu workflow, los campos que vas a ver del lado de parámetros son los siguientes, según la documentación oficial de PDF4me:

• Conformance Level: el nivel de conformidad ZUGFeRD. Las opciones son BASIC, COMFORT, EXTENDED, EN16931 y XRECHNUNG. Elegís uno solo y el XML generado se ajusta a ese perfil.
• Output Mode: podés optar por XML With PDF (el PDF/A‑3 completo con XML incrustado) o XML Only (solo el archivo XML, si ya tenés un PDF generado por otro lado y solo necesitás el adjunto estructurado).
• Invoice Data: los datos de la factura en formato XML, JSON o CSV. Acá es donde conectás la salida de tu sistema de facturación o de un nodo anterior que arme el payload.
• PDF/A Compliance: el nodo valida internamente que el PDF generado cumpla con PDF/A‑3b (salvo que elijas XML Only, donde no aplica). Si la validación falla, el nodo tira error explícito y podés ramificar un manejo de excepciones en el workflow.

El punto que más fricción genera en la práctica es la validación del XML contra el esquema EN 16931. El nodo hace una validación sintáctica, pero las reglas de negocio —que el total coincida con la suma de las líneas, que los porcentajes de IVA sean correctos para el país del receptor, que el número de factura no esté duplicado en tu secuencia— corren por tu cuenta. PDF4me no adivina la lógica de tu negocio; eso lo tenés que controlar en un paso previo del workflow o en el sistema que genera los datos.

¿Cómo validar y solucionar problemas de facturas ZUGFeRD generadas con PDF4me?

El hecho de que el nodo devuelva un PDF sin errores no garantiza que el sistema del comprador alemán lo acepte —y si alguna vez lidiaste con ERPs alemanes, sabés que son implacables con las validaciones—. Es recomendable validar la conformidad técnica del archivo: estructura del PDF/A‑3, metadatos requeridos, fuentes incrustadas, y la integridad del XML adjunto contra el esquema declarado. Complementá con enviar notificaciones a Slack con n8n.

Lo que no hace —y acá está el detalle que te puede costar un pago rechazado— es validar las reglas de negocio específicas del receptor. Un caso real que aparece en la documentación: un cliente generaba facturas con el perfil BASIC porque los datos se veían “completos”, pero el sistema del comprador exigía COMFORT como mínimo porque necesitaba parsear el desglose de IVA por línea para su motor de compliance fiscal. PDF4me generó el PDF sin problemas, la validación técnica pasó en verde, y la factura rebotó igual en las oficinas del cliente en Múnich.

La recomendación de la documentación es seca y directa: siempre probá con el sistema del receptor antes de mandar facturas reales, y si el comprador no te puede dar acceso a un sandbox, pedile que te valide una factura de prueba con datos anonimizados. Lo bueno es que n8n te permite bifurcar el flujo: un nodo Validate PDF/A, si falla, va a una rama de corrección; si pasa, sigue a envío —y todo eso corre sin que toques nada después de la configuración inicial—.

¿Qué ventajas tiene automatizar facturas ZUGFeRD con n8n y PDF4me?

La principal es que pasás de un proceso manual (o semiautomático que alguien del equipo de finanzas toquetea cada fin de mes) a un flujo 100% automatizado que arranca con la extracción de datos, sigue con la generación del PDF/A‑3 híbrido y termina con el envío o almacenamiento, sin intervención humana en el medio. Los workflows de ejemplo que publicó PDF4me en su blog muestran un caso concreto: un archivo JSON depositado en una carpeta de Dropbox dispara el nodo Create ZUGFeRD Invoice, y la factura generada se guarda automáticamente en otra carpeta —o se manda por email, o se sube al ERP, o se publica en un endpoint del cliente—.

Eso sí, no subestimes el trabajo previo de normalización de datos. El flujo automatizado es impecable si la fuente de datos es consistente; si tu JSON de facturación es un Frankenstein que armó tres personas distintas con criterios diferentes a lo largo de dos años, la automatización solo va a hacer que los errores lleguen más rápido al comprador.

Otro punto a favor: PDF4me se integra con otras aplicaciones del ecosistema n8n —Google Sheets, bases de datos SQL, servicios de correo, ERPs vía API—, así que podés armar un pipeline completo de facturación para clientes europeos sin salirte de la herramienta de automatización que ya conocés. Para empresas latinoamericanas que facturan a Alemania (exportadoras de software, servicios profesionales, agroindustria), esto resuelve el compliance sin necesidad de contratar un desarrollo a medida.

Errores comunes al generar facturas ZUGFeRD en n8n

• Elegir BASIC cuando el comprador necesita COMFORT o EN16931. Es el error más repetido. BASIC solo incluye totales y datos de cabecera; si el sistema del receptor espera el desglose de IVA por línea, la factura rebota aunque el PDF se vea perfecto. Antes de configurar el nodo, preguntale al cliente alemán qué perfil mínimo acepta (o revisá su portal de proveedores; casi siempre lo publican).
• No validar el XML contra las reglas de negocio antes de generar el PDF. El nodo de PDF4me valida sintaxis y conformidad técnica, pero no verifica que la suma de las líneas coincida con el total, que el IVA esté bien calculado o que los IDs de impuestos sean correctos para el régimen fiscal alemán. Esa validación tiene que estar en un paso previo del workflow, y te conviene usar un nodo de Code en n8n para correr un chequeo rápido antes de llamar a PDF4me.
• Usar ZUGFeRD 1.0 por inercia o documentación vieja. La versión 1.0 está obsoleta desde hace años y ningún sistema que cumpla con la legislación alemana debería aceptarla. Si estás migrando un proceso viejo, revisá que la configuración apunte a ZUGFeRD 2.x (el nodo de PDF4me usa la especificación 2.x por defecto, pero si venís de una integración REST vieja, podrías estar apuntando a la versión incorrecta sin darte cuenta).
• Asumir que el PDF/A‑3 generado es perfecto y no probarlo con un validador externo. Aunque las herramientas de validación integradas pueden ser útiles, si estás en un entorno de producción con cientos de facturas diarias, meté también un validador externo como paso adicional en el workflow (por ejemplo, la herramienta gratuita de validación de la Koordinierungsstelle für IT-Standards alemana). Dos validaciones son mejor que una cuando el pago está en juego.

Preguntas Frecuentes

¿Qué es una factura ZUGFeRD?

Una factura ZUGFeRD es un archivo PDF/A‑3 que contiene dos representaciones de la misma factura: una visual para humanos (el PDF que ves en pantalla) y una estructurada para máquinas (un XML incrustado como adjunto, conforme a la norma europea EN 16931). El mismo archivo sirve para que una persona lo lea y para que un ERP lo procese automáticamente sin reingresar datos. Es obligatorio para facturación B2B en Alemania desde el 1 de enero de 2025 según la legislación alemana. Cubrimos ese tema en detalle en instalar n8n con Docker.

¿Cómo generar una factura ZUGFeRD en n8n?

Usás el nodo “Create ZUGFeRD Invoice” de PDF4me, que está disponible en el marketplace de nodos de n8n. Le pasás los datos de la factura en XML, JSON o CSV, seteás el nivel de conformidad (recomendado: EN16931) y el modo de salida (XML With PDF para obtener el PDF/A‑3 completo). El nodo devuelve el archivo listo para almacenar, enviar por email o subir a un sistema contable. También existe la alternativa de dos llamados REST separados (Create PDF/A + Add Attachment to PDF) si necesitás control más detallado.

¿Qué diferencia hay entre ZUGFeRD y XRechnung?

ZUGFeRD es un formato híbrido que combina PDF visible + XML incrustado; XRechnung es XML puro (sin capa visual), desarrollado específicamente para el sector público alemán. Mientras ZUGFeRD tiene varios niveles de conformidad (BASIC a EN16931), XRechnung es obligatorio solo para facturar a entidades gubernamentales alemanas desde 2020. En la práctica, si facturás tanto a privados como al sector público, podés generar EN16931 para los primeros y XRECHNUNG (que es una extensión del anterior) para los segundos, todo desde el mismo flujo de n8n con PDF4me.

¿Precio de PDF4me para crear facturas ZUGFeRD: es gratis o tiene suscripción?

PDF4me funciona con un modelo de suscripción por créditos. Generar una factura ZUGFeRD con el nodo Create ZUGFeRD Invoice consume créditos según el plan que tengas contratado. La documentación oficial no detalla un tier gratuito ilimitado para producción, aunque suele haber créditos de prueba para evaluar el servicio. Para un volumen de facturación real, necesitás un plan pago, y el costo por factura depende de la cantidad de operaciones que hagas (creación de PDF/A‑3, adjunto de XML, validaciones adicionales). Consultá la página de precios actualizada porque los créditos por operación pueden variar.

¿Puedo usar ZUGFeRD en España o solo aplica en Alemania?

ZUGFeRD es el estándar alemán, pero su par francés es Factur‑X (técnicamente idéntico, ambos basados en EN 16931 con PDF/A‑3). Si facturás a empresas alemanas, usás ZUGFeRD; si facturás a francesas, usás Factur‑X. Para España, el formato obligatorio sigue siendo Facturae (XML firmado digitalmente, sin PDF híbrido), aunque la normativa europea avanza hacia la interoperabilidad total con EN 16931, y es probable que en los próximos años convivan o migren. Por ahora, ZUGFeRD no reemplaza a Facturae para facturación doméstica española, pero si exportás servicios a Alemania, sí o sí necesitás ZUGFeRD.

Conclusión

El compliance alemán para facturación B2B cambió y no hay vuelta atrás: el PDF bonito sin XML no va más. PDF4me y n8n resuelven el problema técnico de forma práctica —un nodo, tres formatos de entrada, el PDF/A‑3 híbrido sale en segundos—. La parte que no resuelven por vos es la validación de negocio: si tus datos no son consistentes, el flujo automatizado solo va a hacer que los errores lleguen más rápido al cliente alemán.

Si ya tenés n8n en tu stack, la integración con PDF4me es directa y el costo en tiempo de configuración es bajo. Si no, vale la pena evaluarla: para empresas latinoamericanas que facturan a Europa, es más barato y rápido que desarrollar una solución propia de cero —y te evitás el momento incómodo de recibir un “bitte senden Sie eine korrekte Rechnung” en la casilla de correo—.

Fuentes

• PDF4me en dev.to — A PDF a Human Reads and a Machine Parses at the Same Time: How PDF4me Builds ZUGFeRD E-Invoices
• Documentación oficial de PDF4me — Create ZUGFeRD Invoice en n8n
• Blog de PDF4me — ZUGFeRD Invoice con n8n, Dropbox y flujo JSON