Factur-X vs ZUGFeRD: What's the Difference (and Does It Matter?)
Factur-X and ZUGFeRD are technically the same format with different names. But the details matter when you're trying to pass validation. Here's what you need to know.
If you've spent any time looking into European e-invoicing formats, you've probably hit this question: is Factur-X the same as ZUGFeRD? The short answer is yes — they're the same technical specification under two names. The longer answer involves some history, some politics, and a few practical differences that actually matter when you're trying to get invoices through validation.
Let's sort it out.
The History: How One Format Got Two Names
ZUGFeRD came first. Launched in 2014 by the Forum elektronische Rechnung Deutschland (FeRD), it was Germany's answer to a specific problem: how do you create an e-invoice that's both human-readable and machine-processable? The solution was a hybrid format — a PDF document with structured XML data embedded inside it.
The first version, ZUGFeRD 1.0, used a proprietary data model that predated the EU's EN 16931 standard. It was widely adopted in Germany and Austria, but it wasn't interoperable with the emerging European framework.
Meanwhile, France was developing its own hybrid format. The French tax authority (DGFiP) and the Forum National de la Facture Electronique (FNFE) created Factur-X — same concept (PDF + embedded XML), but designed from scratch to align with EN 16931.
In 2019, Germany and France decided to merge their efforts. ZUGFeRD 2.0 and Factur-X 1.0 became the same specification, jointly maintained by both countries. The French call it Factur-X. The Germans call it ZUGFeRD 2.x. The underlying technical specification — the profiles, the XML schema, the PDF/A-3 structure — is identical.
As of 2026, the current version is ZUGFeRD 2.3 / Factur-X 1.1. Same specification document. Same XML namespace. Same profiles. Two names.
How the Format Works
Whether you call it Factur-X or ZUGFeRD, the structure is the same:
The container is a PDF/A-3 file. PDF/A-3 is an archival PDF format that allows embedding arbitrary files as attachments. The PDF itself contains the visual representation of the invoice — what a human would print and read.
The payload is a CII (Cross-Industry Invoice) XML file embedded as an attachment inside the PDF. The XML file is always named factur-x.xml and contains the structured invoice data — amounts, tax calculations, party information, line items — in machine-readable form.
The relationship between the PDF and the XML is declared in the PDF's metadata. An XMP metadata block identifies the attachment as the structured invoice data, specifies the profile level, and declares the format version.
This dual nature is the whole point of the format. An accounts payable clerk can open the PDF and read it. An ERP system can extract the XML and process it automatically. Both representations should contain the same information — and if they don't, the XML takes precedence.
The Profile System
Both Factur-X and ZUGFeRD use the same profile hierarchy, which determines how much structured data the XML must contain:
| Profile | Data Level | EN 16931 Compliant? | Use Case |
|---|---|---|---|
| Minimum | Invoice reference only | No | Archival, basic routing |
| Basic WL | Header data, no line items | No | Simple invoices without line detail |
| Basic | Header + line items | No | Standard invoicing (pre-EN16931 compatibility) |
| EN 16931 (Comfort) | Full EN 16931 data set | Yes | EU-compliant e-invoicing |
| Extended | Additional fields beyond EN 16931 | Yes (superset) | Complex invoicing with extra data |
| XRechnung | German CIUS profile | Yes | German public sector invoicing |
For EU e-invoicing mandates (France, Germany B2B, Belgium via conversion), only the EN 16931 profile or higher satisfies legal requirements. The Minimum and Basic WL profiles don't carry enough structured data. If your invoices use "Minimum" and you need to comply with a mandate, you'll need to upgrade the profile.
The XRechnung profile is a special case — it's used when generating a ZUGFeRD/Factur-X PDF that contains an XRechnung-compliant XML payload. This is common for German B2G invoicing where the recipient needs to process the XML but the sender also wants to keep a PDF copy.
Where They Actually Diverge
If the specification is identical, where do differences show up in practice? In a few places that matter.
Naming Conventions
The XML attachment must be named factur-x.xml. In older ZUGFeRD 2.0 implementations, you might see zugferd-invoice.xml as the filename. Current implementations should use factur-x.xml regardless of which name you call the format. If your PDF generator still uses the old filename, some validators will flag it.
The XMP metadata embedded in the PDF refers to urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# as the namespace. Again, this is the same whether you call it Factur-X or ZUGFeRD.
Country-Specific Validation Context
Here's where it gets practical. The specification itself is identical, but the validation context changes by country:
In Germany, a ZUGFeRD invoice used for B2B transactions must comply with EN 16931 and may need to satisfy BR-DE rules if the parties agree to XRechnung-level compliance. A ZUGFeRD invoice sent to a government entity (using the XRechnung profile) must pass all BR-DE validation rules.
In France, a Factur-X invoice submitted through a PDP must use at least the EN 16931 profile and include French-specific fields like the SIRET number. The format itself is valid, but the content requirements differ from Germany.
In Austria, ZUGFeRD is commonly used but has its own set of expectations around tax handling and the Austrian business identifier (UID-Nummer).
The format doesn't change. The validation rules layered on top of it do. This means a ZUGFeRD invoice that's perfectly valid in Germany might fail validation in France — not because the format is wrong, but because a French-specific field is missing.
PDF/A Conformance
Both Factur-X and ZUGFeRD require the PDF container to conform to PDF/A-3. In practice, this is where a lot of implementations break. Common issues include:
- Font embedding: PDF/A-3 requires all fonts to be embedded. Many PDF generators use system fonts without embedding them.
- Color space: PDF/A-3 requires ICC color profiles. RGB without a profile declaration fails.
- Transparency: Some transparency operations aren't allowed in PDF/A-3.
- JavaScript: Not allowed in PDF/A-3. Interactive form fields with scripts will fail.
These PDF/A compliance issues are format-level problems that affect both Factur-X and ZUGFeRD equally. If your PDF generator creates files that don't meet PDF/A-3, neither name for the format will save you.
Which Profile Should You Use?
This depends on what you're trying to accomplish:
Minimum — Use this only for internal archival or when you need a PDF with basic machine-readable routing data. Not suitable for any EU mandate.
Basic WL — Useful when you need header-level data without line items. Some legacy systems process invoices at the header level only. Not mandate-compliant.
Basic — Provides line-item detail but uses a data model that predates EN 16931. Fine for voluntary e-invoicing where both parties agree on the format. Not mandate-compliant.
EN 16931 (Comfort) — This is the profile you want for most purposes. It satisfies EU mandate requirements and provides a complete structured invoice. If someone asks you to send a Factur-X or ZUGFeRD invoice that's EN 16931 compliant, this is what they mean.
Extended — Use this when you need to include data beyond what EN 16931 defines — additional delivery information, complex payment terms, industry-specific fields. It's a superset of EN 16931, so it's also compliant. But your trading partner needs to be able to process the extra fields, or at minimum ignore them gracefully.
XRechnung — Use this specifically when sending to German public sector entities that require XRechnung compliance. This profile adds the BR-DE business rules on top of EN 16931. Don't use it for French invoices — the German-specific rules don't apply there.
For most businesses operating in the EU, EN 16931 is the right answer. It's the common denominator across mandates, it carries enough data for processing, and it doesn't impose country-specific rules that could conflict with other markets.
Common Validation Pitfalls
Whether you're generating Factur-X or ZUGFeRD, these are the issues that most frequently cause validation failures:
1. Wrong Profile for the Use Case
You generate a Minimum profile invoice and submit it to a French PDP or German government platform. It fails because the mandate requires EN 16931 level data. Check what your PDF generator defaults to — many set Minimum as the default because it requires the least data input.
2. PDF/A-3 Compliance Failures
Your PDF looks fine visually but fails format validation because it doesn't conform to PDF/A-3 archival requirements. Non-embedded fonts are the most common culprit. Test your PDF output with a dedicated PDF/A validator before worrying about the XML content.
3. XML-PDF Mismatch
The XML data says one amount; the visual PDF says another. This happens when the PDF is generated from a different template than the XML, or when rounding is handled differently between the two generation paths. While the XML is authoritative, a mismatch raises questions and may trigger manual review.
4. Missing or Outdated Metadata
The XMP metadata in the PDF must correctly declare the Factur-X conformance level, version, and namespace. Older PDF libraries sometimes use ZUGFeRD 1.0 metadata structures that don't match the current specification.
5. Old Filename Convention
Using zugferd-invoice.xml instead of factur-x.xml as the embedded XML filename. Modern validators expect factur-x.xml. Some are lenient about this; others are not. Use the correct filename and avoid the ambiguity.
6. Encoding Issues
The embedded XML must be UTF-8 encoded. Some PDF embedding tools re-encode the attachment or strip the BOM, causing XML parsing failures when the validator tries to extract and read the file.
The Bottom Line
Factur-X and ZUGFeRD are the same format. If your system generates valid ZUGFeRD 2.3 invoices, those invoices are also valid Factur-X 1.1 invoices. The specification is identical, the profiles are identical, the XML schema is identical.
What changes is the context:
- In Germany, you'll hear "ZUGFeRD" and need to consider BR-DE rules for government invoicing
- In France, you'll hear "Factur-X" and need to consider French-specific requirements like SIRET numbers and PDP routing
- Across borders, use the EN 16931 profile and call it whatever your trading partner prefers
The format name doesn't affect validation. The profile level and the country-specific content rules do. Focus on generating EN 16931-compliant data with correct country-specific fields, and the naming question becomes irrelevant.
For a deeper comparison of the XRechnung and ZUGFeRD approaches, see our XRechnung vs ZUGFeRD technical comparison. For format-specific learn pages, check out Factur-X explained, ZUGFeRD explained, and CII explained.
FAQ
Is Factur-X the same as ZUGFeRD?
Yes. Since 2019, Factur-X and ZUGFeRD 2.x are the same technical specification maintained jointly by France and Germany. The PDF structure, XML schema, profiles, and validation rules are identical. The only difference is the name — France uses Factur-X, Germany uses ZUGFeRD.
Which profile do I need for EU e-invoicing mandates?
You need the EN 16931 profile (sometimes called "Comfort") at minimum. The Minimum, Basic WL, and Basic profiles don't carry enough structured data to satisfy EU e-invoicing mandates. The Extended profile also works, as it's a superset of EN 16931.
Can I use ZUGFeRD for French e-invoicing?
Yes, because ZUGFeRD and Factur-X are the same format. A ZUGFeRD invoice with the EN 16931 profile is technically identical to a Factur-X EN 16931 invoice. Just make sure the invoice includes French-specific fields (like the SIRET number) and that the XML attachment is named factur-x.xml.
What XML format is inside Factur-X / ZUGFeRD?
The embedded XML uses the CII (Cross-Industry Invoice) syntax, specifically UN/CEFACT SCRDM (Supply Chain Reference Data Model). It's not UBL. If your systems generate UBL invoices, you'll need a conversion step to create the CII XML for embedding in the PDF. Learn more about CII and UBL on our learn pages.
Why does my ZUGFeRD invoice fail validation even though the XML is correct?
Usually because the PDF container doesn't conform to PDF/A-3 requirements. The most common causes are non-embedded fonts, missing ICC color profiles, or incorrect XMP metadata. Validate the PDF/A-3 compliance separately from the XML content — they're two different validation checks that both need to pass.
Should I use ZUGFeRD or XRechnung in Germany?
It depends on the recipient. For government entities (B2G), XRechnung is generally required — you can either send a pure XRechnung XML or a ZUGFeRD PDF with the XRechnung profile. For B2B transactions, both XRechnung and ZUGFeRD (EN 16931 profile or higher) are accepted. ZUGFeRD is often preferred for B2B because the PDF visual representation is convenient for accounting teams that still process invoices visually. See the XRechnung vs ZUGFeRD comparison for a detailed breakdown.
What's the current version of Factur-X / ZUGFeRD?
As of 2026, the current version is ZUGFeRD 2.3 / Factur-X 1.1. Both version numbers refer to the same specification. When generating invoices, use the current version's profiles and schema to ensure compatibility with modern validators and receiving systems.
Does the embedded XML filename matter?
Yes. The specification requires the embedded XML to be named factur-x.xml. Older implementations used zugferd-invoice.xml, but current validators expect the Factur-X naming convention. Using the wrong filename can cause validation failures or prevent receiving systems from finding the structured data inside the PDF.
Check Your Compliance Status
Find out exactly what your business needs to do for e-invoicing compliance.
Use Obligation Finder