XRechnung: the standard behind German e-invoicing

Formally, XRechnung is the German Core Invoice Usage Specification (CIUS) of the European norm EN 16931: it takes the norm’s semantic data model, the Business Terms from invoice number through line items to VAT breakdown, and pins down how they are used for invoices to and between German parties. The standard is operated by KoSIT, the Koordinierungsstelle für IT-Standards, on behalf of the IT-Planungsrat, the federal-state body that coordinates public-sector IT. Version 3.0.2 is current as of September 2026, a maintenance release of the 3.0 line.

An XRechnung invoice is a single XML file in one of the two syntaxes the European norm mandates: UBL 2.1 or UN/CEFACT CII. Senders choose the syntax; a compliant receiver must accept both. There is deliberately no human-readable layer, no embedded PDF, no styling: the invoice is the data record, and anything a person sees is produced by a viewer. That design makes XRechnung the cleanest format for fully automated processing, and the least convenient one for a colleague who just wants to glance at an invoice.

XRechnung also defines an Extension concept for cases the core profile cannot carry, adding elements or code-list values beyond EN 16931-1 for specific German requirements. For most businesses the core profile is all they will ever see; the point to remember is that "XRechnung" names a specification with versions and rules, not a product.

The hard obligation sits in B2G. Since November 27, 2020, suppliers to federal authorities must invoice electronically under the E-Rechnungsverordnung, and XRechnung is the reference format for doing so. Federal invoices are submitted through the ZRE and OZG-RE portals or over the Peppol network, and the German states run their own, closely related regimes for state and municipal customers.

Addressing is the part that trips up first-time suppliers: every public-sector customer is identified by a Leitweg-ID, a routing identifier you must carry in the invoice as the buyer reference. The Leitweg-ID comes from the customer, typically in the contract documents, and an invoice without the correct one is rejected before any human sees it. When submitting over Peppol, the receiver address is the same Leitweg-ID with the scheme prefix 0204 in front.

In domestic B2B, XRechnung is not prescribed, but it is one of the formats that satisfy the e-invoicing mandate of § 14 UStG, since it conforms to EN 16931 by construction. High-volume, system-to-system invoicing relationships tend to prefer it precisely because there is no PDF layer to tempt anyone into manual handling.

Almost nobody writes XRechnung XML by hand. The realistic paths are the ones the creating-e-invoices guide walks through in detail: the export function of your invoicing or ERP software, a dedicated e-invoicing tool, manual capture in the federal portals for low volumes, or a Peppol Access Point for scale. What matters when configuring any of them is the version and the buyer reference: exports should target the current XRechnung version, and public-sector invoices must carry the customer’s Leitweg-ID.

Compliance is mechanically testable, and you should test it before your customers do. KoSIT provides validation tooling for the standard, and the BMF letter of October 15, 2025 gives the error taxonomy: Formatfehler make the file no e-invoice at all, Geschäftsregelfehler violate the norm’s arithmetic and consistency rules, Inhaltsfehler are formally valid but factually wrong. A validation step in the outbound pipeline catches the first two classes automatically.

Since January 1, 2025, any German supplier can send you an XRechnung without asking, and the file that arrives is XML with no picture attached. Opening it in a text editor is technically possible and practically useless for accounting. A receiving process needs three capabilities: parse both syntaxes, validate against the norm, and map the Business Terms into whatever structure your ERP or accounting system books from.

That mapping is exactly what Talonic’s invoice processing does, for XRechnung and for everything else in the same inbox: the free Peppol e-invoice extractor shows the field model on a real file in the browser, and the production pipeline resolves XRechnung, ZUGFeRD, Peppol invoices, PDFs, and scans into one schema-validated output with confidence and provenance per field, processed on EU infrastructure in Germany.

Reading about formats is one thing; an accounts-payable inbox full of them is another. Two free resources and one production path:

• Peppol e-Invoice Extractor: pull the seller, buyer, line items, VAT breakdown, and totals out of an e-invoice, free in the browser
• Peppol e-invoice extraction guide: the EN 16931 field model (Business Terms) explained field by field
• Invoice parsing with schema validation: process XRechnung, ZUGFeRD, Peppol invoices, PDFs, and paper scans into one validated output schema, with confidence and provenance on every value