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.

 

What is XRechnung?

 What is XRechnung?

XRechnung is Germany's national implementation (CIUS) of the EN 16931 European e-invoicing standard, mandatory for all public sector invoicing in Germany.

How XRechnung Works

XRechnung defines a strict XML structure based on the European standard EN 16931. It supports two syntaxes:

• UBL 2.1 (Universal Business Language) — Most common, used by Peppol
• UN/CEFACT CII (Cross-Industry Invoice) — Used by ZUGFeRD/Factur-X

German-Specific Rules

XRechnung adds 21 business rules beyond EN 16931, including:

• Leitweg-ID: Required routing identifier for German government invoices
• Payment terms: Specific format requirements
• VAT categories: Mapping to German tax codes

Submission Methods

XRechnung invoices can be submitted via:

• ZRE (Zentrale Rechnungseingangsplattform): Federal government portal
• OZG-RE: State government portals
• Peppol: Via certified Access Point
• Email: To specific submission addresses (varies by authority)

Why XRechnung Matters

B2G: Already Mandatory

Since November 2020, all invoices to German federal authorities must be XRechnung-compliant. Most state governments have similar requirements. Non-compliant invoices may be rejected.

B2B: Coming 2025-2028

Germany's B2B e-invoicing mandate phases in:

• January 2025: All businesses must receive EN 16931 invoices
• January 2027: Businesses >€800K must send e-invoices
• January 2028: All businesses must send e-invoices

XRechnung or ZUGFeRD are both accepted for the B2B mandate.

How to Get Started

Step 1: Check Your Requirements

Are you invoicing government (B2G) or only businesses (B2B)? Government requires XRechnung; B2B can use XRechnung or ZUGFeRD.

Step 2: Get Your Leitweg-ID

For government invoices, you need the recipient's Leitweg-ID routing number. This is usually provided on purchase orders or contracts.

Step 3: Generate or Convert

Use your accounting software's XRechnung export, or convert existing invoices

 

What is Peppol?

 What is Peppol?

Peppol (Pan-European Public Procurement Online) is the dominant e-invoicing network in Europe. It’s a set of open specifications that define how businesses exchange electronic documents — invoices, credit notes, purchase orders — across borders, systems, and formats. Think of it as SMTP for invoices. Your ERP connects to a certified Access Point. The Access Point routes your invoice to the receiver’s Access Point. Both sides speak the same language (Peppol BIS Billing 3.0), regardless of what ERP, accounting system, or country either party operates in. Originally an EU-funded project launched in 2008 for public procurement, Peppol now covers B2B e-invoicing across 39+ countries with 300,000+ registered participants. As of 2026, Belgium, Germany, and Poland mandate Peppol for B2B transactions. France, Spain, and others are adding Peppol support alongside national systems.

How Peppol Works

The Four-Corner Model

Peppol uses a federated architecture called the four-corner model:

Corner 1: The sender (your business or your customer’s ERP)
Corner 2: The sender’s Access Point (certified Peppol service provider)
Corner 3: The receiver’s Access Point
Corner 4: The receiver

The sender’s ERP generates a Peppol BIS invoice and submits it to their Access Point. The Access Point looks up the receiver’s Peppol ID in the network’s directory (SML/SMP), finds the receiver’s Access Point, and delivers the invoice via the AS4 transport protocol. The receiver’s Access Point delivers the invoice to the receiver’s system.

No direct connection between sender and receiver is needed. No bilateral agreements. No format negotiation. As long as both sides have a certified Access Point and a registered Peppol ID, they can exchange documents.

Access Points

An Access Point is a certified service provider that connects your business to the Peppol network. It handles message routing, delivery receipts, and protocol compliance.

Access Points are certified by a Peppol Authority (one per country or region). Certification requires passing conformance tests for message handling, security, and SLA compliance.

As a business, you choose one Access Point. As an ERP vendor, you either become a certified Access Point yourself (significant investment, full control) or you integrate with an existing one via their API.

Most mid-market ERP vendors choose the second option. The Access Point handles the transport; the ERP vendor focuses on generating valid invoices.

Peppol IDs

Every participant on the Peppol network has a unique identifier. The format combines a scheme ID (identifying the type of identifier) with the actual value.

Common scheme IDs:

Scheme	Country	Identifier Type
0208	Belgium	KBO/BCE enterprise number
0106	Netherlands	KvK Chamber of Commerce number
9930	Germany	VAT number (USt-IdNr)
0007	International	GLN (Global Location Number)
0088	International	EAN Location Code
9906	Italy	Codice Fiscale

In UBL, a Peppol ID looks like this:

<cbc:EndpointID schemeID="0208">0123456789</cbc:EndpointID>

Getting the scheme ID wrong is one of the most common integration errors. The scheme must match the identifier type and the country. An invoice with a Dutch KvK number but scheme ID 9930 (German VAT) will be rejected.

SML and SMP (Service Discovery)

The Service Metadata Locator (SML) and Service Metadata Publisher (SMP) form Peppol’s directory system. When an Access Point needs to deliver an invoice, it queries the SML to find which SMP holds the receiver’s metadata, then queries the SMP to get the receiver’s Access Point URL and supported document types.

This happens automatically — you don’t interact with SML/SMP directly unless you’re building an Access Point.

Peppol BIS Billing 3.0

Peppol BIS (Business Interoperability Specification) Billing 3.0 is the invoice format specification. It’s a CIUS (Core Invoice Usage Specification) of EN 16931, meaning it takes the European e-invoicing standard and adds Peppol-specific rules on top.

The underlying syntax is UBL 2.1 (Universal Business Language). An alternative CII syntax exists but UBL is the default for most implementations.

Every Peppol invoice must pass:

1. UBL 2.1 XML schema validation
2. EN 16931 business rules (BR-01 through BR-65)
3. Peppol-specific rules (PEPPOL-EN16931-R001 through R080)
4. Country CIUS rules (if applicable — e.g., XRechnung for Germany, BEvCIUS for Belgium)

The specification identifier that goes in your invoice:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

Full specification: docs.peppol.eu/poacc/billing/3.0

Why Peppol Matters

Where Peppol Is Mandatory (2026)

The mandate landscape is moving fast. Here’s where Peppol stands as of March 2026:

Country	Status	Peppol Role	Details
Belgium	Mandatory B2B (Jan 2026)	Required network	Grace period ended March 31
Germany	Reception mandatory (Jan 2025), sending phased 2027–2028	XRechnung delivered via Peppol	Largest EU market
Poland	KSeF mandatory	Peppol supported alongside KSeF	Dual-track system
France	Phased from Sep 2026	Supported via certified platforms (PDP)	Peppol is one of several options
Italy	FatturaPA mandatory	Peppol growing for cross-border	SDI remains dominant domestically
Netherlands	Voluntary, widely adopted	De facto standard	Highest Peppol adoption in EU
Norway	B2G mandatory	Required for public sector	Early Peppol adopter
Singapore	Nationwide e-invoicing	Peppol-based InvoiceNow	Asia-Pacific expansion
Australia / NZ	B2G pilots	Peppol-based eInvoicing	Growing adoption

 

Why ERP Vendors Need Peppol Support

If you build or maintain an ERP that serves EU businesses, Peppol support is no longer optional in most markets. The question isn’t whether to support it — it’s how to support it without breaking your existing invoice pipeline.

The common pitfall: adding Peppol as an afterthought. ERP generates a PDF or flat file, a converter turns it into UBL, and the result gets pushed to an Access Point. This works until it doesn’t — and it stops working exactly when your customer needs it most (month-end, audit, cross-border transaction with edge-case VAT rules).

The structural approach: validate every invoice against all four rule layers before it reaches the Access Point. Catch schema errors, missing fields, wrong scheme IDs, and rounding mismatches before they become rejections.

That’s what a pre-submission compliance gate does. It sits between your ERP export and the Access Point, and it makes sure nothing leaves your system that would get rejected on the other end.

Common Peppol Validation Errors

These are the errors we see most frequently in production Peppol pipelines:

PEPPOL-EN16931-R010 — Buyer reference is missing or invalid. Required for all Peppol invoices. Maps to BT-10 (Buyer Reference). Many ERPs leave this blank by default.

PEPPOL-EN16931-R001 — Business process identifier missing. The ProfileID element must contain the Peppol BIS 3.0 process identifier.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the total. Usually a rounding issue — especially common with Belgian invoices after the 2026 rounding rule change.

BR-16 — Order reference missing when required. Some country CIUS rules make this mandatory (Germany’s BR-DE-15 requires a buyer reference for public sector invoices).

BR-CO-09 — VAT identifier prefix doesn’t match the country code. The VAT number must start with the correct two-letter country prefix.