XRechnung: the German CIUS for electronic invoicing

XRechnung is Germany's national specification for electronic invoices — the layer that turns the abstract European standard into something concrete enough for the German tax administration to act on. It is not a file format; it is a Core Invoice Usage Specification (CIUS) that sits on top of EN 16931, tightening the European baseline to match what German law and German receiving systems require. XRechnung is maintained by KoSIT (Koordinierungsstelle für IT-Standards), a body jointly run by the German federation and the länder.

Legal scope and timeline

The XRechnung mandate has rolled out in several phases:

• November 2020. Federal authorities and most state administrations begin requiring XRechnung for invoices addressed to public administration above 1,000 €. The mandate progressively extends to all public-sector invoicing.
• January 2025. All German B2B recipients must be technically capable of receiving electronic invoices in an EN 16931-compliant format — XRechnung or Factur-X / ZUGFeRD. The PDF-by-email era is formally over for B2B.
• January 2027. Electronic invoicing becomes mandatory for issuing B2B invoices, with a final transitional carve-out for businesses below an 800,000 € annual turnover threshold.
• January 2028. The transitional period ends. Every B2B invoice between domestic German businesses must be issued in an EN 16931-compliant format.

The legal basis is the Wachstumschancengesetz of 2024, which amends §14 UStG to make the electronic invoice the default and the paper invoice the exception. For the broader legal and operational context — accepted formats, transmission channels, archival, and the Leitweg-ID system for the public sector — see E-invoicing in Germany.

Two syntaxes, one specification

A common source of confusion: XRechnung is not a single XML format. The specification permits invoices to be expressed in either of EN 16931's two endorsed syntaxes — UBL 2.1 or UN/CEFACT CII — and a compliant invoice in either form is equally valid. Receiving systems must handle both. In practice, the public sector tends to favour UBL while industry-issued invoices lean towards CII, but neither preference has the force of law. See UBL vs CII for the trade-offs.

XRechnung is also not the only legally valid format for the German B2B market. The hybrid PDF/XML format Factur-X / ZUGFeRD is equally accepted, and the choice between the two is a real architectural decision rather than a matter of legal preference — see XRechnung vs ZUGFeRD for the trade-offs.

What XRechnung adds to EN 16931

XRechnung's contribution is a set of additional business rules — the BR-DE-* family — that constrain or require fields the European baseline leaves optional. The most consequential additions are:

• Mandatory payment instructions (BR-DE-1). The invoice must specify how the buyer is to pay — typically a SEPA credit transfer with IBAN, or a direct debit mandate. Without it, automated processing on the receiving side is impossible.
• Mandatory seller contact (BR-DE-2, -5, -6, -7). A named contact point with telephone or email. Not just a generic info@ mailbox; a person or function the buyer's accounts payable team can address.
• Mandatory city and postal code for both seller and buyer (BR-DE-3, -4, -8, -9). The European baseline allows these to be absent in some cases; XRechnung does not.
• Buyer reference (BR-DE-15). Mandatory. For invoices to public administration, this is the Leitweg-ID — a routing identifier issued by the receiving authority.
• Restricted invoice type codes (BR-DE-17). Only a subset of UNTDID 1001 codes is permitted: 326 (partial), 380 (commercial), 384 (corrected), 389 (self-billed), 381 (credit note), and a handful of construction-services codes.
• Structured Skonto encoding (BR-DE-18). When a cash discount is offered, it must be expressed in a fixed structured form within the payment terms field, so that receiving software can apply the discount automatically rather than parse free text.
• Payment instrument coherence (BR-DE-23 to -25). Whichever payment means the invoice declares — credit transfer, card, direct debit — only the corresponding business group may be present.

A typical XRechnung invoice is checked against perhaps 200 rules: the EN 16931 baseline plus around 30 BR-DE-* rules plus the additional BR-CO-* and BR-CL-* checks the European standard already provides.

The Leitweg-ID

For invoices to German public administration, the buyer reference (BT-10) is not a free-text field. It must be a Leitweg-ID — a structured routing identifier issued by the receiving authority to the supplier in advance. The Leitweg-ID tells the receiving portal which department, agency, or sub-unit the invoice belongs to, and is the precondition for the invoice being routed through the public-sector e-invoicing portals (ZRE for federal authorities, OZG-RE for several länder, dedicated portals elsewhere).

In B2B invoicing the buyer reference is also mandatory but can be any value the parties have agreed on — typically an order number, a contract reference, or a customer-internal identifier.

The XRechnung Extension

Standard XRechnung covers the EN 16931 information set. Some real-world German invoicing scenarios — sub-line items for composite services, third-party payment splits, additional reference structures — require fields that are not part of the European baseline. The XRechnung Extension adds these as optional elements, validated by the BR-DEX-* family. An invoice using Extension fields is no longer pure EN 16931, but it remains processable by Extension-aware receiving systems.

The Extension is opt-in. Most invoices do not need it.

Validating an XRechnung

The official validator is published by KoSIT and runs the schematron against your file. It is the source of truth for "is this XRechnung-compliant", and any disagreement between a third-party validator and KoSIT should be resolved in KoSIT's favour. Our validator bundles the same schematron rules, so a green report from us corresponds to a green report from KoSIT — but the official tool is the one that matters in a dispute.

What XRechnung does not solve

The boundaries of the specification are worth being explicit about. XRechnung says nothing about:

• Transmission. How the file gets to the receiver — PEPPOL, the federal ZRE portal, email, SFTP, a customer's own upload form — is not part of XRechnung. Public-sector receivers each prescribe their own channels; B2B is a matter of agreement between the parties.
• Archival. Eight years for accounting records under §147 AO (lowered from ten by the Bürokratieentlastungsgesetz IV in 2025), with the additional GoBD requirements on integrity and auditability. How the file is stored is not XRechnung's concern.
• Signing. German law no longer requires a qualified electronic signature for ordinary B2B invoices, but specific sectors (notably parts of construction and public procurement) still impose their own requirements.
• Lifecycle. "Received", "approved", "paid", "disputed" — these are the receiver's problem, not the standard's.

For anyone evaluating an "XRechnung-capable" product, the right questions are: which versions does it support, does it validate against the bundled KoSIT schematron, does it handle both UBL and CII, and how does it integrate with the transmission channels the customers actually use.