Skip to content

UN/CEFACT Cross Industry Invoice

How a CII invoice is structured, what the D16B and D22B releases mean, why the release cannot be read from a document, and where CII genuinely differs from UBL.

What CII is

The Cross Industry Invoice is UN/CEFACT's XML invoice. It is one of the two syntaxes EN 16931 can be expressed in — the other being UBL 2.1 — and it is the syntax carried inside Factur-X and used across French e-invoicing.

Element names come from UN/CEFACT's Core Component Technical Specification, which builds each name from an object class, a property term and a representation term. The result is verbose but unambiguous: SpecifiedTradeSettlementHeaderMonetarySummation can only mean one thing.

Namespaces

  • urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 — the document root, conventionally rsm.
  • urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100 — business structures, conventionally ram.
  • urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100 — data types such as DateTimeString and Indicator, conventionally udt.
  • urn:un:unece:uncefact:data:standard:QualifiedDataType:100 — qualified data types, conventionally qdt.

As in UBL, the URIs are normative and the prefixes are not. A tool that matches the literal string ram: will fail on conformant documents.

The release question

This is the point that causes the most trouble in practice, so it is worth stating plainly: the UN/CEFACT release of a CII document cannot be determined from the document itself.

D16B, D22B and the other releases all publish the Cross Industry Invoice under the same namespace URI, …:CrossIndustryInvoice:100. There is no version element and no version attribute. The release is a property of the schema a document was built against — information about the exchange, not content of the instance.

The consequence matters for validation. Validation artefacts are release-specific: rules published for one CII release are not automatically applicable to another, and a validator that assumes a release will happily produce confident, wrong results. Any tool that tells you "this is D22B" from the file alone is guessing. This site does not, and the CII viewer says so where you would expect the answer.

What you can read from a document is what its producer claims: the guideline identifier in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID, for example urn:cen.eu:en16931:2017 or a Factur-X profile URN. That is a declaration, not a verdict.

Document skeleton

A Cross Industry Invoice has three top-level children, in this order:

  • rsm:ExchangedDocumentContext — the business process (ram:BusinessProcessSpecifiedDocumentContextParameter) and the guideline the document claims (ram:GuidelineSpecifiedDocumentContextParameter).
  • rsm:ExchangedDocument — the header: ram:ID, ram:TypeCode, ram:IssueDateTime and any ram:IncludedNote.
  • rsm:SupplyChainTradeTransaction — everything else: the lines, then the header agreement, delivery and settlement.

Inside the transaction:

  • ram:IncludedSupplyChainTradeLineItem — one per line. Each has its own agreement (prices), delivery (quantity) and settlement (tax, line total) sections.
  • ram:ApplicableHeaderTradeAgreement — buyer reference, seller and buyer parties, order and contract references.
  • ram:ApplicableHeaderTradeDelivery — ship-to party and actual delivery date.
  • ram:ApplicableHeaderTradeSettlement — currency, payment means, VAT breakdown, allowances and charges, payment terms and the monetary summation.

Note the ordering: lines come before the parties, which is the opposite of UBL.

Where CII differs from UBL

The two syntaxes express the same semantic model, but they are not the same document with different tag names. The differences that matter when writing a mapping:

  • Tax registrations. CII uses ram:SpecifiedTaxRegistration/ram:ID with a schemeID attribute — VA for VAT, FC for a local tax number. UBL nests a cac:TaxScheme element instead.
  • Dates. CII writes a string with a UN/EDIFACT 2379 format qualifier: <udt:DateTimeString format="102">20260615</udt:DateTimeString> is 15 June 2026. UBL uses ISO calendar dates directly.
  • Allowance and charge indicator. CII wraps it — ram:ChargeIndicator contains udt:Indicator. UBL has a plain boolean cbc:ChargeIndicator.
  • Due date. CII has no header-level due date; it is on ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime.
  • Currency. In CII most amounts omit currencyID and inherit ram:InvoiceCurrencyCode. EN 16931 only requires the attribute on the tax total in the accounting currency.
  • Gross price. CII has an explicit ram:GrossPriceProductTradePrice alongside ram:NetPriceProductTradePrice. UBL expresses a gross price indirectly, through a price-level allowance.
  • IBAN. CII has a dedicated ram:IBANID element. UBL uses a generic account identifier whose interpretation depends on the payment means.

A converter that treats these as cosmetic will lose or invent data. Where a field genuinely means the same thing in both syntaxes it maps cleanly; where it does not, the difference has to be preserved.

Try it

Open a document in the CII viewer to see the structure resolved, with the raw XML and the parsed model alongside. For the hybrid PDF format built on CII see Factur-X, and for the semantic model see EN 16931.

Frequently asked questions

How do I tell whether a CII file is D16B or D22B?

You cannot, from the file alone. Every release publishes the Cross Industry Invoice under the same namespace URI, …:CrossIndustryInvoice:100. The release describes which schema version the document was built against, and that is metadata about the exchange, not content of the instance. In practice you learn it from the specification you are implementing — for example Factur-X 1.0.7 and later are aligned on D22B — or by validating against a specific schema and seeing which one accepts it.

Why does CII use such long element names?

They are generated from UN/CEFACT’s Core Component Technical Specification, where a name is built from an object class, a property term and a representation term. SpecifiedTradeSettlementHeaderMonetarySummation is unambiguous by construction. It is verbose to read but it means the same thing in every UN/CEFACT document type.

What is the difference between rsm, ram, udt and qdt?

They are four namespaces. rsm holds the document-level structure of the Cross Industry Invoice. ram holds the reusable business structures — parties, lines, tax, totals. udt holds unqualified data types such as DateTimeString and Indicator. qdt holds qualified data types, used for example by FormattedIssueDateTime on referenced documents. As always the URIs are normative and the prefixes are not.

Where is the due date in a CII invoice?

There is no header-level due date. It is on the payment terms: ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime. This is a genuine structural difference from UBL, which has cbc:DueDate directly on the document.