How do I recognise a CII file?

By the root element rsm:CrossIndustryInvoice and the prefixes rsm, ram and udt. UBL by contrast starts with ubl:Invoice and uses cbc and cac.

Is CII harder to process than UBL?

To read, yes, because it nests more deeply and a field can sit four levels below the root. For a parser the difference is meaningless — both map the same BT numbers.

Why do ZUGFeRD and Factur-X use CII specifically?

History. Both grew out of the UN/CEFACT world long before EN 16931 put the two syntaxes on an equal footing. The choice is hard-wired there: there is no ZUGFeRD with UBL inside.

Can I convert CII to UBL?

Yes, as long as both documents implement the EN 16931 core — then they map the same fields. Once extension fields are involved that the core does not know, the conversion stops being lossless.

CII (Cross Industry Invoice): structure and use of the UN/CEFACT syntax

Origin and role

CII comes from UN/CEFACT, the United Nations body for trade facilitation and electronic business — the same organisation that produced EDIFACT. The syntax is therefore older than EN 16931 and was adopted by the standard, not invented for it.

In the European format landscape CII occupies a clear position: wherever a hybrid format is involved, the embedded invoice is a CII file. ZUGFeRD and Factur-X know no alternative.

The structure

CII splits an invoice document into two large blocks, and the second one splits again into three:

text

1rsm:CrossIndustryInvoice
2├── rsm:ExchangedDocumentContext     context: which rule set applies (BT-24)
3├── rsm:ExchangedDocument            header: number, date, type, notes
4└── rsm:SupplyChainTradeTransaction
5    ├── ram:IncludedSupplyChainTradeLineItem   the lines
6    ├── ram:ApplicableHeaderTradeAgreement     seller, buyer, order reference
7    ├── ram:ApplicableHeaderTradeDelivery      delivery, service date
8    └── ram:ApplicableHeaderTradeSettlement    currency, tax, totals, payment

That three-way split — agreement, delivery, settlement — is the most visible difference from UBL, which lays its groups out flatter side by side. It follows the logic of a trade: what was agreed, what was delivered, what is being settled.

The namespaces

Three prefixes come up constantly:

Prefix	Meaning
`rsm`	the document structure itself
`ram`	the reusable business objects (most fields)
`udt`	simple data types, e.g. amounts with a currency attribute

One field in its place

The seller's VAT identification number (BT-31) sits here in CII:

xml

1<ram:ApplicableHeaderTradeAgreement>
2  <ram:SellerTradeParty>
3    <ram:Name>Muster GmbH</ram:Name>
4    <ram:SpecifiedTaxRegistration>
5      <ram:ID schemeID="VA">DE811128135</ram:ID>
6    </ram:SpecifiedTaxRegistration>
7  </ram:SellerTradeParty>
8</ram:ApplicableHeaderTradeAgreement>

Note the schemeID="VA" attribute: CII does not distinguish tax number and VAT identifier by using different elements but by a code on the same element. VA means the VAT identifier, FC the tax number.

🔴 This is a classic source of error: writing both numbers into the same element without setting the code produces a document in which the recipient mistakes the tax number for a VAT identifier.

Amounts carry their currency

A second trait you notice while generating: monetary amounts in CII are not bare — they carry the currency as an attribute, at least where the standard requires it.

xml

1<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
2  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
3  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
4  <ram:TaxTotalAmount currencyID="EUR">190.00</ram:TaxTotalAmount>
5  <ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
6</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

That TaxTotalAmount of all things needs the currency attribute while the other totals do not looks arbitrary, and it is one of the rules home-grown generators regularly trip over.

When you meet CII

When generating, whenever the target format is ZUGFeRD or Factur-X — there you have no choice. With XRechnung you do, and practice there mostly picks UBL.

When receiving, always. The moment a supplier sends a ZUGFeRD file, CII is on the table, regardless of which syntax you generate yourself.

💡 The advice that follows is the same as for UBL: treat syntax as a transport detail. Internally you work with the standard's BT fields; CII and UBL exist only at the outer boundary. Then a format change costs configuration rather than a rebuild.