PDFs and the ZUGFeRD Standard: What Compliance Looks Like Now

Accurate, efficient invoicing matters for businesses of any size, and one of the standards driving that in Germany is ZUGFeRD — a hybrid e-invoice format that pairs a human-readable PDF with a machine-readable XML file. If your business issues or receives invoices in Germany, or you're building PDF tools for customers who do, understanding ZUGFeRD isn't optional anymore: it's tied directly to a legal e-invoicing mandate that's now in effect.

What Is the ZUGFeRD Standard?

ZUGFeRD (“Zentraler User Guide des Forums elektronische Rechnung Deutschland”) is a specification for hybrid electronic invoices, developed by the Forum elektronische Rechnung Deutschland (FeRD) together with German ministries, industry associations, and standards bodies. A ZUGFeRD invoice embeds structured, machine-readable XML data inside a PDF/A-3 file — so a person can open and read the invoice like any other PDF, while accounting software can pull the structured data straight out of the same file.

FeRD released the original ZUGFeRD 1.0 specification on June 25, 2014. The format has been revised several times since, most significantly with ZUGFeRD 2.0 in 2019, which switched to the international UN/CEFACT CII XML syntax shared with France's Factur-X format and aligned the standard with the EU's EN 16931 e-invoicing norm. That alignment matters: under Germany's Wachstumschancengesetz (Growth Opportunities Act), ZUGFeRD satisfies the legal definition of an “electronic invoice” starting from version 2.0.1 onward. Older ZUGFeRD 1.x invoices do not meet EN 16931 and shouldn't be used for new invoices under the current mandate.

Why Was ZUGFeRD Introduced?

FeRD estimated that Germany exchanges roughly 32 billion invoices a year, yet electronic invoice adoption remained in the single digits as a percentage of that total. ZUGFeRD was created to give small and medium-sized businesses — not just large enterprises with EDI infrastructure — a practical, standardized way to exchange structured invoice data without requiring a prior agreement between sender and receiver, which many EDI formats do require.

Because a ZUGFeRD file is a real PDF/A-3 document, it also inherits PDF/A's long-term archiving guarantees, which matters for the multi-year invoice retention rules that apply under German tax law.

Where Germany's E-Invoicing Mandate Stands Today

Germany's B2B e-invoicing mandate, introduced under the Growth Opportunities Act, is rolling out in phases rather than all at once:

•     Since January 1, 2025: every business operating in Germany must be able to receive and process structured e-invoices in an EN 16931-compliant format — either XRechnung (pure XML) or ZUGFeRD (hybrid PDF + XML). A plain PDF sent by email no longer counts as an e-invoice under German law, though it may still be accepted temporarily with the recipient's consent.

•     From January 1, 2027: businesses with turnover above €800,000 must be able to issue e-invoices, not just receive them.

•     From January 1, 2028: the issuing requirement extends to all domestic B2B businesses, regardless of size.

If you're developing PDF tools for any industry that touches German invoicing — accounting software, ERP systems, procurement platforms — your PDFs need to support ZUGFeRD generation and validation well before your customers hit their own deadline.

How to Make a ZUGFeRD-Compliant PDF

Building a ZUGFeRD-compliant invoice comes down to three things: the right PDF format, correctly structured XML, and validation.

1. Use the correct PDF format. ZUGFeRD invoices must be PDF/A-3 — the ISO archival PDF standard, which is also the only PDF/A variant that allows embedding files (like XML) that aren't themselves required to be PDF/A-compliant.

2. Prepare the XML invoice data. This is the core of ZUGFeRD compliance. The XML must follow the schema for the ZUGFeRD version and profile you're targeting, with all required fields — sender, receiver, amounts, tax details, payment terms, and so on — populated correctly. Validate the XML against the schema before moving on.

3. Embed the XML in the PDF/A-3 file and validate the result. The XML needs to be embedded as an associated file with the correct relationship setting, using a tool that supports PDF/A-3 creation and embedded files — Adobe Acrobat, Adobe PDF Library, and similar PDF/A-capable tools all handle this. Once embedded, run the finished PDF through a ZUGFeRD validator to confirm both the PDF/A conformance and the XML content are correct before treating the invoice as compliant.

ZUGFeRD also defines several profiles — Minimum, Basic WL, Basic, EN 16931, Extended, and XRechnung — that control how much structured data an invoice carries. For most businesses targeting the German mandate, the EN 16931 profile is the safest choice, since it guarantees full alignment with the European standard.

ZUGFeRD Version History

ZUGFeRD has gone through several revisions since 2014, and only the more recent ones matter for compliance today:

•     ZUGFeRD 1.0 (June 2014): the original specification. Used a custom XML schema and does not meet EN 16931 — not valid for the current legal mandate.

•     ZUGFeRD 2.0 (March 2019): a ground-up revision built on the international UN/CEFACT CII syntax, aligned with EN 16931 and developed jointly with France's Factur-X.

•     ZUGFeRD 2.0.1 (October 2019): the version from which ZUGFeRD legally qualifies as an electronic invoice under German tax law.

•     ZUGFeRD 2.1 (March 2020): improved compatibility with Factur-X 1.0.

•     ZUGFeRD 2.2 and 2.3 (2024): refinements to compatibility, usability, and support for more complex VAT scenarios.

•     ZUGFeRD 2.4 (2025, effective January 2026): updated against the latest UN/CEFACT standard, with improvements to the Extended profile and cross-border invoicing support.

•     ZUGFeRD 2.5 (June 2026): the current version, focused on interoperability improvements between businesses and public authorities across Europe.

For any new implementation, target ZUGFeRD 2.x — ideally the current release — using the EN 16931 or Extended profile depending on how much invoice detail you need to carry.

ZUGFeRD Conversion Code Samples

For developers ready to start converting PDF files to ZUGFeRD, Datalogics provides code samples on GitHub:

•     .NET / C# / .NET Framework: the ZUGFeRDConverter.cs sample demonstrates converting a PDF into a ZUGFeRD-compliant PDF/A-3 document by embedding a ZUGFeRD XML invoice and adding the required XMP metadata.

•     Java / Maven: the ZUGFeRDConverter sample configures IntelliJ to compile and run a converter that produces a ZUGFeRD-compliant PDF/A-3 document.

•      Adobe C/C++: the ConvertToZUGFeRD sample converts an input PDF plus a ZUGFeRD invoice XML into a compliant ZUGFeRD PDF.

•      Modern C++: the ZUGFeRD Converter sample built on Datalogics' newer Modern C++ interface, converts an input PDF and ZUGFeRD invoice XML into a ZUGFeRD-compliant PDF/A-3 document, attaching the XML as a file attachment and writing the required XMP metadata and PDF/A extension schema.

•     VB.NET: the ZUGFeRDConverter.vb sample performs the same conversion for Visual Basic .NET projects.

All of these, along with the rest of Datalogics' code samples, are available in the Datalogics GitHub repository.

Getting Started

Whether you're preparing your own invoicing pipeline or building PDF tools for customers who need to hit Germany's e-invoicing deadlines, getting comfortable with PDF/A-3 and ZUGFeRD's embedded-XML structure now will save you a scramble later. Adobe PDF Library supports the PDF/A-3 creation and file-embedding work ZUGFeRD compliance requires. Start your free trial of our SDK and get into compliance today.

Join us on Discord | Schedule a Call with an Engineer | Ask Scout, our Friendly AI Assistant