Automation MCP Server Features Blog Pricing Contact
Identifier reference XRechnung CIUS

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

The CustomizationID of XRechnung 3.0, the German CIUS of EN 16931. Two spellings of it circulate, one on the xeinkauf.de domain and one on the older xoev-de pattern, and knowing why saves a lot of head-scratching in front of validation reports.

What this identifier declares

This string is the CustomizationID (BT-24) of XRechnung 3.0, the German Core Invoice Usage Specification maintained by KoSIT. Split at the # marks, it reads: the document follows the EN 16931 core model, stays compliant with it (a strict subset, no data beyond the core), and applies the XRechnung 3.0 overlay: the German business rules (BR-DE), including the famous mandatory buyer reference (BT-10) carrying the Leitweg-ID that routes an invoice to the right public-sector office, plus German requirements on payment details and contact fields.

Public-sector receivers in Germany expect exactly this declaration. It is what separates an XRechnung from a generic EN 16931 invoice with German addresses in it.

One identifier, two spellings

Searches for this page arrive via two different strings, and both are real:

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0

The first is the identifier the XRechnung 3.0 specification defines. The second carries the naming pattern of versions 1.2 through 2.3, which lived on the xoev-de domain (urn:xoev-de:kosit:standard:xrechnung_2.3 and so on), applied to 3.0. When KoSIT moved XRechnung under the xeinkauf.de procurement umbrella, the identifier moved with the 3.0 release, but the old pattern lingers in libraries and templates that only bumped the version number. Receivers and validators differ in how forgiving they are, so emit the xeinkauf.de form and treat the other as legacy input.

Where it appears in the XML

XRechnung inherits both EN 16931 syntax bindings. In UBL, the identifier is the cbc:CustomizationID directly under the root:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>

In CII, the same value sits in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID inside rsm:ExchangedDocumentContext.

What validators derive from it

The declaration routes the document to the KoSIT rulebook: syntax XSD, the EN 16931 core rules, and the German BR-DE rules on top, in the version the identifier names. The InvoiceXML XRechnung validator recognises both spellings, applies the current KoSIT rule set, and returns findings with their rule IDs and layers, so "core problem" and "German overlay problem" are distinguishable at a glance.

Common problems around this identifier

  • Version drift. Declaring xrechnung_2.3 (or older) after the 3.0 switchover of February 2024 is the most frequent intake failure in German B2G integrations.
  • The wrong spelling for a strict receiver. Platforms that match the string exactly may not accept the xoev-de variant for 3.0 documents.
  • Declared but not delivered. The identifier promises the BR-DE rules pass; a missing or malformed Leitweg-ID in BT-10 is the classic way that promise breaks.

Working with XRechnung documents

To check a file you received or produced, the XRechnung validator runs the full KoSIT rule set in the browser or over the API. To generate compliant documents, the create endpoint stamps the current CustomizationID and validates against the current rules before delivery; when KoSIT publishes the next release, the switch happens server-side on the effective date, with no change to your integration. The XRechnung hub covers the German landscape, and the XRechnung API toolkit is the full integration walkthrough.

Frequently asked questions

Which of the two XRechnung 3.0 identifiers should I emit?

The xeinkauf.de form, urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. It is the identifier the XRechnung 3.0 specification defines. The urn:xoev-de:kosit:standard:xrechnung_3.0 variant carries the pre-3.0 naming pattern over to 3.0 and still appears in tooling, so be liberal when reading, but strict when writing.

Why did the identifier's domain change from xoev-de to xeinkauf.de?

KoSIT, the German coordination office for IT standards that maintains XRechnung, moved the standard under the xeinkauf.de umbrella, the federal portal for public procurement. With XRechnung 3.0 the identifier followed: the xoev-de:kosit:standard prefix of versions 1.2 through 2.3 became xeinkauf.de:kosit.

Is xrechnung_2.3 still a valid identifier?

XRechnung 2.3 was superseded by 3.0 in February 2024, and public-sector receivers validate against the current version. Documents still declaring a 2.x identifier fail intake at strict platforms. Regenerating with the current CustomizationID (and content that passes the current KoSIT rules) is the fix.

Does XRechnung exist in CII as well as UBL?

Yes. XRechnung is a CIUS of EN 16931 and inherits both syntax bindings: UBL (invoice and credit note) and UN/CEFACT CII. The CustomizationID is the same string in both; only its XML location differs. Most German B2G traffic is UBL, but CII XRechnung is fully legitimate.