XRechnung vs ZUGFeRD: which to use, and when

The two names dominate every German conversation about electronic invoicing, and they are not — as many people assume — alternatives in the same category. They represent two different approaches to the same problem, and the choice between them is a real architectural decision.

What each one actually is

XRechnung is a CIUS: a profile that constrains the European standard EN 16931 with extra rules to make it usable by German receivers. An XRechnung invoice is pure XML — either UBL 2.1 or UN/CEFACT CII — and contains no human-readable representation of itself. To look at one, you open it in a text editor or pass it through a renderer.

ZUGFeRD is a hybrid format: a PDF/A-3 file with a CII XML attachment embedded inside it. The PDF is what humans see; the embedded XML is what software processes. Both layers describe the same invoice. From version 2.1 onwards, ZUGFeRD is technically identical to Factur-X; the two names simply reflect German and French branding of the same standard.

In other words: the difference is not "two competing German invoice formats". The difference is "structured-only" vs "structured-plus-presentation".

Both are legally valid in Germany

Since the German B2B mandate of January 2025, both XRechnung and ZUGFeRD (in profile EN 16931 or EXTENDED) are accepted electronic invoices under §14 UStG. There is no legal preference for one over the other. A receiver who insists on only one format is making a business choice, not invoking a legal requirement.

This is the practical answer to the most common question: "do we have to switch from ZUGFeRD to XRechnung?" The answer is no, provided the ZUGFeRD profile is EN 16931 or higher. Lower profiles (MINIMUM, BASIC WL, BASIC) are not legally compliant electronic invoices on their own.

Where the real differences live

The two formats are functionally equivalent for accounting purposes. The differences that matter in day-to-day operation are:

Human-readability. ZUGFeRD wins. A bookkeeper or auditor can open the file in any PDF reader. An XRechnung file requires either a renderer or a willingness to read XML directly. For organisations whose invoicing process still involves people looking at invoices — and that is most organisations — ZUGFeRD is friendlier.

File size. XRechnung wins. A pure XML invoice is typically 5–30 KB. A ZUGFeRD file is typically 100–500 KB, dominated by the PDF. Per file the difference is negligible; at scale it adds up.

Strictness of validation. A tie, in principle. Both are validated against the same EN 16931 + BR-DE-* schematron rules. In practice ZUGFeRD adds two extra failure modes: the PDF/A-3 layer can be malformed independently of the XML, and the two layers can drift out of sync. Pure XRechnung has neither problem.

Producer cost. ZUGFeRD is usually cheaper to produce when an existing system already generates PDFs. The marginal effort is "embed an XML attachment in our existing PDF pipeline". Building a pure XRechnung producer from scratch is a larger integration: the system must construct UBL or CII directly, with no PDF as a fallback.

Receiver cost. XRechnung is cheaper to consume if the receiving system is fully automated. There is no PDF to discard, no extraction step, no risk of layer drift. For a high-volume accounts payable team, pure XML is simpler.

Public-sector compatibility. XRechnung is the format the German public-sector portals (ZRE, OZG-RE) actively expect. ZUGFeRD is technically accepted but the portals still treat it as a special case. For invoicing public administration, XRechnung remains the path of least resistance.

When XRechnung is the right pick

• You issue invoices in volume to German public administration. The portals are built around XRechnung.
• Both you and your customers are fully integrated for structured invoicing, and the PDF wrapper is dead weight.
• You issue from an ERP or invoicing platform that already has a clean structured-XML output path.
• You want the smallest file size and fastest receiver-side processing, and your receivers do not need a human-readable layer.

When ZUGFeRD is the right pick

• You issue invoices to a mixed audience: some customers fully integrated, others still working from PDFs in inboxes.
• Your existing system already generates PDF invoices, and adding the embedded XML is a smaller integration than rebuilding a structured-XML pipeline.
• You want a single archival artefact that satisfies both human-inspection and machine-processing needs.
• Your customers have not committed to a specific format and you want the safest bet on broad acceptance.

A note on profile

If you choose ZUGFeRD, choose the EN 16931 or EXTENDED profile — never MINIMUM, BASIC WL, or BASIC. The lower profiles do not meet the German B2B legal threshold; they exist for routing-only or transitional use cases. A receiver whose tax department will challenge the file will challenge a BASIC ZUGFeRD invoice for the same reason they would challenge a paper invoice: it does not carry the structured information the law now requires.

The honest recommendation

For most organisations starting fresh in 2025–2026, ZUGFeRD in the EN 16931 profile is the safer default. It works with every legal receiver, satisfies the human-readability expectation that is still widespread in German business culture, and does not require customers to upgrade their tooling. The cost is a slightly larger file and a slightly more complex producer pipeline.

For organisations that already invoice public administration heavily, or whose receivers are uniformly integrated for structured invoicing, XRechnung is the cleaner choice. It removes a layer of dead weight and matches the format the public-sector portals were designed for.

Neither answer is permanently right. As tooling matures and structured invoicing becomes the universal default, the human-readability argument for ZUGFeRD will weaken, and pure XRechnung will become the natural choice for everyone. That is probably a five-to-ten-year process, not a two-year one.