ZUGFeRD

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

The share of businesses sending ZUGFeRD/Factur-X is, according to a (german) Bitkom-study, around 45% in September 2021 (of the 43% of businesses submitting electronic invoices at all) in Germany.

Architecture

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.

Further info

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.

A small sample of 100 invoices showed ZUGFeRD invoices were paid 5.3 days earlier.

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.

Implementation

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

Factur/X

Factur-X is just another name for ZUGFeRD 2.0.

Versions

ZUGFeRD 2.2.0 was been released on March 1st, 2022.
Changes

  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.

Profiles

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 EN16931 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.

Attachments

Additional files accompanying the invoice, e.g. protocols, measurements or journals, may be embedded in the PDF as well (Relationship=Source). Allowed types are

  • application/pdf (.pdf)
  • image/jpeg (.jpg)
  • text/csv (.csv)
  • TXT
  • XML
  • JSON
  • image/gif (.gif)
  • image/tiff (.tiff)

The typecode for these attachments is often “916”.

Samples

Codelists

The permitted attribute values are listed in the Full listing of the code lists as used in EN16931 – version 4.0 (in the published version in version 8 but the most up to date is allowed).

Industry recommendations

The german Energy industry, a pharma company manufacturer have published usage recommendations on ZUGFeRD.
The german Building recommendation may been replaced by a updated, joint construction recommendation by several associations.
They make certain elements mandatory, or at least heavily recommended and explain how their business elements can be mapped.

There is a (german) recommendation how to use ZUGFeRD for invoices in Switzerland.
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.
At least for B2B France offers a Chorus Pro test system exactly here and documents the processes in a document which has now reached version 2.2.

Open-Source-Software