UBL vs CII: the two XML syntaxes of EN 16931

EN 16931 defines a semantic data model for invoices and endorses two XML syntaxes for representing it on the wire: UBL 2.1 (Universal Business Language) and UN/CEFACT CII (Cross Industry Invoice). Both express the same business information; both are valid; both are checked by the same business rules. The choice between them is, with very few exceptions, not a technical choice but an ecosystem choice.

This page explains where each comes from, where each dominates today, and what the visible differences look like for someone who has to read or produce them.

A common misconception

The first thing to understand is what the two formats do not differ on. They do not encode different invoices. They do not carry different information. They do not produce different validation outcomes for the same business content. The EN 16931 schematron exists in two parallel implementations — one for UBL, one for CII — and the two implementations enforce the same rules over the same semantic model. A correctly produced UBL invoice and a correctly produced CII invoice describing the same transaction will pass the same checks and will be processed identically by any compliant downstream system.

The two formats are not "compatible" in the sense that one can be silently converted into the other — they have different element names, different nesting rules, different attribute conventions — but they are equivalent in the sense that any well-formed invoice in one can be losslessly transformed into a well-formed invoice in the other, given a correct mapping.

Where each one comes from

UBL (Universal Business Language) is maintained by OASIS, an open standards consortium. It originated in the early 2000s as a general-purpose XML vocabulary for business documents — invoices, orders, despatch advices, catalogues, and so on. Its design philosophy is element-rich and self-descriptive: most data live in named elements rather than attributes, and the element names themselves carry meaning (cbc:InvoicedQuantity, cac:AccountingSupplierParty, cbc:PayableAmount).

CII (Cross Industry Invoice) is part of the UN/CEFACT trade facilitation work. It descends from the UN/EDIFACT tradition — a much older effort at structured business documents — and was reformulated as XML in the 2010s. Its design carries more EDIFACT influence: deep structural nesting, terser element naming, more reliance on type codes and attributes. Element names like ram:SpecifiedTradeProduct and ram:ApplicableHeaderTradeAgreement are typical.

Both predate EN 16931 by years. When CEN was looking for XML syntaxes to endorse for its new standard in 2015–2017, both UBL and CII were established and had implementer constituencies. Endorsing both was the only diplomatically viable outcome.

Visible differences for a reader

The same semantic content looks quite different in the two formats:

UBL is more verbose at the outer structure but flatter in nesting. An invoice line typically lives directly inside the invoice element, with the line number, item name, quantity, and price as straightforward children.

CII is more compact in element names but deeper in nesting. The same invoice line is wrapped in ram:IncludedSupplyChainTradeLineItem, then ram:SpecifiedLineTradeAgreement, ram:SpecifiedLineTradeDelivery, and ram:SpecifiedLineTradeSettlement, each carrying a slice of the line's attributes. The structure mirrors the EDIFACT segment-and-group logic underneath.

For a developer with no prior exposure, UBL is generally easier to read: the element names announce what they contain, and the nesting matches intuition. CII rewards a reader who already knows the underlying semantic model — once the mapping is in your head, the deep structure makes sense — but it is opaque on first encounter.

Where each dominates

The geographical split is reasonably clean:

UBL territory — Denmark, Norway, the Netherlands, Belgium, Sweden, Iceland, much of the public sector across the Nordics, and the entire PEPPOL network. PEPPOL BIS Billing 3.0 is UBL-only, and PEPPOL is the de facto e-invoicing backbone for cross-border European invoicing.

CII territory — Germany (XRechnung supports both but industry favours CII), France (national format and Factur-X embedded XML are CII-based), Switzerland.

XRechnung accepts both syntaxes equally. PEPPOL accepts only UBL. French B2B accepts both at the format level, with Factur-X being CII-only by construction. In practice, this means an organisation invoicing across European borders will end up producing both, even if internal preference is for one.

Tooling

Tooling for both formats is mature. The major XML libraries (lxml, Xerces, .NET XmlReader, and so on) handle both equally. Schematron validators run the same EN 16931 rules against both. Code generators exist for producing UBL and CII from XSD definitions in any major language. There is no meaningful tooling gap.

The one area where tooling diverges is in the validation reports themselves: schematron reports cite the rule ID, but the path to the failing element is naturally different between the two formats. A "Buyer city is missing" failure points at cac:BuyerCustomerParty/cac:Party/cac:PostalAddress/cbc:CityName in UBL and at ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CityName in CII. Tools that surface validation errors usefully need to know which syntax they are looking at.

The verdict

There is no general technical reason to prefer one syntax over the other. The decision in practice is dictated by where the invoice is going:

• Sending to a PEPPOL endpoint? Use UBL.
• Sending to a German receiver who requested XRechnung CII? Use CII.
• Issuing Factur-X? You are using CII, embedded in a PDF.
• Building a system that will produce both? Build the semantic model first, generate UBL and CII as outputs from the same source. Do not try to convert between the two as your primary path; the mappings exist but they are tedious to maintain and tend to silently lose information at the edges.

The historical irony is that EN 16931 was meant to end format fragmentation in European invoicing, and instead — by endorsing two syntaxes — it preserved one of its most visible symptoms. The wager was that a stable semantic model would make the syntactic split irrelevant in the long run. Whether that wager is paying off depends on whose tooling one is using.