XRechnung: format, rules and validation explained

What XRechnung is — and is not

XRechnung is not a separate invention alongside the European standard but an expression of it. In technical terms: a CIUS, a core invoice usage specification. It takes EN 16931 and tightens it where German requirements are stricter — making optional fields mandatory and narrowing value ranges.

What it explicitly may not do is invent new fields. That is exactly why an XRechnung stays readable for any European recipient who understands the standard. They see an unusually completely filled-in document, not a foreign format.

🔴 The most widespread misconception: that XRechnung is a PDF with extra data. It is not. It is pure XML. Double-click the file and you see markup. The format that brings a readable PDF with it is called ZUGFeRD.

Two syntaxes, one content

XRechnung inherits the two-track nature of EN 16931: it exists in UBL and in CII. Both variants carry the same fields under the same BT numbers, are checked by the same rule set, and are equally conformant.

You can tell them apart by the root element:

1<!-- UBL -->
2<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
3  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>
4  <cbc:ID>INV-2026-0042</cbc:ID>

1<!-- CII -->
2<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
3  <rsm:ExchangedDocument>
4    <ram:ID>INV-2026-0042</ram:ID>

The CustomizationID (BT-24) is the field by which a recipient recognises that they are holding an XRechnung and which rule set to check against. It is not a formality — put the wrong identifier there and the recipient validates against the wrong rule set.

The German add-on rules

Beyond the European rules, XRechnung brings its own. They carry identifiers like BR-DE-… and DE-R-…, and in practice they are the most common cause of a rejection — not malformed XML.

The three that cause the most work:

A document can satisfy the European standard completely and still fail these. That is not a contradiction — it is the purpose of a CIUS.

The Leitweg-ID

Invoices to public administration need a delivery address inside the government network — the Leitweg-ID. It sits in BT-10, the buyer reference, that is, in a regular field of the European standard that Germany fills by binding rule.

1{
2  "countrySpecific": {
3    "countryCode": "DE",
4    "leitwegId": "991-12345-67"
5  }
6}

You get the ID from the customer. It cannot be derived, and it cannot be looked up.

Where an XRechnung lands

The federation runs two intake platforms — ZRE for the direct federal administration and OZG-RE for connected bodies. Which one applies is revealed by the Leitweg-ID. States and municipalities partly run platforms of their own.

For the sender this changes nothing about the document: the same file is correct everywhere, as long as the Leitweg-ID is right.

XRechnung and ZUGFeRD together

The two are not mutually exclusive. ZUGFeRD defines a profile called XRECHNUNG that satisfies the German add-on rules — the file is then a PDF with embedded XML and a conformant XRechnung.

That is the practical way out for anyone who does not want to maintain two output paths: one file that goes to public authorities and to companies alike. The price is that you bind yourself to the strictest rule set, even when the recipient is a company.

Validate before you send

The German add-on rules are the reason that validating against EN 16931 alone is not sufficient. Validate against the XRechnung rule set in the version your recipient runs — versions change not only rules but occasionally their severity, and an invoice that passed with a warning last year can fail hard today.