← Back to all articles

XRechnung 3.0: what changed and how to comply

SealDoc Team · · 6 min read

XRechnung 3.0 became the required version for German government invoice submissions in November 2023. It tightened the field requirements compared to version 2.x and added validation rules that reject invoices previously accepted without issue. If you invoice German federal or state government bodies and have not updated your invoice generation since 2023, you may be generating non-compliant documents without knowing it.

Here is a plain-language guide to what XRechnung is, what changed in version 3.0, and how to bring your invoicing into compliance.

What XRechnung is

XRechnung is a German government specification for electronic invoicing, built on top of the European standard EN 16931. It is the mandatory format for invoices addressed to German public sector buyers: federal ministries, agencies, and (depending on the state) state and municipal bodies.

Unlike Factur-X or ZUGFeRD, which are hybrid formats (PDF with embedded XML), XRechnung is pure XML. There is no visual PDF wrapper. The document is machine-readable only, and recipients process it directly in their ERP or public procurement systems. Human-readable visualisations are generated by the receiving system on demand.

XRechnung uses both CII (Cross Industry Invoice) and UBL (Universal Business Language) XML serialisations. Version 3.0 covers both. The two carry identical invoice data; the format choice depends on what the receiving system expects. Most German federal portals accept either.

The central submission portal for the German federal government is ZRE (Zentraler Rechnungseingang des Bundes). Many states operate their own portals (OZG-RE), and a growing number accept Peppol delivery as an alternative.

Who must comply

Mandatory for:

  • All suppliers issuing invoices to German federal government bodies (Bundesbehörden), required since 27 November 2020
  • Suppliers to German state bodies where the state has adopted the mandate (varies by Bundesland; most have by now)
  • Suppliers to German municipal bodies where the municipality has activated the mandate
  • Subcontractors where the prime contractor passes on the obligation contractually

Not currently mandatory for:

  • Private-sector B2B invoicing in Germany (though this is changing: the German B2B mandate, phased from 2025 to 2028, allows Factur-X/ZUGFeRD and XRechnung as compliant formats)
  • Invoices below the threshold set by individual contracting authorities (some set minimums for structured submission; most do not)

If you are unsure whether a specific buyer requires XRechnung, check the contracting notice or purchase order. Government buyers are required to specify the accepted invoice format in procurement documents.

What changed in version 3.0

XRechnung 3.0 was published by the Koordinierungsstelle für IT-Standards (KoSIT) and became mandatory on 1 August 2023 for new submissions, with full enforcement from 1 November 2023. The key changes:

BG-6 SellerContact is now mandatory

In XRechnung 2.x, the seller contact information (BG-6) was optional. In 3.0, at least one of the following sub-fields must be present:

  • BT-41 SellerContactPoint (contact name or department)
  • BT-42 SellerContactTelephoneNumber
  • BT-43 SellerContactEmailAddress

In practice, most implementations include all three. If your invoice generation does not populate BG-6 at all, your invoices will fail the XRechnung 3.0 schematron validation.

BT-10 Buyer Reference (Leitweg-ID) handling tightened

The Leitweg-ID is a routing identifier used by German government systems to direct invoices to the correct internal cost centre or department within a public authority. In XRechnung 2.x it was present but its validation was permissive.

In version 3.0, the Leitweg-ID must be in the correct format (numeric segments separated by hyphens, with a check digit) and must match a value provided by the contracting authority. If the Leitweg-ID is missing or malformed, the invoice is rejected at the portal.

Your buyer will provide the Leitweg-ID in the purchase order or contract. Always carry it through verbatim into BT-10.

BT-23 Business Process Type now validated

BT-23 identifies the business process context. In 3.0, the value must come from an approved code list. The standard value for most B2G invoices is urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, but specific portals may require a different value. Check the portal documentation for your target buyer.

IBAN required when payment means is credit transfer

If BT-81 (PaymentMeansCode) is 58 (credit transfer), then BT-84 (PaymentAccountIdentifier) must contain a valid IBAN in version 3.0. In earlier versions, an account number in any format was accepted. Free-text bank references are no longer sufficient.

Stricter schematron rules overall

Beyond the specific field changes, version 3.0 tightened the schematron validation rules. Invoices that passed 2.x validation with warnings may now fail outright. Common causes:

  • Missing or empty currency code on line items when the document currency is already declared
  • Incorrect calculation of line amounts (sum of line amounts must match the header total within rounding tolerance)
  • TaxCategory codes that do not match the accepted EN 16931 code list
  • Dates in incorrect format (ISO 8601 is required: YYYY-MM-DD)

Validation tools

Before submitting any XRechnung invoice, validate it. Two tools are widely used:

Validator.KoSIT.de is the official German government validator. It runs the full XRechnung 3.0 schematron suite and reports rule-by-rule pass/fail. It is free and accepts CII and UBL formats.

SealDoc Validator accepts XRechnung 3.0 CII XML files and returns a structured report covering EN 16931 schema validity, XRechnung 3.0 schematron rules, and a plain-English list of errors. Use our Validator tool if you want a human-readable report alongside the technical validation result.

Both validators are non-destructive: you submit the file, they return a report, nothing is stored.

How SealDoc generates XRechnung 3.0

SealDoc’s invoice generation API includes the XRechnungDe profile, which targets XRechnung 3.0 CII. When you use this profile:

  • BG-6 SellerContact is required in the API input (the API will reject the request with a clear error if it is missing, so you find out at generation time, not at portal submission time)
  • BT-10 Leitweg-ID is validated for format correctness before generation
  • BT-23 is set to the correct default value, overridable if your buyer requires a specific value
  • IBAN is required when payment method is credit transfer
  • All schematron rules from the 3.0 specification are enforced before the file is returned

The output passes the official KoSIT validator without warnings. We run the KoSIT validation suite as part of our own CI pipeline on every profile update, so you can rely on the output being current.

If you are migrating from an older invoice generation system, the fastest validation path is: generate a sample invoice with your current system, run it through the Validator tool, fix the reported errors in your data model, then re-test. The most common error we see in XRechnung 2.x-era invoices is the missing SellerContact, followed by malformed Leitweg-ID values.

The archival question

XRechnung invoices are pure XML, which is machine-readable but not human-readable in a document viewer. For your own archival copy, consider generating a Factur-X PDF/A-3 alongside the XRechnung XML. The Factur-X copy gives you a human-readable archive that satisfies German GoBD requirements for long-term document retention, while the XRechnung file satisfies the government submission requirement.

SealDoc can generate both from the same invoice data in a single API call.

Validate your XRechnung invoices now

If you generate invoices for German government buyers and have not updated your system since 2022 or early 2023, run a sample through our Validator tool. You will know within seconds whether you are generating valid XRechnung 3.0 or whether there are fields that need attention before your next invoice cycle.


← Back to all articles