XRechnung
Germany's CIUS of EN 16931 for public-sector and increasingly B2B e-invoicing. What Beliq emits, validates, and where the submission boundary lies.
XRechnung is the German Core Invoice Usage Specification (CIUS) of EN 16931, maintained by KoSIT (Coordination Office for IT Standards) under mandate from the IT Planning Council on behalf of the Federal Ministry of the Interior and Bremen. It implements EU Directive 2014/55/EU for invoicing to German public-sector buyers (B2G) and is also widely required by large B2B buyers in Germany.
The XRechnung 3.0 line has been in force since 2024-02-01, and the patch level Beliq validates against is XRechnung 3.0.2, from the KoSIT Schematron pack pinned at 2.6.0. The two move independently: the spec version is what a document declares in its CustomizationID, the pack version is what judged it, and GET /v1/rulesets publishes both as specVersion and rulesetVersion. KoSIT’s release timing is not fixed, and a bugfix bundle is valid the day it is published; see the XRechnung release cycle note on the validation-artifacts page for what that means for upgrade timing.
KoSIT’s 2026-08-31 bundle (Schematron 2.6.0 plus a new validator configuration) is vendored, pinned and in force: announced on 2026-09-05 as a breaking ruleset bump, it took effect without a notice period, so latest resolves to it now. The outgoing pack and severity table stay pinnable as xrechnung_schematron:2.5.0 and xrechnung_severity_overrides:2026-01-31 until 2027-06-11. A pin of either one also runs the other at the version of the same KoSIT bundle, and pins of the two from different bundles return 422. The previous channel no longer reaches them: KoSIT dates the 2026-08-31 bundle valid from 2026-08-31, so a request on previous resolves latest and sets rulesetFellBack: true (why). A document you send today is judged under 2.6.0, so if you need the earlier verdict, pin it. What changes afterwards, rule by rule, is in ruleset versioning and the changelog.
What Beliq emits
When you call POST /v1/generate with standard: "xrechnung", Beliq writes an XRechnung XML document in UN/CEFACT CII D16B. XRechnung permits both EN 16931-defined syntaxes (per EN 16931-2), UBL 2.1 and CII D16B, but the generate request has no field that picks one. For XRechnung in UBL, generate the CII and send it to POST /v1/convert with sourceFormat=cii&targetFormat=xrechnung.
| Element | Beliq behaviour |
|---|---|
ram:GuidelineSpecifiedDocumentContextParameter (BT-24) |
The XRechnung URN. |
| Syntax | CII D16B. No request field changes it; convert writes the UBL binding. |
ram:BuyerReference (BT-10) |
Required; supply via invoice.buyerReference. For B2G this is the Leitweg-ID identifying the receiving authority. |
| Seller email (BT-43) | Required; supply via invoice.seller.email. |
| Electronic addresses (BT-34 seller, BT-49 buyer) | Required on both parties, and fatal in KoSIT’s own Schematron (PEPPOL-EN16931-R020 / R010). Beliq resolves each party from peppol, then email as EAS EM, then vatId + a supported address.countryCode, and returns 400 VALIDATION_ERROR, with a message naming the party, when none of the three resolves. |
| Payment means | At least one paymentMeans entry must be present. |
| VAT identifier | Either seller.vatId (BT-31) or seller.taxId must be set. |
The full request schema (parties, lines, totals, etc.) is on POST /v1/generate, and a worked German curl example is in the Germany guide.
German-specific rules
XRechnung adds DE-prefixed business rules on top of EN 16931 core rules (BR-*). The most common to watch for are documented in the Germany guide: Common validation errors section. Rule IDs follow the BR-DE-* convention; the full Schematron is published at itplr-kosit/xrechnung-schematron.
Validation pipeline
Every invoice generated with standard: "xrechnung" is validated before the response is returned, and uploaded XML can be re-validated via POST /v1/validate. The pipeline is:
- XSD: UBL 2.1 or CII D16B structural correctness.
- EN 16931 Schematron: the cross-syntax core rules.
- XRechnung Schematron (KoSIT): DE-specific overlay; matched by
CustomizationID.
The pinned versions Beliq runs are published on the validation artifacts page (single source of truth; this page does not duplicate them).
Submission channels
Beliq generates and validates XRechnung XML. Today it does not submit to the German government portals; submission goes through your ERP / AP system to:
- ZRE (Zentraler Rechnungseingang): federal agencies.
- OZG-RE: state and municipal authorities, via the Online Access Act gateway.
Channel operation belongs to your transmission partner. Managed delivery is in build, and it covers the Peppol Network rather than the ZRE and OZG-RE portals.
Related
- Germany guide: country-side specifics, BR-DE-* rules, ZUGFeRD comparison
- Format reference overview: where XRechnung sits among EU formats
- Validation artifacts: current Schematron versions and update policy
- KoSIT XRechnung: official specification
- KoSIT: xrechnung-schematron (GitHub)
- EN 16931