Is XRechnung just EN 16931 for Germany?

XRechnung is a CIUS of EN 16931, a national narrowing of the European standard. Every XRechnung invoice is an EN 16931 invoice; the reverse is not true, and the gap is what gets documents rejected.

Close, but the relationship runs one way. XRechnung is a CIUS of EN 16931, maintained by KoSIT: it takes the European standard and narrows it for German use. Every valid XRechnung invoice is a valid EN 16931 invoice. A valid EN 16931 invoice is very often not a valid XRechnung one, and that gap is where German rejections come from.

EN 16931 is deliberately permissive. It has to describe invoicing across every member state, so a lot of its fields are optional and a lot of its values are open. A Core Invoice Usage Specification takes that model and tightens it: makes optional fields mandatory, restricts code lists, and adds rules of its own. It never adds new business terms outside the European model, which is what keeps a CIUS document readable by any EN 16931 processor.

XRechnung is Germany’s. Peppol BIS Billing 3.0 is the Peppol network’s. NLCIUS is the Netherlands’. They are siblings, all narrowing the same core.

The German rules carry a BR-DE-* prefix, and the ones that bite in practice are about identification and reachability rather than accounting:

• A buyer reference (BT-10) is required. For public-sector invoices this is the Leitweg-ID identifying the receiving authority, and it is not optional or inferable. A missing one fires BR-DE-15.
• The seller’s email address (BT-43) is required.
• Electronic addresses are required on both parties (BT-34 for the seller, BT-49 for the buyer), and they are fatal in KoSIT’s own Schematron, not warnings.
• At least one payment means entry must be present.
• A VAT identifier or a tax identifier must be set on the seller.

None of those is an EN 16931 requirement. An invoice that passes the European core and lacks a buyer reference is a perfectly good European invoice and a rejected German one.

EN 16931 names two XML syntaxes, UBL and CII, and XRechnung permits both. That is a real choice: a German receiving system may expect one or the other, and the same invoice content is expressible in either. Beliq emits CII by default for XRechnung, matching what most German integrations already read, and can produce the UBL binding instead. The German rules apply either way.

Both are German, both are EN 16931, and they are not interchangeable. XRechnung is XML: a structured file, no PDF. ZUGFeRD is a hybrid, a readable PDF/A-3 with CII XML embedded inside it. Which one to send depends on the receiver, not on preference. Public-sector portals expect XRechnung. Many B2B counterparties prefer a hybrid, because it arrives as something a human can also open.

Validation depth also differs. XRechnung is Authority-checked on the conformance-verified tier: KoSIT publishes a per-rule test corpus, and the ruleset Beliq runs is asserted rule by rule against it. ZUGFeRD and Factur-X are Authority-checked on the builder-round-trip tier, because their publisher releases no equivalent corpus. Same badge, different evidence behind it, and the difference is published rather than averaged away.

Paper and PDF invoices (with the recipient's consent) and non-conforming EDI stay permitted through 31 December 2027.

Last verified against the German Federal Ministry of Finance (BMF) and the European Commission eInvoicing country page, cross-checked against the June 2026 confirmation that the 2027 date is unchanged on 24 August 2026. Official source.

Alongside those dates, invoicing to German public-sector buyers has required XRechnung since the implementation of Directive 2014/55/EU, through the federal ZRE portal and the OZG-RE gateway for state and municipal authorities. Beliq builds and validates the file for either; submission to those portals runs through your own ERP or accounts-payable system.