XRechnung: the German e-invoice standard explained

XRechnung is Germany's national specification of the European e-invoice norm EN 16931: a pure XML invoice in UBL or UN/CEFACT CII syntax, without a PDF, maintained by KoSIT for the IT-Planungsrat. It is the format that federal buyers require and one of the two formats that satisfy the German B2B e-invoicing obligation under § 14 UStG. The valid version on 3 September 2026 is XRechnung 3.0.2; XRechnung 4.0, built on the revised EN 16931-1:2026, is in preparation.

What is XRechnung?

XRechnung is a Core Invoice Usage Specification (CIUS) of EN 16931. It takes the European semantic model of an invoice and narrows it for German use: it makes some optional elements mandatory (for example the buyer reference, the seller's contact details and payment information), restricts code lists and adds German business rules with identifiers of the form BR-DE-nn. An XRechnung is therefore always a valid EN 16931 invoice, but not every EN 16931 invoice is a valid XRechnung.

The standard was created to transpose Directive 2014/55/EU, which obliges public bodies to accept EN 16931 e-invoices. Since the Wachstumschancengesetz it doubles as a B2B format: the BMF names it in UStAE 14.1 Abs. 13 as a purely structured format that meets the requirements of § 14 UStG. The German context is on the Germany hub; the norm itself on EN 16931.

KoSIT (Koordinierungsstelle für IT-Standards) operates XRechnung on behalf of the IT-Planungsrat, the federal-state body for public IT. It publishes the specification, a Schematron rule set, a validator configuration, a test suite of example invoices and an XSLT visualisation component, all as open source on GitHub.

Which syntax: UBL or CII?

Both. EN 16931-2 lists two syntaxes and XRechnung supports both with identical semantics:

Choose the syntax your counterpart or tooling already uses. If you send over Peppol, UBL is the natural choice because Peppol BIS Billing 3.0 is UBL-based. If you also produce ZUGFeRD, CII lets one XML serve both: the ZUGFeRD profile XRECHNUNG embeds an XRechnung-conformant CII file in a PDF/A-3.

There is also the Extension XRechnung, a conformant extension of EN 16931 for cases the core model cannot express, for example sub-invoice lines in construction. Extension files carry a different specification identifier; the validator configuration covers them, but check whether a given receiver accepts them.

Which version is current, and what about XRechnung 4.0?

XRechnung 3.0.2 is the valid version. Version 3.0 entered into force on 1 February 2024 and 3.0.2 has received bugfix releases since July 2024; the latest bundle is dated 31 January 2026. KoSIT moved to one main release per year in 2023, so the version number changes rarely while the validator configuration is refreshed more often.

XRechnung 4.0 is the successor. It implements the revised European norm EN 16931-1:2026, which KoSIT reports has been available in English since March 2026, with the German translation expected by 30 September 2026. The revision adds more than fifty business terms and seven business groups, allows several orders and deliveries in one invoice and supports XML attachments in the core model. KoSIT's statement of 1 September 2026 announces a preview of XRechnung 4.0 for September 2026 that is not intended for production, says the final bundle depends on CEN publishing the syntax bindings and validation artefacts, and foresees parallel use of the current and the new version until March 2029.

How do I validate an XRechnung?

Run the file through the KoSIT validator with the official XRechnung configuration. The validator is a Java application (validationtool) published at github.com/itplr-kosit/validator; the configuration for XRechnung is a separate, dated ZIP from github.com/itplr-kosit/validator-configuration-xrechnung. The configuration contains the XML schemas for UBL 2.1 and CII D16B, the Schematron rules of EN 16931 and the additional rules of the CIUS and the Extension XRechnung. Validation happens in two stages:

1. Schema validation (XSD) — is the XML well-formed and structurally valid UBL or CII? A failure here is a format error in the sense of the BMF letter: the file is not an e-invoice.
2. Schematron validation — do the business rules hold? Rules are prefixed BR- (EN 16931 core), BR-CO- (calculation), BR-S-/BR-AE- and similar (tax categories) and BR-DE- (German). The validator produces a report with the verdict "acceptable" or "rejected" and lists every failed rule with its XPath.

A typical invocation:

java -jar validationtool-1.6.2-standalone.jar \
  -s validator-configuration-xrechnung_3.0.2_2026-01-31/scenarios.xml \
  -r validator-configuration-xrechnung_3.0.2_2026-01-31 \
  -h invoice.xml

Two practical notes. First, rule severity matters: the BMF distinguishes format errors (not an e-invoice), business-rule errors (still an e-invoice, but possibly incorrect) and content errors in the VAT mandatory data (incorrect invoice); a missing buyer reference, for instance, is irrelevant for VAT but rejected by federal receivers. Second, keep the validation report — the BMF recommends it as evidence of due care. If you only need a quick check without installing anything, the free e-invoice checker runs the German rules on an uploaded file without storing it.

What is the Leitweg-ID and where does it go?

The Leitweg-ID is the routing address of a public buyer in Germany. It consists of a mandatory coarse part built from the official regional key (state, district, municipality), an optional fine part of up to 30 alphanumeric characters chosen by the authority, and a mandatory two-digit check number computed with ISO/IEC 7064 modulo 97-10, the same procedure as an IBAN; the parts are separated by hyphens. The contracting authority tells the supplier the Leitweg-ID with the order.

In the invoice it belongs in BT-10 Buyer reference — UBL cbc:BuyerReference, CII ram:BuyerReference — which XRechnung makes mandatory (rule BR-DE-15). When sending over Peppol it can additionally appear as the electronic address in BT-49. The Bund and several Länder require it; other Länder use their own references. For B2B invoices the field still has to be filled to pass XRechnung validation, but any agreed reference (an order number, a customer number) is acceptable there.

Where do I submit XRechnung to public buyers?

It depends on who the buyer is.

Federal administration (Bund)

Since September 2025 through one platform, the OZG-RE, into which the former ZRE was merged. Channels: web entry, file upload, e-mail and Peppol. The obligation for suppliers has applied since 27 November 2020 for direct awards from €1,000 net. The platform accepts XRechnung and, according to the federal information site, other EN 16931-conformant formats.

Länder and municipalities

Each state has its own e-invoicing regulation, portal and rules on whether suppliers must send e-invoices; several states connect their portal to Peppol. Follow the instructions of the buying authority.

Businesses (B2B)

No portal. E-mail, download or Peppol, as agreed. See receiving e-invoices and sending and receiving over Peppol.

How KRONENWERK handles this

SUPPORTED KRONENWERK generates XRechnung when a German company issues an invoice and validates the file at issuance with the KoSIT Schematron rules, cross-checked with the Mustang library; a file that violates a rule is not issued. The buyer reference — the Leitweg-ID for public buyers — is part of the invoice data, and the tax verdict per invoice (standard, reverse charge, exempt, and so on) is derived from the transaction's facts with the buyer's VAT ID checked against VIES. Incoming XRechnung files are read into bills. Delivery to federal or state portals by upload or e-mail is done by the business with the generated file; sending over Peppol goes through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery. Developers can create invoice drafts through the API described at e-invoicing API; issuing happens in the product after validation. See also the e-invoicing product page.