Every name on this list is the same European standard, EN 16931, dressed for a different occasion. Once you see that, the choice stops being a technology decision and becomes a simple question about your customer: who are they, and in which country? This map is for finance teams outside Germany that suddenly need to produce "a ZUGFeRD" or "an XRechnung" and want to know what they are actually being asked for.
The map
| Name | What it is | Who expects it |
|---|---|---|
| EN 16931 | The European semantic standard: which fields an e-invoice has and what they mean | Everyone, underneath everything below |
| ZUGFeRD | Germany's hybrid: a normal-looking PDF with the invoice data embedded as XML | German business customers (B2B) |
| Factur-X | The same hybrid standard, co-published with France; ZUGFeRD and Factur-X are technically identical | French counterparties; the French reform runs on it |
| XRechnung | Germany's pure-XML profile with extra German rules, no visual page | German public-sector buyers (B2G) |
| Peppol BIS | An EN 16931 profile used on the Peppol delivery network | Buyers who ask for delivery "via Peppol" |
Two consequences save the most confusion. First, ZUGFeRD and Factur-X are one standard with two names, so a file produced for a German customer is structurally a Factur-X and vice versa. Second, Peppol is primarily a transport network: "send it via Peppol" is a statement about delivery, not about a fifth data format.
The one question that decides
Is your customer a German business or a German public authority?
- A business: send ZUGFeRD. Their accounting system reads the embedded data; the humans see a normal PDF; ordinary email is a fully compliant channel. What Germany actually demands from foreign suppliers, and when you can decline the whole exercise, is covered in Your German customer wants an e-invoice.
- A public authority: send XRechnung, with the buyer's Leitweg-ID routing code. Expect a portal or Peppol as the submission channel and German-language rejection reports; the rejection guide translates the codes when one bounces.
- A French customer: the same hybrid file under its French name; invoices there flow through the French platform system. Our sibling service Facturoute covers the French side.
Deadlines and duties on the German side are mapped in the e-invoicing guide for English-speaking businesses.
Syntax, for those who ask
Under the hood there are two XML syntaxes for the same semantics: CII (used inside ZUGFeRD/Factur-X, and one of the two XRechnung syntaxes) and UBL (the other XRechnung syntax, and the one Peppol favours). You rarely choose: the format choice implies the syntax, and when a buyer insists, you convert CII to UBL or UBL to CII in one step. For the anatomy of each format, sample files included, the deep guides are the ZUGFeRD format guide and the XRechnung format guide.
Producing the file without new software
Both German formats come out of a browser form or a conversion of the invoice you already produce: create a ZUGFeRD invoice or an XRechnung directly. If the invoice language worries you, it should not: English invoices are fine in Germany, because the compliance-critical parts travel as codes.
Legal position as at September 2026, last reviewed on 25 September 2026. Based on EN 16931, the ZUGFeRD/Factur-X specifications (one co-published standard), the XRechnung specification, and the Peppol BIS Billing documentation.
Frequently asked questions
Are ZUGFeRD and Factur-X really the same thing?
Yes, technically identical and co-published by the German and French bodies. The two names reflect the two markets; a compliant file is both at once.
Is Peppol a format I need to support?
Peppol is first of all a delivery network. Some buyers want invoices delivered through it, and on the network the Peppol BIS profile of EN 16931 is the common currency. For German B2B invoicing by email, you do not need Peppol at all.
Which format should we standardize on internally?
For German business customers, ZUGFeRD: it is the least disruptive on the receiving side because it still looks like a PDF. Keep XRechnung as the exception for public-sector buyers, driven by the buyer's demand, not by preference.
Do we need different data for each format?
No, that is the point of the shared standard. The same semantic invoice fills all of them; what changes is the wrapper (hybrid PDF versus pure XML) and a few extra German mandatory fields on the public-sector profile.
Our ERP exports UBL. Is that usable in Germany?
For XRechnung, yes: UBL is one of its two accepted syntaxes. For ZUGFeRD, the embedded XML is CII, so you convert UBL to CII in one step; the semantics carry over because both syntaxes express the same standard.