ZUGFeRD & Factur-X: The Complete Guide 2025

ZUGFeRD is the hybrid e-invoice format shared between Germany and France. As a PDF/A-3 document with embedded CII XML it combines human readability with machine processability – making it the ideal bridge between classical invoice printing and fully automated e-invoice processing. This guide explains everything from the ground up: history, technology, profiles, validation, and practical tips for 2025.

What Is ZUGFeRD?

ZUGFeRD stands for Zentraler User Guide des Forums elektronische Rechnung Deutschland. The format was developed by the FeRD consortium (Forum elektronische Rechnung Deutschland), an association of industry bodies, software companies, and federal agencies. It unites two worlds in a single file: a PDF/A-3 document (for the human reader) and an embedded CII XML file (for machine processing).

What Is Factur-X?

Factur-X is the technically identical counterpart to ZUGFeRD 2.x, published by the French standardization organization FNFE-MPE. Since ZUGFeRD version 2.0 (2019) both formats are fully interoperable: a ZUGFeRD 2.x file is a valid Factur-X file and vice versa. The name Factur-X is used in international contexts and particularly in French-speaking regions.

The History: From ZUGFeRD 1.0 to 2.x

• ZUGFeRD 1.0 (2014): First version, not yet EN 16931-compliant. Proprietary FeRD profile. Still in use at older systems.
• ZUGFeRD 2.0 (2019): Realignment on EN 16931 and harmonization with Factur-X. Introduction of multiple conformance profiles.
• ZUGFeRD 2.1 (2020): Minor corrections and clarifications. Considered the stable production version.
• ZUGFeRD 2.1.1 (2021): Bugfix release. Currently recommended version.
• ZUGFeRD 2.2 (2022): Additions for credit notes and corrective invoices.

The Technical Structure: PDF/A-3 with Embedded XML

The heart of ZUGFeRD is the PDF/A-3 standard (ISO 32000-1 in conjunction with ISO 19005-3). PDF/A-3 is a long-term archiving format that embeds all fonts, color profiles, and resources within the PDF and prohibits external references – with one important extension over PDF/A-2: it allows embedding of arbitrary file types as attachments (not only PDF).

The embedded file is always named factur-x.xml (for Factur-X) or zugferd-invoice.xml / ZUGFeRD-invoice.xml (for older ZUGFeRD 1.0 files). The relationship between PDF and XML is described in the PDF catalog via the AFRelationship key with the value Alternative – this marks the XML file as the machine-readable representation of the visible PDF content.

ZUGFeRD Profiles Compared

ZUGFeRD 2.x defines six conformance profiles, differing in the scope of mandatory data and permitted optional fields:

• MINIMUM: Minimal dataset – invoice number, date, total amount, seller, buyer. No line items. Suitable for simplest accounting integration.
• BASIC WL (Without Lines): Extends MINIMUM with payment and tax data at document level, but still without individual line items.
• BASIC: Full invoice line items with tax code per line. First step toward full invoice processing.
• EN 16931 (Comfort): Full EN 16931 compliance. Semantically equivalent to an XRechnung. Qualifies as an e-invoice under the new § 14 UStG.
• EXTENDED: Permits additional data fields beyond EN 16931 (e.g. industry-specific codes). Full EN 16931 backwards compatibility is guaranteed.
• XRECHNUNG: ZUGFeRD file that additionally satisfies all German XRechnung CIUS DE rules. Can be submitted as XRechnung to B2G portals.

The CII XML Format in Detail

The embedded XML file in ZUGFeRD uses the CII syntax (UN/CEFACT Cross Industry Invoice, ISO 19845). The root element is CrossIndustryInvoice. Key namespaces:

• rsm: urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 – main namespace.
• ram: urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100 – aggregate elements.
• udt: urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100 – data types.
• qdt: urn:un:unece:uncefact:data:standard:QualifiedDataType:100 – qualified data types.

ZUGFeRD Metadata in the PDF: XMP

A valid ZUGFeRD file contains XMP metadata (Extensible Metadata Platform) in the PDF catalog, specifying the profile ID and version number. Validating software uses these metadata to determine the profile before checking the XML file. For ZUGFeRD 2.1 EN 16931 the DocumentType value is: urn:factur-x.eu:1p0:en16931.

ZUGFeRD vs. XRechnung: Making the Right Choice

• Choose XRechnung when: you invoice German federal authorities (ZRE portal), the government portal explicitly requires pure XML, or your software only generates UBL.
• Choose ZUGFeRD EN 16931 when: you invoice B2B and want to retain a human-readable document, your recipient does not have a pure XML system, or you want one format for all recipients.
• Choose ZUGFeRD XRECHNUNG when: you want to generate a file that works both for authorities and companies and remains readable as a PDF.

Creating ZUGFeRD Files: Software Options

• DATEV: Can export ZUGFeRD (profile EN 16931 and XRECHNUNG) from DATEV Unternehmen online.
• Mustang Project (Java, open source): The best-known open-source library for ZUGFeRD creation and parsing.
• Konik (Java) and Facturae (PHP): Further open-source libraries.
• Sevdesk, Fastbill, Billbee: Cloud accounting tools with ZUGFeRD export in recent versions.
• Ecosio and Seeburger: EDI service providers with ZUGFeRD conversion services.

Validating ZUGFeRD Files

Validating a ZUGFeRD file is more complex than validating a pure XRechnung, because multiple layers must be checked:

1. PDF/A-3 conformance: Is the PDF a valid PDF/A-3 document? (Checkable with veraPDF, an open-source validator.)
2. XMP metadata: Are profile and version correctly declared in the XMP?
3. File attachment present: Is a file named factur-x.xml (or zugferd-invoice.xml) embedded?
4. XML validation: Does the CII XML file conform to the profile schema and EN 16931 Schematron rules?
5. CIUS DE validation (XRECHNUNG profile only): Additionally check the German BR-DE rules.

GoBD Archiving of ZUGFeRD Files

ZUGFeRD files are excellently suited for GoBD-compliant long-term archiving. PDF/A-3 is an ISO-standardized archive format that embeds fonts and resources and prohibits external dependencies. The GoBD's immutability requirement is satisfied by storing in a revision-safe DMS or archive – the file format itself is not a write-once carrier. The embedded XML file remains as part of the PDF for the entire 10-year retention period.

Common Errors in ZUGFeRD Implementations

• Wrong PDF format: Saving as normal PDF instead of PDF/A-3 makes the file technically invalid.
• Wrong filenames: The embedded XML file must be named exactly factur-x.xml (ZUGFeRD 2.x) – not invoice.xml or rechnung.xml.
• Missing AFRelationship attribute: Without this attribute with value Alternative, software does not recognize the XML file as invoice data.
• Outdated XMP metadata: XMP profile ID must match the actually used profile version.
• Discrepancies between PDF and XML: If the visible invoice amount in the PDF differs from that in the XML, the file is technically valid but legally problematic.

ZUGFeRD in Practice: Frequently Asked Questions

Can I submit a ZUGFeRD file to the ZRE (federal portal)?

Only with the XRECHNUNG profile. The ZRE primarily accepts pure XRechnung XML files. A ZUGFeRD file with XRECHNUNG profile satisfies all XRechnung requirements and is accepted by most federal portals – but check the current documentation of the specific portal.

How do I extract the XML file from a ZUGFeRD PDF?

In Adobe Acrobat: View > Show/Hide > Navigation Panes > Attachments > right-click factur-x.xml > Save. In PDF readers such as Foxit or PDF-XChange: open the Attachments panel and extract file. Programmatically: with Python and the pikepdf or PyMuPDF library, attachments can be extracted automatically.

Is ZUGFeRD 1.0 still permitted?

ZUGFeRD 1.0 is not EN 16931-compliant and therefore does not qualify as an e-invoice within the meaning of § 14 UStG under the new legal situation from 2025. For new implementations only ZUGFeRD 2.1 (or later) should be used. Old systems generating ZUGFeRD 1.0 must be migrated to 2.x before January 1, 2027 or 2028.