ZUGFeRD explicado: el formato híbrido de factura, sus perfiles y un ejemplo real

Resumen

13 min

ZUGFeRD es un formato de factura alemán que reúne dos cosas en un solo archivo: un PDF para las personas y un juego de datos XML estructurado para el software. Quien abre el archivo ve una factura normal. Quien la mete en un programa de contabilidad recibe importes, tipos impositivos y líneas cargados de forma automática. El estándar lo mantiene el Forum elektronische Rechnung Deutschland (FeRD) y se publica a través de la AWV, y la versión vigente es la 2.5.2 del 4 de agosto de 2026. El número que importa no es la versión sino el perfil: dos de los cinco perfiles no se admiten en Alemania como factura completa. Fuera de Alemania el mismo formato lleva otro nombre, Factur-X, y los archivos son intercambiables. Esta guía recorre la estructura, los perfiles, una factura de ejemplo completa con su XML y a quién le sirve de verdad el formato.

¿Qué es ZUGFeRD?

ZUGFeRD es un formato híbrido de factura electrónica. Híbrido significa un archivo con dos formas de leerlo. Por fuera es un PDF de los de siempre, con membrete, líneas e importes. Por dentro el mismo contenido aparece una segunda vez como XML, un juego de datos en el que cada campo tiene un significado definido. El destinatario abre uno u otro según sea una persona o un programa quien mire la factura. Una factura ZUGFeRD no es, por tanto, un formato de archivo aparte del PDF. Es un archivo PDF corriente con un juego de datos añadido dentro.

El nombre es un acrónimo alemán de Zentraler User Guide des Forums elektronische Rechnung Deutschland, la guía central de usuario del foro alemán de factura electrónica. Importa más quién está detrás que lo que significa. FeRD es una asociación de organizaciones sectoriales, administración pública y fabricantes de software, respaldada por el Ministerio Federal alemán de Economía y Energía. El estándar se publica a través de la AWV y es de acceso libre, sin cuota de licencia y sin ningún fabricante que lo posea.

Factura electrónica, ZUGFeRD y XRechnung bien separadas

Confundir los tres términos lleva o bien a pedirle a tu software el formato equivocado, o bien a dar por hecho que un PDF enviado por correo ya cumple. Factura electrónica es el término paraguas: cualquier factura emitida, transmitida y recibida en un formato estructurado que se pueda procesar de forma automática. Un PDF adjunto a un correo no entra, ni siquiera cuando sale de un programa de facturación, porque para un programa su contenido es solo texto sin significado. ZUGFeRD es una manera de cumplir ese requisito y la XRechnung, un archivo de datos puro sin capa visual, es la otra habitual en Alemania. Ambas aplican la EN 16931 y ambas valen igual, y la diferencia está en si queda algo legible al final.

Dónde entra la obligación alemana

Desde el 1 de enero de 2025 toda empresa establecida en Alemania tiene que poder recibir facturas electrónicas, sin periodo transitorio y sin umbral de facturación. Emitirlas se implanta por fases y pasa a ser obligatorio para las facturas nacionales entre empresas desde el 1 de enero de 2028, con fechas anteriores para las compañías más grandes. Para el formato esto significa una cosa: la ley no impone ZUGFeRD, impone la conformidad con la EN 16931. ZUGFeRD es un camino hacia ahí, pero solo en determinadas versiones y perfiles, y justo ahí está la trampa.

El formato ZUGFeRD: PDF y XML en un archivo

El formato resuelve un problema muy real en una fase de transición. La mitad de tus clientes puede procesar datos estructurados y la otra mitad no. Si envías un XML puro pierdes a la segunda mitad, y si envías un PDF no cumples el requisito. El formato híbrido esquiva la decisión metiendo las dos cosas en el mismo archivo.

Cómo entra el XML en el PDF

Técnicamente ZUGFeRD usa PDF/A-3, la variante de archivado a largo plazo del PDF, que a diferencia de un PDF corriente puede llevar cualquier archivo como adjunto. Ahí es donde está el XML, invisible pero unido al documento. Un programa que conoce ZUGFeRD coge el adjunto y lo lee, mientras que una persona que hace doble clic en el archivo no nota nada.

El XML está escrito en sintaxis UN/CEFACT CII, una de las dos notaciones en las que se puede expresar la EN 16931, siendo UBL la otra. Para el formato híbrido solo se admite CII. Eso se vuelve un tema allí donde ya se produce UBL en casa, para Peppol o para una XRechnung en su variante UBL, porque ese juego de datos no se puede meter sin más en el PDF. Hay que convertirlo antes, y quien pasa eso por alto se deja un paso fuera del plan.

Qué archivo vale jurídicamente

Aquí la cosa se pone seria para la contabilidad. Con una XRechnung normal el archivo XML es el original y la respuesta es sencilla. Con ZUGFeRD ambas cosas están en el mismo archivo, y manda la parte estructurada. Si la capa visual y el juego de datos no coinciden, por ejemplo porque alguien editó el PDF después, gana el XML. Por eso el PDF no puede viajar solo como justificante. Quien mueve una factura del correo a un archivo documental tiene que asegurarse de que el XML incrustado sobrevive al viaje, porque algunas herramientas que comprimen o unen PDF descartan los adjuntos en silencio, y eso solo sale a la luz en una revisión.

Versiones y perfiles: qué variante cuenta como factura electrónica

No existe el ZUGFeRD. Existe una línea de versiones y dentro de ella cinco perfiles de datos que contienen cantidades distintas de información. Si lo pasas por alto, en el mejor de los casos envías una factura que el destinatario rechaza y en el peor una que no cuenta como factura electrónica.

De la 1.0 a la 2.x

La primera versión apareció en 2014, mucho antes de la norma europea, y seguía una lógica propia. La versión 2.0 alineó el formato con la EN 16931, y desde entonces la ley alemana traza una línea clara: ZUGFeRD cuenta como factura electrónica solo a partir de la versión 2.0.1, y todo lo anterior es un formato de intercambio de datos, no una factura electrónica. La versión vigente es la 2.5.2 del 4 de agosto de 2026. Las versiones nuevas amplían sobre todo los perfiles superiores mientras el núcleo se mantiene estable, así que la pregunta que hay que hacerle al software sigue siendo concreta: qué versión y qué perfil genera, y si eso se puede cambiar.

Los cinco perfiles y la trampa

El perfil decide cuántos campos contiene el juego de datos. De muy poco a mucho, la secuencia es MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT) y EXTENDED. Por encima hay un perfil de referencia llamado XRECHNUNG, que no describe un volumen de datos propio sino que define cómo se incrusta en el PDF un XML conforme a la norma.

Los dos perfiles más pequeños son el motivo más frecuente de facturas rechazadas. MINIMUM y BASIC WL no llevan líneas de factura y el propio FeRD los concibe como ayuda al asiento contable, no como factura. Cuando un programa genera MINIMUM por defecto, el archivo le parece normal a quien lo envía porque el PDF está completo, y el fallo solo aparece en el destinatario. Para el día a día EN 16931 (COMFORT) es la opción segura, porque cubre el juego de datos básico de la norma por completo, con el tipo impositivo por línea, el periodo de prestación y las condiciones de pago cada uno en su campo. EXTENDED solo compensa donde un sector pide datos adicionales, por ejemplo en construcción o logística.

Cómo averiguar qué genera tu software

No te fíes de la web del fabricante, donde la palabra ZUGFeRD suele aparecer sin ningún añadido. El camino fiable lleva dos minutos. Escribe una factura de prueba a ti mismo, abre el archivo en un visor de PDF y saca el XML incrustado de la lista de adjuntos. Justo al principio de ese archivo, en un campo llamado GuidelineSpecifiedDocumentContextParameter, hay un identificador que delata el perfil. Si termina en minimum o basicwl, has encontrado el problema antes que tu cliente.

Una herramienta de validación va aún más rápido, porque lee el archivo e informa de versión y perfil en lenguaje claro. Si tu software no deja elegir el perfil y genera una de las dos variantes pequeñas, eso es un razón de peso para cambiar y no un defecto estético.

Cómo es una factura ZUGFeRD por dentro

Casi todas las explicaciones del formato se paran justo donde la cosa se pone interesante. Así que aquí va una factura de ejemplo completa, primero como la ve la persona y después como la lee el software. Es la misma operación, mostrada dos veces.

La factura tal y como la ve el destinatario

Pongamos que una oficina de ingeniería factura a un cliente el cálculo estructural de una cercha de cubierta. Número de factura 2026-0184, fecha 14 de octubre de 2026, periodo de prestación hasta el 30 de septiembre de 2026, una línea de 12,5 horas a 95 euros. Eso da una base de 1.187,50 euros, un 19 por ciento de IVA alemán encima, 225,63 euros, y un importe final de 1.413,13 euros, pagadero hasta el 28 de octubre. En el PDF aparece como una tabla con membrete, línea e importes, igual que cualquier otra factura. Nada en la página revela que el archivo contiene más.

La misma factura como XML

Dentro de ese mismo archivo está el juego de datos. Recortado a las partes que sostienen el conjunto, tiene este aspecto:

<rsm:CrossIndustryInvoice>
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>2026-0184</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20261014</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Calculo estructural de cubierta</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>95.0000</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">12.5000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
          <ram:TypeCode>VAT</ram:TypeCode>
          <ram:CategoryCode>S</ram:CategoryCode>
          <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>1187.50</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>1187.50</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">225.63</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1413.13</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1413.13</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Hay tres sitios que merecen una segunda mirada. Arriba del todo, urn:cen.eu:en16931:2017 indica según qué norma está construida la factura, de modo que un programa de validación sabe enseguida qué reglas aplicar. El TypeCode 380 significa simplemente factura, mientras que un abono llevaría 381. Y en el bloque de totales cada valor aparece por separado, desde la suma de líneas hasta el importe a pagar, para que la validación pueda comprobar si las cifras cuadran. Esa comprobación aritmética es el motivo de rechazo más frecuente en la práctica. No un campo que falta, sino un importe de impuesto que se desvía un céntimo de la suma de las líneas porque en algún sitio se redondeó de otra manera.

La misma factura en el perfil equivocado

Ahora la parte reveladora. Si esa misma factura se generase en el perfil MINIMUM, desaparecería todo el bloque central, es decir IncludedSupplyChainTradeLineItem con la descripción, las horas y el precio por hora. Quedaría un juego de datos que conoce el número de factura, la fecha, el total y el importe del impuesto, pero no para qué es el dinero. La página PDF visible estaría completamente igual.

Ahí es donde falla la factura. No en el aspecto, sino en que la parte que manda ya no lleva los datos obligatorios. Quien envía ve un documento correcto, quien recibe obtiene un juego de datos incompleto, y ninguno de los dos se entera hasta que lo pregunta el departamento de cuentas a pagar. Por eso el perfil es el único dato que importa de verdad en este formato, y no el número de versión del que todo el mundo habla.

Cómo saber si un PDF lleva ZUGFeRD

Por fuera no se ve, y en esto caen también contables con experiencia. Un visor de PDF tiene una lista de adjuntos y el archivo incrustado aparece ahí, normalmente con el nombre factur-x.xml o zugferd-invoice.xml. Una herramienta de validación es el camino mejor, porque informa no solo de si hay un XML dentro sino también de qué perfil y qué versión.

ZUGFeRD y Factur-X: un formato, dos nombres

Fuera de Alemania el formato suele encontrarse bajo su nombre francés. Factur-X y ZUGFeRD son técnicamente lo mismo. Alemania y Francia desarrollan la especificación juntas, las versiones salen a la vez y un archivo creado en un país se lee en el otro sin ninguna conversión. Para quien recibe, la diferencia es el nombre sobre el papel y nada más.

Qué nombre te encuentres depende de dónde esté tu interlocutor, no de lo que contiene el archivo. Un cliente francés pedirá Factur-X y uno alemán ZUGFeRD, y tu software produce un único archivo para ambos. La consecuencia práctica merece anotarse: si un programa de contabilidad internacional admite Factur-X, también admite ZUGFeRD, aunque el nombre alemán no aparezca en ningún sitio de su documentación. Si buscas esa función en un sistema que no se hizo para el mercado alemán, busca primero Factur-X.

¿Necesitan ZUGFeRD las empresas de fuera de Alemania?

Es la pregunta que casi todas las guías del tema se saltan, y la que decide si el resto te afecta siquiera. La respuesta corta es que la obligación alemana de emitir facturas electrónicas afecta a las empresas establecidas en Alemania. Un proveedor con sede en España, Estados Unidos o el Reino Unido no queda sujeto a ella por el mero hecho de que el cliente sea alemán.

Quedan tres situaciones que conviene separar, porque la respuesta práctica cambia en cada una.

Facturas a empresas alemanas desde España

Ninguna obligación alemana te afecta, pero el tirón del otro lado es real. Tus clientes alemanes llevan desde principios de 2025 teniendo que poder recibir facturas electrónicas, y muchos han rehecho su departamento de cuentas a pagar alrededor de eso. Un proveedor que sigue enviando un PDF normal no incumple ninguna norma, pero cada vez es más el único trabajo manual dentro de un proceso por lo demás automatizado. ZUGFeRD es la forma más suave de responder a esa expectativa, porque el archivo sigue pareciendo la factura que todo el mundo conoce.

Lo que sí te afecta son las reglas españolas, y no conviene mezclarlas con las alemanas. España implanta desde 2027 dos obligaciones para las facturas entre empresas: cada factura debe comunicarse a la Agencia Tributaria en un formato que después no se pueda alterar, lo que las normas llaman VeriFactu, y las facturas B2B tienen que viajar como factura electrónica por un canal homologado. Unusual Suite genera la factura electrónica, pero no la comunica a Hacienda. De eso se encarga un proveedor certificado, por ejemplo B2Brouter, que registra la factura, le añade el código QR obligatorio y la entrega a tu cliente y a la Agencia Tributaria. Creas la factura en la Suite, descargas el archivo electrónico que acompaña al correo y lo subes al portal de tu proveedor.

Facturas a organismos públicos alemanes

Aquí cambia el cuadro. Las facturas a organismos federales alemanes tienen que ser electrónicas con independencia de dónde esté el proveedor, salvo algunas excepciones. Para ese caso ZUGFeRD es la opción más floja. Los portales de recepción de facturas están construidos alrededor de la XRechnung y esperan un archivo de datos puro junto con un identificador de enrutamiento llamado Leitweg-ID. Algunos portales aceptan un archivo ZUGFeRD en el perfil de referencia XRECHNUNG, pero no es algo en lo que convenga confiar.

El tercer caso es la filial alemana, y es el motivo más frecuente por el que un equipo financiero acaba leyendo sobre ZUGFeRD. La filial está establecida en Alemania, así que la obligación le afecta por completo, con las fechas escalonadas de más arriba. La decisión entonces no es si cumplir, sino cuál de los dos formatos alemanes encaja con la cartera de clientes, y de eso va el apartado siguiente.

ZUGFeRD frente a XRechnung: cuál enviar

Las dos cumplen la EN 16931 y las dos son válidas en Alemania, así que la elección no va de cumplimiento. Va de quién recibe la factura y de qué puede hacer con ella.

La respuesta depende del destinatario, no de la tecnología.

En corto: ZUGFeRD es el formato para facturar entre empresas durante una transición y la XRechnung el del sector público. Si no sabes qué puede procesar un cliente concreto, que es lo normal, el archivo híbrido deja la pregunta abierta, y para eso precisamente se construyó.

Cómo crear una factura ZUGFeRD

El formato no se puede generar a mano. Un PDF/A-3 con un XML incrustado correctamente y conforme a la norma no sale de un procesador de textos, y exportar desde una hoja de cálculo tampoco ayuda. Hace falta software que conozca el formato. Los caminos disponibles se diferencian menos en el resultado que en cuánto trabajo cae antes y después.

Este artículo procede de Unusual Software GmbH, el fabricante de Unusual Suite. La tabla siguiente también menciona nuestro propio producto. La hemos escrito para que siga siendo útil si te decides por otra cosa.

Precios y alcance dependen del plan y del número de usuarios. Para precios en firme, pregunta al fabricante.

Si trabajas fuera de Alemania hay un camino más corto que conviene probar antes que ninguno de estos. Comprueba si el sistema de contabilidad que ya usas admite Factur-X, porque es el mismo formato bajo su nombre internacional. Muchos programas que se venden por toda Europa lo incluyen sin mencionar jamás ZUGFeRD.

Los caminos se diferencian sobre todo en de dónde salen los datos de la factura. Los programas de contabilidad son fuertes en lo que viene después, en justificantes, plan contable y entrega a la asesoría, pero quien registra horas y factura a partir de ellas guarda esos datos en otro sitio y los teclea dos veces. El software de gestión integrado viene del lado contrario y construye la factura con proyectos y horas que ya están en el sistema, a cambio de una contabilidad menos profunda. Los generadores gratuitos valen para una prueba y no valen para el trabajo continuo, porque cada factura empieza desde cero.

Unusual Suite

Unusual Suite envía un PDF híbrido. Eso va al principio, porque responde a la pregunta de la que trata esta guía. Cada factura emitida sale como un PDF legible que lleva la factura electrónica conforme a la EN 16931 incrustada dentro y adjunta aparte, para Alemania y la mayoría de países como XRechnung en la versión 3.0.1 y para España como Peppol BIS 3.0. El formato sigue al país de la dirección de tu propia empresa, no al idioma en el que uses la aplicación. La persona y el programa de contabilidad leen el mismo envío, y cada receptor se queda con la forma que entiende su sistema.

Lo que sí hace es reunir CRM, gestión de proyectos, control de horas y facturación en una sola interfaz. Las líneas de factura se construyen con el tiempo de trabajo registrado junto al proyecto, la regla de facturación y el periodo, y una corrección sale como abono electrónico que remite a la factura que rectifica. Está pensado para empresas de servicios que facturan por el tiempo dedicado. Una guía aparte explica qué tiene que hacer un software de facturación electrónica y cómo reconocer uno adecuado.

Recibir y procesar facturas ZUGFeRD

Se escribe mucho sobre emitir y poco sobre recibir, y sin embargo en Alemania el lado receptor es problema de todos desde principios de 2025. Quien recibe una factura electrónica en formato ZUGFeRD tiene que poder aceptarla, leerla y conservarla.

Validar en vez de confiar

Un archivo entrante no debería pasar sin más. Una herramienta de validación lee el XML incrustado, informa de campos obligatorios que faltan, recalcula los totales e indica qué perfil hay, que es justo donde se hacen visibles los dos perfiles más pequeños. Si llega una factura en el perfil MINIMUM, faltan las líneas y no se sostiene como factura completa. El segundo punto afecta a la capa visual: cuando el PDF y el XML dicen importes distintos manda el juego de datos, así que quien contabiliza a mano debería leer las cifras del XML y no de la página impresa.

Qué pasa con una factura equivocada

Si el error aparece después de enviar, la factura no se sobrescribe ni se borra. Se queda como está y recibe un segundo documento al lado. En el juego de datos ambos se diferencian por un único valor: una factura lleva 380 en el TypeCode y un abono lleva 381, y el abono nombra además la factura a la que se refiere. Para la contabilidad esto es más limpio que cualquier corrección sobre el original, porque la secuencia de hechos queda trazable. En la práctica significa que tu software debería emitir una corrección como documento electrónico propio, no como un PDF nuevo con la palabra anulación en el asunto. Las herramientas de facturación sencillas suelen carecer de esto, así que pruébalo con una factura de prueba antes de decidir.

Para la conservación la regla es corta. Guarda el archivo original sin cambios, de manera que el XML de ZUGFeRD se mantenga incrustado, y prueba con un archivo de muestra si tu archivo documental deja pasar el adjunto. Una impresión no cuenta y una copia PDF regenerada tampoco. Hay un límite más que corresponde mencionar aquí, porque lo comparten muchos programas de facturación: no toda herramienta que escribe facturas electrónicas sabe leer las que entran. Eso vale para los planes más baratos de algunos fabricantes de contabilidad, así que al comparar herramientas conviene mirar por separado la emisión y la recepción.

Conclusión: primero entender el formato, después elegir la herramienta

ZUGFeRD no es una imposición sino una respuesta a una transición en la que la mitad de los clientes lee datos estructurados y la otra mitad todavía no. Mientras eso siga así, el formato híbrido es la opción más cómoda para facturar entre empresas. Para los organismos públicos el camino pasa por la XRechnung, y fuera de Alemania el cuadro vuelve a cambiar, normalmente hacia Peppol o hacia el mismo archivo con el nombre Factur-X.

Lo que conviene llevarse de este texto es menos la técnica que la única pregunta que hay que hacerle al software: qué versión y qué perfil genera. Versión 2.0.1 o superior y como mínimo el perfil EN 16931, y la base está bien. Todo lo demás, del control de horas al archivo documental, se decide después.