XRechnung vs. ZUGFeRD: Choosing the Right E-Invoice Format

Germany's e-invoicing mandate isn't a distant policy discussion. It's a technical deadline with real consequences for every software vendor, ERP provider, and finance team operating in the DACH region. At the center of that deadline sits a question that shapes both your implementation path and your compliance posture: XRechnung or ZUGFeRD?

The answer isn't purely technical. It depends on your client base, your existing infrastructure, and whether the people approving invoices want to read them or just process them. This article breaks down the XRechnung vs ZUGFeRD decision with precision and tells you which format to reach for when.

A quick bit of context first. A PDF emailed to a customer is no longer an electronic invoice in the legal sense; the EU now expects a structured, machine-readable dataset, which is exactly why a plain PDF fails the structured-invoice test. Both XRechnung and ZUGFeRD implement the same European semantic data model, EN 16931, so they carry identical invoice fields under the hood; if you want the field-level detail, our breakdown of what EN 16931 means for European e-invoicing covers it. Germany phases the obligation in over the 2025-to-2028 mandate timeline, and B2G has required structured invoices since 2020. With that settled, let's get to the actual comparison.

XRechnung is Germany's national implementation of EN 16931. It's a pure XML format: no visual component, no embedded PDF, no human-readable layer. What you get is a structured data file that conforms to either UBL (Universal Business Language) or CII (Cross Industry Invoice) syntax, both valid expression formats under the EN 16931 semantic model.

KoSIT (Koordinierungsstelle für IT-Standards) maintains the format. KoSIT publishes the XRechnung specification, validation rules, and Schematron files, the technical ruleset used to verify that a given XML file actually meets the standard.

What XRechnung looks like in practice:

The "no visual" rule trips people up. XRechnung doesn't include a PDF at all. A recipient who wants to eyeball the invoice has to open it in a rendering tool: the free federal viewer application or one built into their ERP. That's deliberate. The standard puts data integrity and machine processing ahead of human convenience, and it makes no apology for it.

Where XRechnung is mandatory:

Why pure XML is an advantage for automation:

When an ERP system receives an XRechnung file, there's no ambiguity. The invoice total isn't a number rendered in a font at a specific pixel location. It's a value in a defined XML field with a defined data type. ERP systems parse, validate, and process these files with zero manual intervention. For high-volume invoice processing, that's not a convenience feature. It's the foundation of scalable accounts payable automation.

The tradeoff is real, though. XRechnung isn't built for human-to-human communication. If your client base includes businesses where finance staff need to eyeball invoices before approval, pure XML creates friction at exactly the wrong moment. Send a raw .xml file to a procurement manager at a family-owned supplier and you'll get a confused email back, not a paid invoice.

ZUGFeRD solves the human-readability problem without giving up machine-processability. It does this through a hybrid architecture: a PDF/A-3 file (ISO 19005-3) with an embedded XML dataset. A human opens the PDF; the ERP system reads the embedded XML and ignores the visual layer entirely. The same document serves the bookkeeper and the parser, which is the whole point.

The key thing to understand for a format choice is the legal hierarchy. In ZUGFeRD 2.x the XML data is legally authoritative: if the PDF on screen and the embedded XML ever disagree, the XML wins. That has a direct storage consequence later, because it's the XML you must preserve unaltered, not the pretty page wrapped around it. It also means a sloppy implementation that renders a number in the PDF but writes a different value into the XML produces an invoice that is technically valid and substantively wrong, the kind of bug that surfaces in an audit rather than in testing.

ZUGFeRD ships in several profiles of increasing data richness, from a stripped-down MINIMUM up through an EN 16931 profile that matches XRechnung field-for-field in data content, and an EXTENDED profile for industry-specific needs. There's one more fact that matters for cross-border invoicing: ZUGFeRD 2.x and the French Factur-X standard are the same thing. One file satisfies both the German and French jurisdictions with no conversion step. The profile granularity, the PDF/A-3 internals, and the ZUGFeRD-equals-Factur-X mechanics are covered in depth in our Factur-X hybrid format guide; here it's enough to know the embedded file is named factur-x.xml and the EN 16931 profile is the one most B2B buyers will ask for.

Why B2B prefers ZUGFeRD:

In B2B transactions, approval workflows still involve a human more often than not. A CFO signing off on a high-value invoice wants to see the document, not squint at an XML file in a text editor. ZUGFeRD gives both audiences what they need: the finance team sees a clean PDF, the ERP system processes the embedded XML. For software vendors fitting compliant e-invoice archiving into their platforms, that hybrid nature is a gift, because it supports messy real-world client workflows without forcing anyone to change how they approve a bill.

The XRechnung vs ZUGFeRD choice comes down to one axis: optimize for machine-only processing, or support both machine and human workflows. The table below captures the structural differences that drive that decision.

Read that table top to bottom and a pattern emerges. The two formats are equivalent on the only row that touches data content, EN 16931 compliance, and differ on everything that touches delivery and human handling. That's the real headline of the XRechnung vs ZUGFeRD comparison: it isn't a fight about data quality, it's a fight about packaging.

Validation and EN 16931 compliance:

Both formats must pass EN 16931 semantic validation. For XRechnung, that means running the XML through the KoSIT Schematron rules. For ZUGFeRD, the embedded XML is extracted and validated against the same EN 16931 rules. Tools like Mustang Project and the official KoSIT validator handle this programmatically, so a vendor can wire validation straight into the invoice pipeline and reject a malformed file before it ever reaches a customer.

Transmission: XRechnung is commonly routed over the Peppol network, while ZUGFeRD usually travels by email or a direct API integration. The mechanics of Peppol's four-corner model and access points are a topic of their own, covered in our Peppol network guide.

Handling attachments:

This is one of the underrated differences in the XRechnung vs ZUGFeRD debate. ZUGFeRD's PDF/A-3 container can embed extra files alongside the invoice XML, such as delivery notes, contracts, or supporting documentation, all inside a single object. XRechnung allows a limited attachment mechanism within the XML structure, but it's far less flexible. For complex invoices that travel with paperwork, ZUGFeRD's container model has a clear practical edge, and it's a deciding factor for industries like construction or logistics where an invoice rarely arrives alone.

Picking a format is step one. Whichever you land on, the file then has to survive ten years of regulatory scrutiny, and that's a separate problem with its own rules. An XRechnung XML and a ZUGFeRD PDF/A-3 must both be retained in their original, unaltered format for the full retention period; converting either one for storage breaks the original-format requirement.

How you satisfy that is out of scope here, but the three references worth your time are: GoBD-compliant archiving for the German bookkeeping rules, the e-invoice archiving requirements for integrity and audit trail for why a plain file share isn't enough, and tamper-proof versus merely secure storage for the cryptographic-proof angle an auditor actually cares about. Get the format right first, then read those before you design the archive.

For most German businesses operating in 2025 and beyond, the honest answer is: both. But which one you stand up first depends on your primary transaction type.

Decision matrix:

The "both" approach for ERP vendors:

Modern ERP systems can't afford format lock-in. A mid-market manufacturer might invoice a federal ministry (XRechnung via Peppol) and a private logistics partner (ZUGFeRD via email) in the same week. The platform has to generate both formats from one data source, validate each against EN 16931, transmit through the right channel, and archive both in a compliant repository. That's why the smart move is a format-agnostic e-invoicing module rather than betting on a single standard. The XRechnung vs ZUGFeRD question stops being either-or the moment your software has to serve more than one customer.

A practical sequencing tip: if you sell to the public sector at all, build XRechnung output and Peppol transmission first, since that's the hard mandatory deadline, then layer ZUGFeRD on top for your B2B customers, where you have more room to choose. The reverse order leaves you scrambling when a government tender requires XRechnung you can't yet produce.

If you're an ERP or accounting platform deciding whether to build this yourself or embed it, two companion reads go deeper than this format piece does: white-label e-invoice archiving for software vendors on shipping it under your own brand, and turning compliant archiving into a revenue stream on the business case for treating compliance as a product rather than a cost center.

XRechnung and ZUGFeRD aren't rival standards fighting for the same slot. They're complementary tools for different transaction contexts. XRechnung delivers pure machine-processability for B2G workflows, where no human needs to read the file. ZUGFeRD delivers hybrid usability for B2B settings where someone still wants to look before they approve. A serious e-invoicing implementation in Germany needs both, ideally generated from the same underlying data so the two never drift apart.

So the decision rule is simple. Are you invoicing the government? XRechnung, full stop. Selling B2B where a person signs off? Lead with ZUGFeRD's EN 16931 profile and keep XRechnung in your back pocket. Crossing the German-French border? ZUGFeRD doubles as Factur-X, so one file does the job. Get that choice right and the rest of your pipeline, validation, transmission, and the ten-year archive, has a clean foundation to build on.

If you're building or upgrading an e-invoicing module for your ERP platform, OriginVault's invoice archiving layer handles tamper-proof, GoBD-ready retention under your own brand, integrated via a single API.