ZUGFeRD ( Zentraler User Guide Forum elektronische Rechnung Deutschland ) is a open european standard for a structured, hybrid PDF e-invoice . Technically, this works by embedding a XML file into PDF file. Embedded ZUGFeRD files work with all PDF readers but of course these readers may not automatically process the metadata.

At the right you see a sample PDF containing ZUGFeRD metadata generated with the Mustang library. If you open it in Adobe Acrobat Reader just click on the paperclip symbol to see the embedded ZUGFeRD XML structure.
Screenshot of Acrobat Adobe PDF Reader showing a ZUGFeRD invoice with open file attachments tab


ZUGFeRD is based on

  • PDF for the optical representation and
  • an embedded XML for the metadata/structural representation

The PDF used in ZUGFeRD is PDF/A-3. PDF/A is a subset of PDF which does not only allow validation (PDF per se can not be validated), it is specifically designed for better archival: e.g. external fonts are always embedded in PDF/A. PDF/A-3 (standardized in ISO 19005-3:2012 and not at all related to the paper format DIN-A3) is the third version of the archivable PDF/A edition, which supports embedded files.

The CEN semantic model of a core invoice is already foundation for ZUGFeRD 1.0. It e.g. defines the correct number of decimals (rule 9): in quantity (4) , currency prices (4) and totals (2), the units and how the invoice amount is calculated.

Andreas Starke has published his suggestions for ZUGFeRD Industry-specific extensions in June 2018.

Apparently all german states accept ZUGFeRD invoices and E-Rechnung-Bund mentions the ZUGFeRD 2.1.1 XRechnung reference profile as alternative to the XRechnung.


Like the XRechnung, ZUGFeRD uses the EN16931 calculation rules and the according codelists for the allowed attribute values.


Factur-X is just another name for ZUGFeRD 2.0.


ZUGFeRD 2.1.1 was been released on July 1st, 2020.

  1. from 2.1 to 2.1.1
    • there is now a dedicated profile for the XRechnung along with support for the embedded filename xrechnung.xml
  2. from 2.0 to 2.1
    • a english translation is now available(there was none for 2.0)
    • factur-x.xml is now not only allowed as filename of the embedded file but zugferd-invoice.xml has been deprecated
    • the codelists have been updated to version 3 of the CEF artefacts
    • many cardinalities have been adjusted, e.g. the extended profile now supports 2x grand total amounts, e.g. in Euro and foreign currency
  3. from 1.0 to 2.0
    • ZUGFeRD 2 supports European B2G invoices, namely EN16931. Alternatively to ZUGFeRD (more precisely UN/CEFACT CrossIndustryInvoice D16B SCRDM uncoupled), UBL 2.1 and EDIFACT are also eligible for EN16931.
    • ZUGFeRD 2 has been adopted by the french FNFE as “Factur-X version 1.0”.
    • In particular to accommodate french requirements there are two new profiles below basic,
      • Minimum
      • Basic Without Lines (BASIC WL)

      The profile Comfort has been renamed to EN 16931.

    • The filename of the embedded file changes from ZUGFeRD-invoice.xml to zugferd-invoice.xml (lower caps) in ZF2 respectively factur-x.xml in FX
    • The XML part of ZUGFeRD 1 was some sort of a customized XML format based on UN/CEFACT. ZF2 is based on the original version of the XML schema, UN/CEFACTS Cross Industry Invoice CII, more precisely on UN/CEFACT CII SCRDM 16B uncoupled .
    • The root node therefore changes from CrossIndustryDocument to CrossIndustryInvoice.
    • The schema change also means that some elements are renamed, e.g.
      Name in ZF1 in ZF2
      SpecifiedExchangedDocumentContext ExchangedDocumentContext
      HeaderExchangedDocument ExchangedDocument
      ApplicablePercent ram:RateApplicablePercent
      SpecifiedSupplyChainTradeDelivery ram:SpecifiedLineTradeDelivery
      SpecifiedLineTradeAgreement ram:AssociatedDocumentLineDocument
      SpecifiedSupplyChainTradeAgreement ram:SpecifiedLineTradeAgreement
    • some element names became more specific, e.g. ID became IssuerAssignedID if it was used in BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument or ContractReferencedDocument
    • Now also the sequence of some elements is defined more specifically, which may cause you to reorder some elements, e.g. in SpecifiedSupplyChainTradeTransaction the IncludedSupplyChainTradeLineItem now has to be the first child BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument ContractReferencedDocument now have to start with ID, then typecode and some more.
    • The XSLT Style Sheet to convert to HTML will no longer be part of the release. But the ones from XRechnung can be used.

You can use the commandline or have a look at Mustangprojects (not very complete) XSLT file which facilitates the transformation from ZF 1 XML to ZF 2 XML. There is also a first attempt for a Mustangproject sample file for version 2.


ZUGFeRD supports six different levels of required structured information

  • Minimum (ZUGFeRD 2 only)
  • Basic Without Lines (ZUGFeRD 2 only)
  • Basic
  • EN16931 (called Comfort in ZUGFeRD 1)
  • XRechnung (a reference profile, i.e. no validation artifacts are published by FeRD)
  • Extended

Mustangproject usually exports on the Extended profile.

  • In 2015 Intarsys published some nice (german) slides on status, history and genealogy of ZUGFeRD 1 including several PDF aspects, tools and workflows and optically compares the profiles basic, comfort and extended.
  • The Bitkom explained ZUGFeRD (in german) in 2014 and features a similar sample invoice with optical indications which attribute belongs to basic respectively comfort on page 6.



The permitted attribute values are listed in the Full listing of the code lists as used in EN16931 – version 4.0.

Industry recommendations

The german Building as well as the german Energy industry have published usage recommendations on ZUGFeRD. They make certain elements mandatory, or at least heavily recommended.
Andreas Starke has published a tool and a process to add additional data for industries like transportation to ZUGFeRD invoices but so far no actual industry implementation has materialized.