What is ZUGFeRD?

 What is ZUGFeRD?

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid e-invoice format that embeds machine-readable XML data inside a PDF/A-3 document. Open the file in a PDF reader — you see a normal invoice. Parse the embedded XML — you get structured data that an ERP can process automatically. ZUGFeRD 2.x and Factur-X are the same specification. They unified in 2020. The only difference is the name: ZUGFeRD is the German branding, Factur-X is the French. The underlying XML is CII (Cross Industry Invoice) D16B syntax, and the embedded file is always named factur-x.xml. The current version is ZUGFeRD 2.3.2 (aligned with Factur-X 1.07.2), released in late 2024. It’s EN 16931-compliant and accepted as a valid e-invoice format under Germany’s B2B mandate.

How ZUGFeRD Works

A ZUGFeRD invoice is a PDF/A-3 file with a structured XML attachment. The PDF/A-3 standard (ISO 19005-3) allows embedding arbitrary files inside a PDF — ZUGFeRD uses this to embed a CII XML file containing all the invoice data in machine-readable form.

The Dual-Readability Concept

When you open a ZUGFeRD invoice in any PDF reader (Adobe, Preview, browser), you see a normal, human-readable invoice. The visual layout, formatting, and branding are all there — exactly like a traditional PDF invoice.

When software processes the same file, it extracts the embedded XML attachment and reads the structured data directly. No OCR, no parsing, no guessing where the invoice number is. The data is typed, structured, and follows the EN 16931 data model.

This is what makes ZUGFeRD hybrid: one file serves both human readers and machine processors.

The XML Attachment

The embedded XML file is always named factur-x.xml (even in ZUGFeRD-branded invoices — this is part of the unified specification). The XML uses CII (Cross Industry Invoice) D16B syntax, which is one of the two syntaxes defined by EN 16931 (the other being UBL 2.1).

The XML is attached to the PDF via the PDF’s Associated File mechanism. The relationship type is set to Alternative — meaning the XML is an alternative representation of the same document content.

Why PDF/A-3 Specifically

Regular PDFs don’t allow embedded file attachments in a standards-compliant way. PDF/A-3 does. It’s the archival variant of PDF that:

• Embeds all fonts (no missing character issues decades later)
• Includes ICC color profiles
• Allows associated file attachments (the XML)
• Guarantees long-term readability without external dependencies

This matters for compliance. Tax authorities require invoice archives to be readable for 7–10+ years. PDF/A-3 guarantees this. A regular PDF with an XML attachment might not pass archive compliance checks.

Generating a ZUGFeRD Invoice

The production flow has four steps:

1. Generate the visual PDF — your ERP’s existing PDF generation, but output as PDF/A-3 (not regular PDF). This means embedding fonts, including ICC profiles, and setting the PDF/A conformance level.
2. Generate the CII XML — create the structured invoice data in CII D16B syntax with the correct ZUGFeRD profile (see profiles section below). The XML must be EN 16931-compliant.
3. Embed the XML in the PDF — attach factur-x.xml to the PDF/A-3 file with the correct relationship metadata (AFRelationship = Alternative).
4. Validate — check both the PDF/A-3 conformance and the CII XML validity against EN 16931 + profile rules. Validate a ZUGFeRD invoice →

Most ERP vendors handle steps 1–3 in their invoice output module. Step 4 is where a pre-submission compliance gate catches issues before the invoice reaches customers or archives.

Why ZUGFeRD Matters

ZUGFeRD Profiles Explained

ZUGFeRD defines six profiles, each adding more data fields than the last. The profile you choose determines what data must be present in the XML.

Profile	Data Depth	EN 16931 Compliant	Use Case
Minimum	Invoice metadata only	No	Archival, payment reference only
Basic WL	Header + totals, no line items	No	Basic accounting without line detail
Basic	Full line items with prices and quantities	No	Standard B2B invoicing
EN 16931 (Comfort)	Full EN 16931 data model	Yes	Cross-border EU, government invoicing
Extended	EN 16931 + additional fields	Yes (superset)	Complex scenarios (logistics, manufacturing)
XRechnung	German CIUS rules applied	Yes	German public sector invoicing

Which Profile Do I Need?

Sending to German government? Use XRechnung or EN 16931. The Minimum and Basic WL profiles are explicitly not accepted for the German B2B mandate — they lack required data fields.

Standard B2B in Germany? EN 16931 is the safe choice. It meets the mandate requirements and works cross-border. Basic works for domestic-only if you don’t need full EU compliance.

Cross-border EU trade? EN 16931. It’s the European standard — any EU trading partner’s system should process it.

France? EN 16931 (remember: ZUGFeRD 2.x = Factur-X, so the same profile works for French compliance).

Archival only? Minimum — but be aware this won’t meet Germany’s e-invoicing mandate requirements.

ZUGFeRD in Germany: Mandate Status

Germany’s e-invoicing mandate rolls out in three phases:

Date	Requirement
January 1, 2025	All businesses must be able to receive structured e-invoices (ZUGFeRD, XRechnung)
January 1, 2027	Businesses with revenue > €800,000 must send e-invoices
January 1, 2028	All businesses must send e-invoices

ZUGFeRD (profiles EN 16931, Extended, or XRechnung) is one of the accepted formats. XRechnung (pure XML without PDF wrapper) is the other. Both are valid.

During the transition period (2025–2026), paper and PDF invoices are still explicitly allowed for sending. But reception capability is already mandatory — your ERP must be able to ingest ZUGFeRD and XRechnung invoices now.

ZUGFeRD for ERP Vendors

If you maintain an ERP serving German businesses, ZUGFeRD support is on your roadmap. Here’s what matters:

PDF/A-3 output is the first hurdle. Most ERPs generate regular PDFs. Converting to PDF/A-3 requires font embedding, ICC profile inclusion, and conformance-level metadata. Libraries like Apache PDFBox, iText, or pdf-lib can handle this — but your existing PDF templates may need adjustments.

CII XML generation is the data challenge. Your ERP has the invoice data. The question is mapping it to CII D16B fields with the right profile. The EN 16931 data model defines ~180 business terms (BT-1 through BT-180+) — the profile determines which are required.

Embedding is the assembly step. Attach the XML to the PDF with the right metadata. This is a one-time implementation.

Validation is the ongoing concern. ERP templates drift across customers. Profile requirements change. Country-specific rules get updated. Validating every ZUGFeRD invoice before delivery catches issues before they become rejections.

Common ZUGFeRD Validation Errors

These are the errors we see most frequently in ZUGFeRD invoices:

PDF/A-3 conformance failures — The most common ZUGFeRD-specific error. The PDF isn’t valid PDF/A-3: missing embedded fonts, wrong color profile, or incorrect conformance level metadata. This is a PDF issue, not an XML issue — but the invoice is invalid without a conformant container.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the invoice total. Rounding differences between the PDF (visual) and XML (structured) representations are the usual cause.

BR-DE-15 — Buyer reference missing. Required by the German CIUS (XRechnung rules). If you’re using the XRechnung profile, BT-10 must be populated.

BR-CO-18 — Tax amount calculation mismatch. The VAT breakdown in the XML doesn’t match the line-level or total-level tax amounts.

BR-DE-16 — Seller contact email missing. Another German CIUS requirement — the seller must provide a contact email address (BT-43).

Wrong profile declaration — The XML declares Minimum or Basic WL profile, but the sender intends EN 16931 compliance. Or the profile declared doesn’t match the data actually present. This causes validation rules to apply incorrectly.

ZUGFeRD vs Other Formats

ZUGFeRD vs XRechnung — ZUGFeRD is a hybrid (PDF + XML). XRechnung is pure XML. Both are EN 16931-compliant. ZUGFeRD gives you visual + machine-readable in one file; XRechnung is structured data only. For German B2B, both are accepted. For situations where the receiver needs a visual PDF, ZUGFeRD is the practical choice. 

ZUGFeRD vs Factur-X — They’re the same specification since 2020. ZUGFeRD is the German name, Factur-X is the French name. The XML structure, profiles, and validation rules are identical. If you implement one, you’ve implemented the other. 

ZUGFeRD vs UBL — Different XML syntaxes. ZUGFeRD uses CII (Cross Industry Invoice). UBL (Universal Business Language) is the other EN 16931-compliant syntax, used by Peppol and XRechnung. You can’t mix them — a ZUGFeRD invoice contains CII XML, never UBL. 

ZUGFeRD vs Peppol BIS — ZUGFeRD is a format (what the invoice looks like). Peppol is a network (how the invoice gets delivered). They serve different purposes, but they overlap: a ZUGFeRD CII invoice can be sent via Peppol (if the receiver’s Access Point supports CII syntax). In practice, most Peppol participants use UBL, not CII. 

How to Get Started

Step 1: Choose Your Profile

For most use cases: EN 16931. It meets Germany’s mandate, works cross-border, and is Factur-X-compatible for France. Only choose XRechnung profile if you’re specifically invoicing German government entities.

Step 2: Generate the PDF/A-3

Your PDF generation must output PDF/A-3 conformant files. Key requirements: all fonts embedded, ICC color profiles included, no transparency effects, no JavaScript, no encryption. Test PDF/A-3 conformance separately — a valid-looking PDF isn’t necessarily PDF/A-3 compliant.

Step 3: Generate the CII XML

Map your invoice data to CII D16B business terms. The EN 16931 profile requires: invoice number (BT-1), issue date (BT-2), currency (BT-5), seller and buyer identification, line items with amounts, and a complete VAT breakdown.

Step 4: Embed and Validate

Embed factur-x.xml in the PDF with AFRelationship = Alternative. Then validate the complete invoice — both the PDF/A-3 conformance and the CII XML against EN 16931 + profile rules + country CIUS.