Automation MCP Server Features Blog Pricing Contact
Identifier reference EN 16931 core

urn:cen.eu:en16931:2017

The stem of European e-invoicing. On its own, this string declares a plain EN 16931 core invoice; with a #compliant# or #conformant# suffix it anchors nearly every national and network profile in Europe. Reading it correctly tells you exactly which rulebook a document expects.

What this identifier declares

urn:cen.eu:en16931:2017 is the specification identifier (BT-24) of the European core invoice model, EN 16931-1:2017, published by CEN. A document declaring exactly this string, with no suffix, claims to be a plain core invoice: it carries the EN 16931 business terms, satisfies the core business rules, and applies no national or network specialisation on top. This is, for example, the identifier the Factur-X EN 16931 profile writes into its XML, and a common choice for German domestic B2B invoices under the 2025 mandate.

The identifier grammar: stem, compliant, conformant

The string matters well beyond the bare form, because it is the stem of a small grammar that organises the whole European landscape:

urn:cen.eu:en16931:2017
urn:cen.eu:en16931:2017#compliant#<CIUS identifier>
urn:cen.eu:en16931:2017#conformant#<extension identifier>

#compliant# announces a CIUS: a specification that narrows the core without contradicting it, so the document remains a valid EN 16931 invoice. Peppol BIS Billing 3.0, XRechnung, Dutch NLCIUS, and Factur-X BASIC all hang off this stem with #compliant#. #conformant# announces an extension that may carry data beyond the core, as Factur-X EXTENDED does. When you meet an unfamiliar identifier, split it at the # marks: stem, relationship, specialisation. That decomposition is usually the entire answer.

Where it appears in the XML

BT-24 has one home per syntax. In UBL it is an element directly under the root:

<cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>

In CII (the syntax inside Factur-X and ZUGFeRD hybrids, and one of XRechnung's two bindings) it sits in the document context:

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

What validators derive from it

BT-24 is the routing key for validation. The declared identifier selects the rule set; for the bare stem that means the syntax XSD plus the CEN core Schematron, and nothing else. The UBL, CII, and Factur-X validators all read it first, report the applied rule set in data.profile, and echo the declared string back in data.customizationId so mismatches are visible at a glance.

Common problems around this identifier

  • Bare core where an overlay is expected. The classic rejection: a structurally perfect core invoice bounced by a Peppol access point or a German public-sector receiver because the market requires its CIUS identifier, not the stem alone.
  • Treating the suffix as decoration. The part after #compliant# changes which rules run. Two documents identical except for BT-24 can validate differently, and both results are correct.
  • Near-miss strings. The identifier is matched exactly: a stray space, wrong case, or an invented year (en16931:2018 appears in the wild) makes it unknown to strict receivers.

Working with EN 16931 documents

To generate core-compliant invoices, the UBL and CII create endpoints accept plain invoice JSON, stamp the correct BT-24 for the requested profile, and run the full core rule set before delivery, with the CEN artifacts maintained server-side. To check documents you receive, the matching validators name every violated rule. For background on the standard itself, read EN 16931 explained.

Frequently asked questions

What is the difference between #compliant# and #conformant#?

#compliant# introduces a CIUS: a specification that restricts the core without stepping outside it, so the document is still a valid EN 16931 invoice (Peppol BIS, XRechnung, NLCIUS, Factur-X BASIC). #conformant# introduces an extension: consistent with the core but allowed to carry data beyond it (Factur-X EXTENDED). The separator word is a receiver's first hint of what to expect.

Is plain urn:cen.eu:en16931:2017 enough for Peppol or German B2G?

No. Networks and public-sector mandates expect their own overlay: Peppol access points look for the BIS Billing 3.0 CustomizationID, German public-sector receivers for the XRechnung identifier. The bare core identifier is correct for exchanges that agreed on the plain core, such as German domestic B2B under the 2025 mandate.

Which rules does a validator run for this identifier?

The CEN core artifacts: the syntax XSD (UBL 2.1 or CII D16B) plus the EN 16931 Schematron, more than 200 business rules covering required fields, totals arithmetic, VAT category logic, code lists, and decimal precision. No national overlay applies, because none is declared.

Is the identifier the same in UBL and CII?

Yes, the value is identical; only its address differs. UBL carries it in cbc:CustomizationID, CII in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. Both are the semantic field BT-24, the specification identifier.