Automation MCP Server Features Blog Pricing Contact
Identifier reference CII syntax

urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100

The XML namespace of the rsm:CrossIndustryInvoice root element. Unlike the other identifiers on these pages, this one is not a profile declaration: it names the UN/CEFACT CII vocabulary itself, the syntax underneath Factur-X, ZUGFeRD, and CII-flavoured XRechnung.

What this identifier declares

urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 is the XML namespace of the root element of a UN/CEFACT Cross Industry Invoice (CII). If you pulled this string out of a file, you learned two things: the document is a CII invoice, and its structure is governed by the UN/CEFACT schema module version 100, the one distributed as CrossIndustryInvoice_100pD16B.xsd in the D16B schema library that EN 16931 pinned for European e-invoicing.

What it does not tell you is which profile the invoice follows. The namespace is the same in a Factur-X MINIMUM hybrid, a ZUGFeRD EXTENDED invoice, and a CII-syntax XRechnung; the profile is declared separately, inside the document (more on that below). This division of labour is the single most useful thing to know about the string.

Where it appears in the XML

On the root element, as the namespace bound to the rsm prefix, alongside the two module namespaces every CII document also binds:

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

The prefixes rsm, ram, and udt are conventional, not required; namespace-aware tooling matches the URIs, not the prefixes. A document using different prefixes is just as valid, and a parser comparing prefix strings instead of namespaces is a bug waiting to be found.

What validators derive from it

The namespace is the first fork in the road: seeing it, a validator selects the CII branch and the D16B XSDs (CrossIndustryInvoice_100pD16B.xsd and the modules it imports) for structural validation. It then reads BT-24 from ram:GuidelineSpecifiedDocumentContextParameter/ram:ID to choose the business-rule set: EN 16931 core, a Factur-X profile, or the KoSIT rules for XRechnung. The InvoiceXML CII validator walks exactly this chain and reports both what it detected and every rule finding with its XPath context.

Common problems around this identifier

  • Expecting the namespace to version along with the profile. Factur-X releases, ZUGFeRD releases, and XRechnung versions come and go; this namespace does not move with them. Code that switches on the namespace to detect a format version is looking in the wrong place.
  • Prefix assumptions. Matching rsm: as a literal string breaks on perfectly valid documents. Match the namespace URI.
  • Mixed or misspelled module namespaces. The ram and udt URIs must be the matching :100 module versions; a document mixing directories fails schema validation with errors that look far more mysterious than the cause.

Working with CII documents

To check any CII file against the D16B schema and the rule set its BT-24 declares, use the CII validator in the browser or over the API. To produce CII, the create endpoint turns plain invoice JSON into schema-valid, rule-checked XML with the right namespaces and profile declaration stamped in. For received files, /v1/extract/json reads CII (standalone or embedded in a hybrid PDF) into BT-mapped JSON. The CII hub covers the syntax as a format, and the CII technical overview goes deeper into its structure and history.

Frequently asked questions

What does the :100 at the end mean?

It is the version of the UN/CEFACT schema module for the CrossIndustryInvoice message, not a profile or a Factur-X version. The 100 has been stable across the D16B-based schemas European e-invoicing uses, which is why the namespace looks identical in every Factur-X, ZUGFeRD, and CII XRechnung file you open.

What is CrossIndustryInvoice_100pD16B.xsd?

The XSD schema file that defines this namespace, from UN/CEFACT's D16B library (the 2016B release of their standardised schema directory). EN 16931 pinned its CII binding to D16B, so that file, plus the ram/udt/qdt modules it imports, is what CII invoices are structurally validated against.

Is this namespace the same for Factur-X, ZUGFeRD, and XRechnung in CII?

Yes, byte for byte. All of them are CII documents, so they share the root element and its namespace. What differs is the profile declared inside the document, in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID (BT-24), and consequently which rule set applies on top of the shared schema.

Where is the profile of a CII invoice actually declared?

Not in the namespace. The profile lives in BT-24, the ram:ID under rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter, holding values like urn:factur-x.eu:1p0:minimum or urn:cen.eu:en16931:2017. The namespace only says: this is a CII invoice.