The question is almost always put the wrong way round. XRechnung and ZUGFeRD are not competitors you pick between like two programs — they are two wrappings of the same data. Both satisfy the e-invoicing obligation. What differs is the shell, and who asks for which shell.
The difference in one table
| XRechnung | ZUGFeRD / Factur-X | |
|---|---|---|
| What you get | an XML file | a PDF file with XML inside |
| Visible page | none | yes, opens like any PDF |
| Syntax | UBL or CII | CII |
| Relation to the standard | CIUS — a narrowing | CIUS; in the EXTENDED profile also an extension |
| Who typically asks for it | public authorities | businesses among themselves |
| Maintained by | KoSIT, German federal and state governments | FeRD (Germany), FNFE-MPE (France) |
What XRechnung is
XRechnung is the German standard for structured invoicing with public administration: a core invoice usage specification (CIUS) of EN 16931 that narrows the core model and makes mandatory a few fields the standard leaves optional. The best-known example is the Leitweg-ID in BT-10, which addresses the authority.
On versions: version 3.0 has applied since 1 February 2024 and, according to its maintainers, stays in force until at least 31 July 2027. A pre-release of XRechnung 4.0 was published in September 2026; the final version is expected in spring 2027. The publishing rhythm has moved from two releases a year to one main release.
Which version a file is, the file says itself — in BT-24. For XRechnung 3.0 the identifier reads urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Up to version 2.3 it read urn:xoev-de:kosit:standard:xrechnung_2.3: the namespace changed with 3.0, and that is exactly what older tools trip over.
What ZUGFeRD is
ZUGFeRD packs the same data differently: a PDF/A-3 file that shows the readable invoice page and carries the XML as an attachment. Click the file and you see an invoice; read it in and you get data. In France the same format is called Factur-X.
ZUGFeRD has profiles — from the stripped-down MINIMUM to EXTENDED. For the obligation, ZUGFeRD counts from version 2.0.1 except MINIMUM and BASIC WL: those two lack mandatory items and do not count as an e-invoice.
And there is a bridge between the two worlds: ZUGFeRD has a profile called XRECHNUNG. Such a file is a PDF with a visible page whose embedded XML follows the XRechnung rules and carries their identifier in BT-24. Where an authority wants XRechnung but accepts PDF attachments, this is the variant that satisfies both sides.
When to use which
| Your situation | What makes sense |
|---|---|
| Invoicing a German public authority | XRechnung; the address is the Leitweg-ID, the route usually their invoice portal |
| Invoicing a business | ZUGFeRD — the other side can read it even if their software cannot yet import it |
| Customer names no format | ZUGFeRD in the EN 16931 profile; it is the version that gets stuck nowhere |
| Customer insists on XRechnung but wants to see something | ZUGFeRD in the XRECHNUNG profile |
| Recipient abroad via Peppol | UBL — the mandatory syntax there; the access point converts the CII out of ZUGFeRD |
The order of questions is always the same: first establish what the other side accepts, then pick the format — not the other way round. A format the recipient cannot process is not a better format.
What both have in common
- The same field numbers. BT-1 is the invoice number in both, BT-112 the gross total in both — see the structure of the XML.
- The same business rules. The standard's
BR-families apply to both; XRechnung adds itsBR-DE-rules on top — see business rules. - The same legal standing. Both are e-invoices for the purposes of the obligation; in the hybrid format the structured part prevails.
- The same retention. What you keep is the structured part, not a printout — see retention.
How the same field looks in both syntaxes
“The same fields” does not mean “the same element names”. The standard hands out numbers, the syntax hands out names — which is exactly where the impression comes from that these are entirely different files. The invoice number, BT-1, sits at:
| Syntax | Where BT-1 sits |
|---|---|
| CII — that is, in ZUGFeRD and Factur-X | rsm:ExchangedDocument/ram:ID |
| UBL — as in XRechnung and on the Peppol network | ubl:Invoice/cbc:ID |
For the bookkeeping this changes nothing: it is BT-1 both times, and the same rule applies both times. In practice it only means that software reading one syntax does not thereby read the other — and that converting between them is renaming, not losing data.
Four misconceptions that keep going around
| Claim | How it actually is |
|---|---|
| “XRechnung is mandatory for everyone.” | What is mandatory is the e-invoice, not a particular format. XRechnung is typically what the administration asks for. |
| “ZUGFeRD is just a PDF.” | The data sits inside it as XML and is the part that governs. The page is the addition, not the core. |
| “You cannot read an XRechnung.” | You need a viewer instead of a PDF reader — but it is readable, and the administration does exactly that. |
| “You have to commit to one.” | Nothing stops you sending XRechnung to authorities and ZUGFeRD to business customers. The data behind them is the same. |
What E-Rechnung Pro can do here — and what it cannot
Checking: both. The validator takes PDF and XML and runs the standard's rules plus the German add-ons over them. For an incoming XRechnung that is the shortest route to the question of whether it is clean.
Issuing: ZUGFeRD and Factur-X, in the BASIC, EN 16931 and EXTENDED profiles. The service does not produce XRechnung. If you need one, it comes out of your accounting system — and gets checked here before it goes to the portal.
One detail from practice: validation tools often run the XRechnung rules over every file. A perfectly correct ZUGFeRD invoice then reports rule BR-DE-21 as violated — it demands the XRechnung identifier in BT-24, which naturally is not there. That is not a fault in your file; our report therefore subtracts that message.
Frequently asked questions
Is XRechnung better than ZUGFeRD?
Neither is better. They are two shells for the same data; which one fits is decided by the recipient.
Can I send a ZUGFeRD file to a public authority?
Only if their intake allows it. What they ask for is usually XRechnung — and the ZUGFeRD XRECHNUNG profile is made for exactly this case.
How do I tell what I have received?
By the file extension and by BT-24: an .xml file with the KoSIT identifier is an XRechnung, a PDF with embedded XML is a ZUGFeRD invoice. The validation report names both.
Do I have to prepare for XRechnung 4.0 now?
No. Version 3.0 applies until at least 31 July 2027; in September 2026, 4.0 existed only as a pre-release. It becomes relevant when your software supports it and the recipient asks for it.
Which syntax does an XRechnung use — UBL or CII?
Both are permitted. Which one you get depends on the sender; the field numbers are the same in both.
And XRechnung abroad?
It plays no role there — it is a German standard. Across borders what counts is EN 16931 and, where delivery runs over Peppol, that network's own specification in UBL.
Does a ZUGFeRD invoice in the MINIMUM profile count as an e-invoice?
No. MINIMUM and BASIC WL are excluded — they lack mandatory items. Use EN 16931.
In short
- Two shells, one content: XRechnung is plain XML, ZUGFeRD a PDF with XML inside.
- Authorities mostly XRechnung, businesses mostly ZUGFeRD — and the XRECHNUNG profile bridges the two.
- XRechnung 3.0 has applied since 1 February 2024, until at least 31 July 2027; 4.0 is announced, not in force.
- BT-24 gives the version away — with 3.0 the namespace in it changed.
- You do not have to choose: the recipient says what goes where.
Not sure what just landed in your inbox? Upload the file — the report names the format, the profile and every rule that was broken.