What CII is and where it comes from
CII stands for Cross Industry Invoice. It is developed by UN/CEFACT, the United Nations Centre for Trade Facilitation and Electronic Business, the same body responsible for a wider family of trade and supply-chain standards (including EDIFACT, the long-established EDI standard). This lineage matters, because it shapes how CII looks and thinks.
Where UBL grew out of a document-library tradition, an OASIS effort to model business documents as XML, CII comes from a trade-facilitation tradition focused on the flow of a commercial transaction between parties. It is built on UN/CEFACT's Core Component methodology, a rigorous approach to defining reusable data building blocks. The version referenced by the European standard EN 16931 is CII D16B. CII is the primary syntax in the Franco-German invoicing world and, as discussed below, it is the XML that lives inside Factur-X and ZUGFeRD.
A transaction-oriented structure, not a document-oriented one
The most important thing to understand about CII, and the sharpest contrast with UBL, is that it is organised around the structure of a trade transaction rather than the layout of a document.
A UBL invoice is arranged the way a person reads an invoice: header details, then the parties, then the lines, then the totals. CII is arranged the way a trade actually happens, in three phases. After a small context and document header, the body of a CII invoice, the SupplyChainTradeTransaction, is divided into three header-level groups that model the lifecycle of the deal.
The first is the Agreement (ApplicableHeaderTradeAgreement): who the seller and buyer are, and the references that frame the deal, such as the order or contract. The second is the Delivery (ApplicableHeaderTradeDelivery): what was delivered, to where, and when. The third is the Settlement (ApplicableHeaderTradeSettlement): how the transaction is paid and taxed, containing the payment means, the tax breakdown, the currency, and the monetary totals. The invoice lines each repeat a similar agreement/delivery/settlement logic at the line level.
This agreement-delivery-settlement spine is the signature of CII. It reflects the mindset of its origin: an invoice is not primarily a document to be displayed, it is the record of a commercial transaction with a defined lifecycle. Once you recognise those three header groups, any CII invoice becomes navigable, and the difference in philosophy from UBL becomes concrete rather than abstract.
The namespaces and the data-type split
CII documents use a set of namespaces that reflect the Core Component methodology, commonly abbreviated rsm, ram, udt, and qdt.
rsm is the message-level namespace, wrapping the whole CrossIndustryInvoice and its top-level sections. ram is the reusable aggregate namespace, holding the composite business structures, the parties, the trade agreement, the settlement, and so on. Then, distinctively, CII separates its data types into two further namespaces: udt for unqualified data types (the primitive building blocks such as amounts, identifiers, and dates) and qdt for qualified data types (those primitives constrained to specific code lists).
That explicit separation of data types is a visible fingerprint of the Core Component methodology CII is built on. It is more abstract than UBL's simpler basic-versus-aggregate split, and it is one reason CII is often described as more rigorous but less immediately readable than UBL. Where UBL optimises for human legibility with long descriptive element names, CII optimises for methodological consistency, which makes it more compact in places but harder to read at a glance.
CII declares which specification it follows through a context parameter near the top of the document (the guideline identifier inside the document context, ram:GuidelineSpecifiedDocumentContextParameter), which serves the same role as UBL's CustomizationID: it tells a receiver which rule set to apply. The mechanism differs, the purpose is identical.
Because this is the CII syntax used inside Factur-X and ZUGFeRD, the guideline identifier is also where the profile is declared. The five Factur-X profiles each have their own URN:
MINIMUM urn:factur-x.eu:1p0:minimum
BASIC WL urn:factur-x.eu:1p0:basicwl
BASIC urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic
EN 16931 urn:cen.eu:en16931:2017
EXTENDED urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extendedThe EN 16931 (COMFORT) profile is the plain urn:cen.eu:en16931:2017, which is also the identifier a receiver looks for to confirm full EN 16931 compliance. Only the BASIC, EN 16931, and EXTENDED profiles are fully EN 16931 compliant; MINIMUM and BASIC WL carry less than the standard requires and are not accepted as compliant e-invoices on their own.
CII inside Factur-X and ZUGFeRD
For many organisations, the most common encounter with CII is not as a standalone XML file but as the data embedded inside a Factur-X or ZUGFeRD invoice. Those hybrid formats consist of a human-readable PDF with a structured XML invoice attached inside it, and that embedded XML is CII. So even teams that think of themselves as working with "ZUGFeRD" or "Factur-X" are, at the data level, working with CII.
This is worth making explicit because it explains CII's reach. The Franco-German hybrid formats are among the most widely deployed e-invoicing formats in Europe, and they are CII underneath. Understanding CII is therefore not a niche concern, it is the data model behind a very large share of European invoicing, even when the format is known by another name.
Why two syntaxes exist, and which to use
The obvious question is why European e-invoicing ended up with two XML syntaxes expressing the same standard. The answer is partly historical and partly practical.
Both UBL and CII existed, with substantial installed bases, before EN 16931 was written. UBL had strong adoption in the OASIS and Nordic-influenced ecosystem that became the Peppol world. CII had strong adoption in the UN/CEFACT and Franco-German ecosystem. When the European standard was created to harmonise the semantic content of an invoice, forcing everyone onto a single syntax would have meant asking half the market to abandon significant existing investment. Instead, EN 16931 was defined at the semantic level and bound to both syntaxes. A compliant invoice can be expressed in either, and both carry exactly the same business information.
In practice, which syntax you use is usually dictated by the target rather than by preference. Invoices sent over the Peppol network use UBL. Invoices in Factur-X and ZUGFeRD use CII, embedded in the PDF. The German XRechnung specification accepts either UBL or CII. So the decision is generally made for you by the recipient, the network, or the format you are required to produce, not chosen freely. The useful mental model is: Peppol means UBL, the Franco-German hybrids mean CII, and XRechnung leaves the choice open.
Validation, briefly
Validating a CII invoice follows the same two-layer principle as any EN 16931 document, and the same principle covered for UBL: structural schema validation confirms the XML is well-formed CII, and then Schematron validation applies the EN 16931 business rules (and any national rules) to check that the invoice is logically correct. The rules are the same rules, EN 16931 defines them once at the semantic level, but they are expressed for the CII binding. As with UBL, passing structural validation does not mean passing the business rules, and the business-rule layer is where most rejections occur. The official Schematron for these rules requires XSLT 2.0 processing, the same technical consideration that applies across the standard.
Converting between CII and UBL
Because UBL and CII express the same EN 16931 semantic model, an invoice can in principle be converted from one syntax to the other without loss of meaning. Each business term has a defined location in both syntaxes, so a value in a UBL element has a corresponding home in the CII structure and vice versa.
This matters in the real world because the two syntaxes belong to different ecosystems that increasingly have to interoperate. A supplier producing ZUGFeRD (CII) may need to reach a customer who can only accept Peppol (UBL), or a system holding UBL may need to emit CII for a Franco-German recipient. Reliable conversion between the two is what bridges the Peppol world and the Franco-German world. It is a genuinely useful operation precisely because the two-syntax situation is not going away.
Where a service fits in
Producing and validating CII, whether as a standalone file or as the payload inside Factur-X and ZUGFeRD, and converting between CII and UBL where two ecosystems meet, is the kind of work that can be delegated rather than built and maintained in house.
InvoiceXML generates valid CII, validates it against EN 16931 and any applicable national rules, and converts losslessly between CII and UBL in both directions, so that bridging the Franco-German and Peppol worlds is a single operation rather than a mapping project. It can be reached through a REST API for direct integration, through no-code automation platforms, or through an MCP interface for AI-driven and agentic workflows. Because the standard and its rule sets are maintained on the service's side, revisions arrive without you re-integrating validation artefacts.
Building it in house remains a legitimate choice for teams with the capacity to maintain it. The aim of this overview is to make the format and its place in the landscape clear: CII is the UN/CEFACT syntax, organised around the agreement-delivery-settlement lifecycle of a trade, expressing the same EN 16931 model as UBL, sitting inside Factur-X and ZUGFeRD, and chosen not by preference but by where the invoice is going. Understood alongside UBL, it completes the picture of how the same standard travels in two different shapes.