ZUGFeRD and Factur-X

The ZUGFeRD and Factur-X Formats for electronic Invoices

On this page we describe the ZUGFeRD format for electronic invoices. The name ZUGFeRD (pronounced »Tsoogfaird«) is a pun on the German word »Zugpferd« which means »draft horse«. It indicates that the new invoicing standard is positioned to play a major role regarding efficient electronic invoicing. ZUGFeRD allows the exchange of invoices between supplier and payer without any requirements for prior arrangements. ZUGFeRD invoices can be deployed universally and are not limited to specific industry sectors or company sizes. Private enterprises as well as public administration can efficiently organize their invoice processing with ZUGFeRD.

The standard has been created by a working group which comprises members from the public administration, three German federal ministries, industry associations in the financial, tax and software sectors, and other organizations. The working group is called »Forum elektronische Rechnung Deutschland« (FeRD) which means »Forum for electronic invoices Germany«. The organisation responsible for Factur-X is  FNFE-MPE (»Forum National de la Facture Electronique et des Marchés Publics Electroniques«).

ZUGFeRD is abbreviated for »Zentraler User Guide des Forum elektronische Rechnung Deutschland«. The goal of ZUGFeRD is to enable electronic invoice exchange including structured data in the public and private sectors. However, unlike existing standards like EDI it is not only targeted at large organizations, but also small and medium-sized businesses as well as freelancers. ZUGFeRD invoices do not require prior arrangements between sender and receiver and are not specific to any particular industry sector.

ZUGFeRD 1.0 has been published as German national standard. ZUGFeRD 2.0 and its sibling Factur-X target electronic invoicing in all EU countries.

ZUGFeRD 1, ZUGFeRD 2 and Factur-X

The ZUGFeRD 1.0 specification has been published in June 2014. The ZUGFeRD 1.0 info package (available only in German language) contains specifications, XML schemas, XSLT style sheets as well as a dozen of sample PDF invoices. The PDF-specific requirements of the ZUGFeRD format are summarized below.

ZUGFeRD 2.0 has been published in March 2019. It is based on European Norm EN 16931 from June 2017, conforms to the XRechnung standard and is mostly compatible with the corresponding French standard Factur-X.

ZUGFeRD 2.1 has been published in March 2020. It makes the standard fully compatible with Factur-X 1.0.05.

ZUGFeRD 1 und 2 apply the same principles regarding embedding in PDF/A. Minor differences between the versions are mentioned in the description below.

ZUGFeRD Design

ZUGFeRD invoices carry both a human-readable representation (rendering) of the invoice as well as a structured machine-readable XML representation. The human-readable rendering is encoded as one or more PDF pages according to the PDF/A standard. You can find more information about PDF/A here. The XML representation is not a completely new format, but is based on existing international standards. In order to associate both invoice renderings with each other, ZUGFeRD leverages an important feature of PDF/A-3 (ISO 19005-3) which allows to embed attachments of arbitrary types into the PDF/A document. The XML invoice data is embedded in the PDF document as an attachment according to PDF/A-3 (also called associated file). In other words, ZUGFeRD invoices contain two separate renderings of the invoice where PDF/A-3 serves both as one of the renderings as well as the container for the XML rendering.

XML Part of a ZUGFeRD Invoice

While we will focus on the PDF aspects of ZUGFeRD on the remainder of this page, here is a brief overview of the embedded invoice XML. ZUGFeRD does not introduce a new XML format for invoices, but instead is based on the existing standard »Core Cross Industry Invoice« (CII) developed by UN/CEFACT. The CII provides a large framework with more than 2000 elements. The framework is modelled around business processes and relationships. Customarily the CII framework is restricted for particular applications because usually not all elements are required.

ZUGFeRD 2.0 and Factur-X are based on UN/CEFACT Cross Industry Invoice Stand D16B version 100, uncoupled set of schemas (CII). Since ZUGFeRD 1.0 uses a custom XML flavor, the invoice XML slightly differs between both versions. For example, the root element in ZUGFeRD 1.0 is CrossIndustryDocument, but CrossIndustryInvoice in ZUGFeRD 2.0/Factur-X.

ZUGFeRD 1.0 and 2.x/Factur-X support multiple application profiles:

  • ZUGFeRD 2.x only: the »Minimum« and »Basic WL« profiles have been included in ZUGFeRD 2.x for compatibility with the French standard Factur-X. They don't contain all invoicing information required in Germany and should therefore not be used in Germany.
  • The »Basic« profile carries structured data for simple invoices. Additional information can be included as free text. It covers only a subset of EN 16931-1 and is suitable for simple invoices.
  • The »Comfort« profile adds structured data for fully automated invoice processing. It completely covers EN 16931-1.
  • The »Extended« profile adds still more structured data for exchanging invoice across different industry segments.

At a minimum, applications must support the »Basic« profile, but they may add more CII elements provided these don’t interfere with the »Extended« profile. Since additional elements are outside the scope of ZUGFeRD they require prior arrangements between the exchanging parties.

PDF Requirements for ZUGFeRD Invoices

The ZUGFeRD format specification spells out the following requirements:

(1) The PDF part of a ZUGFeRD invoice must conform to the PDF/A-3 standard (ISO 19005-3). All PDF/A-3 conformance levels are allowed, i.e. PDF/A-3a, PDF/A-3b, and PDF/A-3u. It simultaneously serves as container for the XML part. While only a single XML invoice attachment is allowed in ZUGFeRD, additional attachments for other purposes may also be embedded. For example, spreadsheets, CAD drawings, images or other files can be embedded which are related to the invoice or may be relevant for invoice verification.

While only PDF/A-3 allows embedded file attachments, the three PDF/A levels are upwards compatible regarding the use of PDF elements. This implies the following combinations for creating ZUGFeRD invoices by attaching XML to PDF/A invoices:

  • PDF/A-1a and PDF/A-2a can serve as basis for PDF/A-3a, PDF/A-3b or PDF/A-3u;
  • PDF/A-1b and PDF/A-2b can serve as basis for PDF/A-3b;
  • PDF/A-2u can serve as basis for PDF/A-3b or PDF/A-3u;

(2) The XML part of the invoice must be associated with the document level of the PDF/A document (as opposed to some part of it, e.g. a page). In PDF/A-3 this is expressed with the /AF (associated files) key in the document catalog. It is required to use a fixed file name for the XML attachment; however, the standards require slightly different file names:

  • ZUGFeRD 1.0: file name »ZUGFeRD-invoice.xml«
  • ZUGFeRD 2.0: file name »zugferd-invoice.xml«
  • ZUGFeRD 2.1 and Factur-X: file name  »factur-x.xml«

The relationship of attachment and document must be »Alternative« in ZUGFeRD 1.0 and ZUGFeRD 2.0 to signal that the PDF and XML representations are equivalent. In PDF/A-3 this is expressed with the /AFRelationship key.

ZUGFeRD 2.1 changes the required value of the /AFRelationship key from »Alternative« to »Source« for the BASIC, EN 16931 and EXTENDED profiles if the invoice recipient is located outside Germany and if the PDF document is the result of transforming the XML data. Note that the ZUGFeRD 2.1 samples contain a wrong /AFRelationship key (»Data« instead of the required »Alternative« or »Source«).

(3) The XML file must additionally be declared as regular PDF attachment so that it can be processed with tools which don’t support associated files according to PDF/A-3). This is achieved by including the attachment in the PDF 1.7 standard data structure /EmbeddedFiles in the document catalog.

(4) The XMP document metadata must include four entries from the ZUGFeRD schema. These entries describe the document type (always INVOICE); the file name of the embedded XML representation which must match the name under which the XML is actually attached in the PDF document; the version of the corresponding XML schema; and the name of the applicable ZUGFeRD profile (BASIC, COMFORT, or EXTENDED). PDF/A requires that custom metadata properties like those defined by ZUGFeRD are accompanied by the corresponding schema description or extension schema; see here for details. The requirements for XMP extension schema descriptions are identical in PDF/A-1, PDF/A-2 and PDF/A-3. Templates for the XMP metadata properties for ZUGFeRD 1.0, 2.0, 2.1 and Factur-X including the required PDF/A extension schema description can be found at the end of this page. The templates for the three standards are slightly different because different file names are required for the XML attachments (see (2) above) and different XML namespaces and prefixes are used.

Noteworthy differences between ZUGFeRD 2.0 and 2.1

ZUGFeRD 2.1 resolves differences between ZUGFeRD 2.0 and Factur-X on the one hand and between ZUGFeRD 2.0 and the German XRechnung profile used in the public administration on the other hand. ZUGFeRD 2.1 and Factur-X 1.0.05 are technically identical, in particular:

  • ZUGFeRD 2.1 switches from the »zf« XML namespace prefix to »fx«.
  • ZUGFeRD 2.1 changes the name of the embedded XML from »zugferd-invoice.xml« to »factur-x.xml« (the ZUGFeRD 2.1 samples still use »zugferd-invoice.xml«)
  • ZUGFeRD 2.1 switches the internal version number in the XMP namespace URI from »2p0« to the Factur-X version number »1p0« where »p« is used in place of a decimal point. Note that Factur-X uses »1.0« for the XMP property fx:Version, while the ZUGFeRD 2.1 specification uses  »1p0« in one place (Technical Supplement A, p.9) and »1.0« in another (p.11). Since ZUGFeRD 2.1 and Factur-X are supposed to be technically identical and the ZUGFeRD 2.1 samples also use »1.0« instead of »1p0« in the fx:Version property we regard »1p0« as a specification error.
  • As already described above, ZUGFeRD 2.1 changes the required value of the key /AFRelationship in a specific situation (the ZUGFeRD 2.1 samples contain the wrong value »Data«).

The first three of these changes require adjustments in the corresponding PDF/A extension schema description when switching to ZUGFeRD 2.1 (available at the end of this page).

Additional explanatory Documents

ZUGFeRD 2.0 introduced the embedding of additional explanatory documents which can be useful for invoice verification, for example:

  • spreadsheet with calculations
  • CAD design
  • XML document with technical information
  • delivery receipt
  • work report
  • expense receipt

Such enclosures for substantiating the invoice require a suitable MIME type specification in the PDF/A document, but no additional XMP metadata.

The ZUGFeRD 2.1 specification is inconsistent regarding which profiles support additional explanatory documents:

  • The XML schema description in the Technical Appendix of the ZUGFeRD 2.1 specification (p.72) allows additional explanatory documents only for  the COMFORT and EXTENDED profiles.
  • In contrast, the ZUGFeRD 2.1 specification, Technical Supplement A, section 2.4.2.2 (equivalent also in ZUGFeRD 2.0, section 5.4.2.2) implies that all profiles support additional explanatory documents:

    »In profiles EN 16931, BASIC, BASIC WL and MINIMUM only the above mentioned formats [PDF, PNG, JPEG, CSV, Excel, Calc] are to be used. Profile EXTENDED allows any format of a valid MIME type.«

Each embedded document requires the element AdditionalReferencedDocument in the XML file which contains a reference to the document. The reference consists of a relative fragment identifier »#ef=filename«, i.e. it points to a local document (the syntax for fragment identifiers for PDF documents is specified in ISO 32000-2, Annex O):

 

<ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>12345</ram:IssuerAssignedID>
    <ram:URIID>#ef=taxi_receipt.pdf</ram:URIID>
    <ram:TypeCode>916</ram:TypeCode>
</ram:AdditionalReferencedDocument>

 

Some of the ZUGFeRD 2.1 and Factur-X 1.0.05 samples include explanatory documents. Since these samples are a bit hard to identify we list them here:

ZUGFeRD 2.1 samples with explanatory documents (all of these samples use the COMFORT profile):

  • zugferd_2p1_EN16931_Betriebskostenabrechnung.pdf
  • zugferd_2p1_EN16931_Elektron.pdf
  • zugferd_2p1_EN16931_Reisekostenabrechnung.pdf

Factur-X 1.0.05 samples with explanatory documents:

  • Facture_F20200023_*.pdf (these samples cover all profiles)

Explanatory documents are neither an alternative to nor a source of the PDF document, but usually provide additional information. For this reason the /AFRelationship key »Supplement« makes most sense (the ZUGFeRD 2.1 samples use »Data«, while the Factur-X 1.0.05 samples use »Unspecified«; both don't seem to be appropriate).

Validating ZUGFeRD and Factur-X Invoices

ZUGFeRD and Factur-X invoices can be validated as follows:

  • Conformance to the PDF/A-3 standard can be checked with one of the available PDF/A-3 validators. For example, the Preflight function in Acrobat XI and above includes PDF/A-3 validation. This process also checks the required XMP extension schema description
  • Correct embeddding of the XML file according to ZUGFeRD 1.0, 2.0, 2.1 or Factur-X can be checked with the sample program zugferd_retrieve_XML in the pCOS Cookbook. This program extracts the XML representation of the invoice.
  • The extracted XML invoice can be checked for formal validity with an XML schema validator. The required XSD/Schematron schema files are included in the ZUGFeRD/Factur-X packages. The ZUGFeRD 1.0 info package also contains a style sheet for visualizing the XML invoice data with HTML (the style sheet requires a processor with support for XSLT 2.0). This allows for rendering the invoice contents independently from the PDF rendering, which can be used for checking or representation in an HTML browser.
  • A ZUGFeRD 1 validator is available at https://www.din-zugferd-validation.org (free, but requires registration)
  • The open source validator ZUV (ZUGFeRD+VeraPDF) checks for PDF/A-3 conformance with veraPDF as well as XML validity according to ZUGFeRD 1.0, 2.0 or 2.1 with EN16931 profile using the respective Schematron files. It is also available online at https://www.zugferd-community.net/de/open_community/validation (requires registration).

PDF Processing for ZUGFeRD and Factur-X

Organizations can implement ZUGFeRD or Factur-X invoices using one or more of the following PDF processing elements:

  • Create a PDF/A-3 invoice with embedded invoice XML from scratch
  • Add invoice XML to an existing PDF/A-1 or PDF/A-2 document to create a PDF/A-3 invoice
  • Extract invoice XML from an existing PDF/A-3 invoice

These processing steps can be implemented with PDFlib products. This is discussed in more detail below.

Implementing digital invoices with PDFlib

PDFlib fully supports the PDF/A-1/2/3 standards and can be used to implement the ZUGFeRD format. All three PDF processing steps above are supported. The ZUGFeRD requirements above can be met with suitable PDFlib API options.

PDF/A-3 standard conformance can be requested with the pdfa option of begin_document(). The required XMP metadata can be supplied with the metadata option:

 

if (p.begin_document(outfile,
    "pdfa=PDF/A-3b metadata={filename={" + xmpfile + "}}") == -1)

 

Since the invoice XML is created dynamically we recommend to use the PDFlib Virtual Filesystem (PVF) to create an in-memory file which contains the XML stream for the invoice. This PVF file must be loaded as an asset which is embedded as file attachment as required by ZUGFeRD. The option documentattachment ensures that it will also be visible in PDF viewers which don’t support associated files according to PDF/A-3 (in other words: the XML file can also be extracted with Acrobat):

 

// Place XML stream in a virtual PVF file
String pvf_name = "/pvf/factur-x.xml ";
byte[] xml_bytes = xml_string.getBytes("UTF-8");
p.create_pvf(pvf_name, xml_bytes, "");

// Create file attachment (asset) from PVF file
int xml_asset = p.load_asset("Attachment", pvf_name,
     "mimetype=text/xml description={ZUGFeRD invoice in XML format} "
   + "relationship=Alternative documentattachment=true");

// Associate file attachment with the document
p.end_document("associatedfiles={" + xml_asset + "}");

ZUGFeRD and Factur-X in the PDFlib and pCOS Cookbooks

The PDFlib and pCOS Cookbooks contain full sample code for the PDF processing steps described above:

Sample ZUGFeRD and Factur-X Invoices

The ZUGFeRD and Factur-X info packages include sample PDF/A-3 invoices which demonstrate various scenarios. In addition we make available ZUGFeRD and Factur-X sample invoices for download. They have been created with PDFlib and the code presented in the PDFlib Cookbook:

ZUGFeRD 1.0 sample invoice: Basic profile

ZUGFeRD 2.0 sample invoice: Basic profile

Factur-X sample invoice: profile EN 16931 (COMFORT) with an embedded delivery receipt as additional document

Resources