ZUGFeRD Invoice Format: Profiles, Compliance & Processing Guide

ZUGFeRD is Germany's hybrid electronic invoice format that embeds structured XML data inside a human-readable PDF/A-3 document. The XML layer uses the UN/CEFACT Cross Industry Invoice (CII) standard, meaning every data field follows an internationally recognized schema. The format offers six distinct profiles with increasing data richness, ranging from MINIMUM (basic metadata only) up to EXTENDED (which includes fields beyond the European standard). For businesses preparing for regulatory compliance, one detail matters above all others: only the EN 16931 profile (also called COMFORT) and above satisfy Germany's upcoming B2B e-invoicing mandate.

The name itself is a mouthful. ZUGFeRD stands for Zentraler User Guide des Forums elektronische Rechnung Deutschland, developed by FeRD (Forum elektronische Rechnung Deutschland), a cross-industry initiative that brought together trade associations, government agencies, and software vendors to create a single e-invoicing standard for the German market.

The core value proposition is straightforward. A ZUGFeRD invoice is a single file that serves two audiences simultaneously. Any recipient can open it in a standard PDF viewer and see a fully formatted, human-readable invoice, complete with logos, line items, and payment details. At the same time, accounting software and AP automation systems can parse the embedded XML attachment to extract structured data for automated processing, posting, and three-way matching. Both layers travel together in one PDF/A-3 container, which eliminates the need to send separate files or re-key data from a visual document.

This dual nature solves a real adoption problem. Pure XML formats require every recipient to have compatible software, which creates friction. Pure PDF invoices look fine on screen but force manual data entry or unreliable OCR on the receiving end. ZUGFeRD bridges the gap: senders can issue a single file that works regardless of the recipient's technical maturity.

The format's traction in the market reflects this practicality. A Bitkom survey of over 1,100 German companies found that among businesses already using e-invoices, 27 percent use hybrid invoices with ZUGFeRD or Factur-X, while 71 percent rely on EDI formats and only 5 percent use the pure XML format XRechnung. Those numbers underscore that hybrid formats have carved out a significant share of the market precisely because they lower the barrier to entry for e-invoicing adoption.

The latest version is ZUGFeRD 2.3, released in May 2025 as part of the harmonized ZUGFeRD 2.3 / Factur-X 1.0.07 specification. This update aligned the German and French variants of the format even more closely, a development with direct implications for any business operating across both countries.

How ZUGFeRD's Hybrid PDF and XML Structure Works

Every ZUGFeRD invoice carries two distinct layers of information: a visual PDF and a machine-readable XML payload. Understanding how these layers coexist inside one document is key to working with the format, whether you're extracting data programmatically or reviewing invoices manually.

The container that makes this possible is PDF/A-3, the ISO-standardized archival PDF format (ISO 19005-3). Unlike a regular PDF, PDF/A-3 supports embedded file attachments while maintaining strict archival compliance. ZUGFeRD exploits this capability by embedding a structured XML file directly inside the PDF container. In ZUGFeRD 2.x, this embedded file is typically named factur-x.xml. Older ZUGFeRD 1.0 invoices used the filename zugferd-invoice.xml, though these are increasingly rare in practice.

The PDF Layer: Human-Readable Invoice

Open a ZUGFeRD invoice in any standard PDF viewer and it looks like a normal invoice. The PDF layer renders the complete visual layout: company logos, seller and buyer addresses, invoice number, line items with descriptions and quantities, tax calculations, and payment totals. Nothing about this layer signals that structured data is hiding inside the file.

This is by design. The PDF layer exists for human consumption and verification. Accountants can review it, print it, and visually confirm that the invoice matches what they expect. For organizations that haven't adopted automated processing, a ZUGFeRD invoice works exactly like any other PDF invoice they already receive.

The XML Layer: Structured Data Payload

Beneath the visual surface sits the XML attachment, and this is where ZUGFeRD's real value lies. The XML follows the UN/CEFACT Cross Industry Invoice (CII) standard, an internationally recognized schema for representing invoice data in a structured, interoperable format.

The CII schema encodes every meaningful invoice field into discrete, labeled XML elements:

Party information (seller name, address, tax ID; buyer name, address, tax ID)
Invoice metadata (invoice number, issue date, due date, currency, payment terms)
Line items (descriptions, quantities, unit prices, item-level tax rates)
Tax breakdowns (tax category, rate, base amount, and calculated tax per category)
Monetary summaries (subtotal, total tax, grand total, prepaid amounts, amount due)

Because this data is structured and standardized, software can parse it directly without OCR, without template matching, and without the fragility of scraping text from a PDF layout. The XML is what automated accounts payable systems, ERP imports, and data extraction tools actually consume.

How the Two Layers Relate

Both layers are supposed to represent the same invoice. The XML is the legally binding structured representation, carrying the authoritative data that systems should process. The PDF provides visual confirmation, giving humans a familiar format they can read and cross-check.

In practice, this dual-layer design serves different users simultaneously. Automated systems ignore the PDF entirely and extract directly from the XML, gaining clean, field-level data without any interpretation ambiguity. Finance teams reviewing the same invoice open it in a PDF viewer and see a document that looks and behaves like every other invoice on their desk. Both workflows operate on the same file.

Built for Archival Compliance

The choice of PDF/A-3 as the container format isn't incidental. PDF/A-3 is specifically designed for long-term digital archiving, ensuring that documents remain readable and self-contained for decades. For German businesses subject to GoBD record-keeping requirements (which mandate retaining invoices for ten years in their original digital format), ZUGFeRD invoices satisfy archival obligations by default. The invoice, its structured data, and its visual representation all travel together in a single, standards-compliant file that doesn't depend on external resources or proprietary software to remain accessible.

The Six ZUGFeRD Profiles: What Each One Contains

ZUGFeRD 2.3 defines six profiles, each building on the previous one with additional structured data in the XML layer. The profile a sender chooses directly determines what you can extract and automate on the receiving end.

Here is what each profile contains and where the boundaries fall.

Profile	Line Items	Tax Breakdown	Payment Details	EN 16931 Compliant	Key Additions
MINIMUM	No	No	No	No	Invoice number, date, seller name, currency, total amount
BASIC WL	No	Summary only	Yes	No	Bank details, payment terms, due date, tax IDs
BASIC	Yes	Summary only	Yes	No	Item descriptions, quantities, unit prices, line totals
EN 16931 (COMFORT)	Yes	Per line item	Yes	Yes	Allowances/charges, delivery info, full addresses, order references
EXTENDED	Yes	Per line item	Yes	Yes	Incoterms, additional party roles, packaging, detailed charge reasons
XRECHNUNG	Yes	Per line item	Yes	Yes	XRechnung schema mapping for dual-standard compliance

MINIMUM

The most basic ZUGFeRD profile. The XML contains only core invoice metadata: document type, invoice number, invoice date, seller name, buyer reference, currency code, and the grand total amount. There are no line items, no tax breakdown, no payment instructions. You can confirm an invoice exists and who sent it, but there is not enough structured data to process it automatically.

BASIC WL (Without Lines)

BASIC WL adds structured payment information that MINIMUM lacks. You get the seller's bank details (IBAN/BIC), payment terms, and due date. Both seller and buyer tax identification numbers are included, along with a tax summary showing the applicable rate and total tax amount. Line items are still absent, so you cannot allocate costs to individual products or services from the XML alone. This profile is sufficient for payment routing but not for detailed bookkeeping.

BASIC

The first profile that includes individual line items. Each line carries a description, quantity, unit of measure, unit price, and line total. This is the threshold where automated cost allocation and basic accounting entry become possible from the XML data directly. The tax breakdown remains at the summary level rather than per line.

EN 16931 (COMFORT)

Full compliance with the European e-invoicing standard EN 16931. This profile adds per-line-item tax breakdowns, allowances and charges (discounts, surcharges, freight), delivery information with dates and locations, complete buyer and seller postal addresses, and purchase order references. The EN 16931 profile is the minimum level that satisfies Germany's upcoming B2B e-invoicing mandate, making it the baseline for any organization preparing for regulatory compliance.

EXTENDED

EXTENDED goes beyond what EN 16931 requires, adding trade-specific fields for industries with more complex invoicing needs. These include packaging information, delivery terms (Incoterms), additional party roles where the invoicee differs from the buyer, and granular allowance/charge reason codes. Manufacturing, logistics, and wholesale distribution are typical use cases for this profile.

XRECHNUNG

A reference profile that maps directly to the XRechnung schema used for German public-sector invoicing. While technically a ZUGFeRD profile, its XML structure mirrors XRechnung's requirements field for field. This allows organizations to produce a single ZUGFeRD file that is simultaneously XRechnung-compliant, bridging both standards without maintaining separate invoice generation workflows.

Why the Profile Level Matters for Processing

The profile of a ZUGFeRD invoice you receive determines what structured data is available for automated extraction. MINIMUM and BASIC WL invoices contain no line items whatsoever. If your AP workflow requires line-item detail from those invoices, you must fall back to reading the visual PDF layer, whether manually or through OCR-based extraction. From BASIC upward, line-item data lives in the XML and can be parsed directly. From EN 16931 upward, the data is rich enough for fully automated three-way matching against purchase orders and delivery receipts.

ZUGFeRD and Germany's B2B E-Invoicing Mandate

Germany's B2B e-invoicing mandate introduces a clear compliance threshold that directly affects which ZUGFeRD profiles your organization can accept as valid electronic invoices. The dividing line is the European standard EN 16931, the semantic data model that defines what an electronic invoice must contain across the EU.

Only ZUGFeRD profiles that fully implement EN 16931 qualify as compliant e-invoices under the mandate. In practice, this means three profiles meet the requirement:

EN 16931 (COMFORT) — the baseline compliant profile
EXTENDED — a superset that includes all EN 16931 fields plus additional data
XRECHNUNG — the German public-sector profile, also built on EN 16931

The remaining three profiles — MINIMUM, BASIC WL, and BASIC — fall short because they omit mandatory EN 16931 fields. These lower profiles lack structured data elements such as detailed tax breakdowns with per-line VAT categorization, complete party identification (including registration numbers and full postal addresses), and structured delivery information. Without these fields, an invoice cannot satisfy the standard's semantic requirements.

The BMF (Bundesfinanzministerium), Germany's Federal Ministry of Finance, has confirmed this distinction. ZUGFeRD invoices at the EN 16931 profile level and above qualify as structured electronic invoices under the mandate. Invoices using lower profiles are classified as "sonstige Rechnungen" (other invoices) — they remain legally valid tax documents, but they are not recognized as e-invoices for mandate compliance purposes.

What this means for your AP team: if you receive ZUGFeRD invoices from German suppliers, verify which profile each supplier uses. A MINIMUM or BASIC WL invoice will still arrive as a valid PDF you can process, but it will not satisfy your e-invoicing obligations and will lack the structured data needed for fully automated ingestion. When onboarding new suppliers or renegotiating invoice delivery terms, specify that you require ZUGFeRD at EN 16931 profile or above.

German businesses have been required to accept e-invoices since January 2025, with phased sending obligations following through 2028. For the full regulatory timeline, transition periods, and receiving obligations under Germany's B2B e-invoicing mandate requirements, the companion article covers the complete picture.

ZUGFeRD vs XRechnung: Key Differences

The confusion between ZUGFeRD and XRechnung is understandable. Both are German e-invoicing formats, both comply with the European standard EN 16931, and both satisfy Germany's B2B e-invoicing mandate. But they are fundamentally different in architecture, and that difference determines when each one is used.

ZUGFeRD is a hybrid format. It embeds structured XML data inside a PDF/A-3 document, producing a single file that is both human-readable and machine-readable. Open it in any PDF viewer, and you see a fully formatted invoice. Feed it to an AP system, and the software can extract every line item from the embedded XML without OCR or manual entry.

XRechnung is a pure XML format. There is no visual layer. The file contains only structured data, and rendering it into something a person can read requires specialized software or a dedicated viewer portal. It is designed for systems that process invoices programmatically and have no need for a PDF representation.

This architectural split drives every other difference between the two formats:

Dimension	ZUGFeRD	XRechnung
File format	PDF/A-3 with embedded XML	Pure XML (UBL or CII)
Human readability	Yes, opens in any PDF viewer	No, requires an XML viewer or rendering tool
Primary use case	B2B invoicing	B2G (business-to-government) invoicing
Transmission method	Email attachment, document exchange platforms	Peppol network, government submission portals
EN 16931 compliance	Yes (at XRechnung or EN 16931 profile level)	Yes (native)
Mandate compliance	Yes, qualifies as an e-invoice under German law	Yes, required for federal government suppliers

The use case split is straightforward. XRechnung was developed specifically for B2G invoicing, where German federal, state, and municipal agencies require suppliers to submit pure structured data. These agencies operate procurement systems that ingest XML directly and have no use for a visual PDF. XRechnung invoices are commonly transmitted via the Peppol network, the pan-European infrastructure for public procurement document exchange.

ZUGFeRD serves the broader B2B market, where the sender often needs recipients to have a readable invoice document alongside the structured data. Not every recipient has an ERP system capable of processing XML. The hybrid approach means a ZUGFeRD invoice works for both automated processing and manual review, making it practical for the full range of business relationships, from large enterprises with sophisticated AP systems to small firms that still open invoices in a PDF reader.

These two formats are not competing standards. They coexist within Germany's e-invoicing ecosystem, each addressing a distinct set of requirements. And the boundary between them is bridged by ZUGFeRD's XRECHNUNG profile, which generates a hybrid PDF/A-3 file whose embedded XML maps directly to the XRechnung schema. A supplier that already produces ZUGFeRD invoices can use this profile to create files that satisfy XRechnung validation requirements while still providing the visual PDF layer that B2B trading partners expect.

ZUGFeRD and Factur-X: One Format for Germany and France

ZUGFeRD 2.x and Factur-X 1.x are technically identical standards. This is not a case of two similar formats or loosely compatible specifications. They are the same standard, published under two names for two national markets. A single invoice file that conforms to one automatically conforms to the other.

This harmonization came about in 2020 through a joint effort between Germany's Forum elektronische Rechnung Deutschland (FeRD) and France's Forum National de la Facture Electronique et des Marchés Publics Electroniques (FNFE-MPE). The two organizations aligned their respective formats into a unified technical specification, with the most recent harmonized release being ZUGFeRD 2.3 / Factur-X 1.0.07, published in May 2025.

What "technically identical" means in practice:

Same XML schema. Both formats embed structured data using the UN/CEFACT Cross-Industry Invoice (CII) XML standard. The XML content inside a ZUGFeRD file and a Factur-X file follows the same schema definition.
Same container format. Both wrap the XML inside a PDF/A-3 document, attaching the machine-readable data as an embedded file within a human-readable PDF.
Same profile hierarchy. The tiered profile system works identically. France uses MINIMUM, BASIC WL, BASIC, EN 16931, and EXTENDED as its profile names, omitting only the XRECHNUNG profile (which exists specifically for German public-sector compliance). The underlying data structures at each level are the same across both standards.

The practical consequence for businesses operating across Germany and France is straightforward: one processing system handles both. A company receiving invoices from German suppliers labeled as ZUGFeRD and French suppliers labeled as Factur-X does not need separate parsing logic, separate validation routines, or separate data extraction workflows. The XML inside is structurally identical, so any system that reads one reads the other.

This cross-border interoperability matters most for companies operating within the EU single market, where supplier relationships frequently span both countries. Rather than maintaining parallel invoice processing capabilities, finance teams can standardize on a single extraction and validation pipeline regardless of whether the sender calls their file ZUGFeRD or Factur-X.

For detailed coverage of Factur-X profiles, France's e-invoicing mandate timeline, and French-specific compliance requirements, see our complete guide to France's Factur-X format.

Processing ZUGFeRD Invoices: Extracting Structured Data

Understanding ZUGFeRD profiles is useful background knowledge, but the practical question for most finance teams is straightforward: when a ZUGFeRD invoice lands in your inbox, how do you actually get the data out? The answer depends entirely on which profile the sender used.

Choosing Your Extraction Path by Profile

The profile level of a ZUGFeRD invoice determines how much structured data is available in the embedded XML and, by extension, how you should approach extraction. The difference is substantial: a MINIMUM profile XML might contain only 15 to 20 elements (invoice number, date, seller name, currency, total), while an EN 16931 profile XML for the same invoice could contain 200 or more elements spanning every line item, tax category, and payment instruction.

Path 1: Direct XML extraction (EN 16931, EXTENDED, XRECHNUNG profiles). Invoices at these profile levels contain a fully structured factur-x.xml attachment with everything needed for automated processing. The XML delivers invoice header fields (invoice number, dates, currency), complete line items with descriptions and quantities, per-line tax breakdowns, payment terms and bank details, and full buyer/seller party information. Software can parse this XML directly without ever interpreting the PDF visuals. This is the cleanest extraction path: structured data in, structured data out, with no ambiguity.

Path 2: Partial XML with supplemental extraction (BASIC profile). BASIC profile invoices include line items in the XML, which puts them ahead of the lower profiles. However, they lack certain EN 16931 fields such as detailed per-line tax breakdowns, delivery location data, and some payment-level details. Whether this matters depends on your downstream requirements. If you need only core invoice and line item data, the XML may be sufficient. If your accounting system or compliance process requires the missing fields, you will need to pull supplemental data from the PDF layer.

Path 3: PDF-layer extraction (MINIMUM and BASIC WL profiles). These profiles provide only header-level metadata in the XML: total amounts, invoice date, supplier identification, and tax summary figures. Line items, itemized tax details, and granular cost breakdowns exist only in the human-readable PDF. Processing these invoices requires reading the PDF itself, either through OCR for scanned documents or AI-based extraction for native PDFs. This is functionally similar to processing a traditional invoice, though the XML header data can still serve as a validation anchor for the extracted results.

The Mixed-Profile Reality

In practice, any organization receiving invoices from multiple German suppliers will encounter a blend of profiles. A large supplier with a modern ERP system might send EN 16931-compliant invoices with rich, parseable XML. A smaller vendor using basic invoicing software might send MINIMUM profile files where the XML carries little more than totals and dates. Both arrive as valid ZUGFeRD PDFs, but they require fundamentally different processing approaches.

This mixed-profile scenario is the core challenge that most ZUGFeRD documentation ignores. A processing workflow built exclusively around XML parsing will fail silently on lower-profile invoices, capturing only partial data. A workflow built exclusively around PDF extraction will waste effort re-extracting data that was already available in structured form.

An effective system needs to adapt: extract from the XML when it contains sufficient structured data, fall back to PDF-layer extraction when it does not, and ideally cross-reference both layers for validation. For finance teams handling this at scale, an automated invoice data extraction platform that can process both native PDFs and their embedded XML removes the need to sort invoices by profile before processing. The system reads what structured data is available and extracts the rest from the visual PDF layer.

Batch Processing and Downstream Integration

Organizations that receive hundreds or thousands of ZUGFeRD invoices monthly from a diverse supplier base face a volume problem on top of the profile-mixing problem. Manually triaging invoices by profile level before routing them to different extraction tools is not sustainable. A platform like Invoice Data Extraction that adapts its extraction approach per document, pulling from XML when structured data is available and reading the PDF when it is not, handles mixed-profile batches in a single run without manual sorting.

For finance teams using natural language prompts to specify which fields to extract, a single instruction set can handle ZUGFeRD invoices regardless of their profile level. The output, whether Excel, CSV, or JSON, is structured for direct import into accounting systems.

Regardless of the extraction path, the end goal for most German businesses is getting invoice data into DATEV, the dominant platform in German accounting. Structured output from ZUGFeRD processing typically needs to conform to DATEV's import requirements, and teams already working with DATEV will find detailed guidance on importing invoice data into DATEV useful for mapping extracted fields to the correct format.