The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) publishes this eXtensible Markup Language (XML) syntax so a supplier can send a structured Electronic Invoice (E-Invoice) that software can post without retyping a paper bill. Enterprise Resource Planning (ERP) and Accounts Payable (AP) systems read the parties, the tax, and the totals from named elements. One schema covers every billing function in the family. A type code on the header, not a second document, tells the receiver whether the file is a commercial invoice, a credit note, or another function from the same code list.
CII belongs to the cross-industry family of supply-chain messages in the Supply Chain Reference Data Model. UN/CEFACT designed the invoice as a maximum data set covering many commodities and sectors, so a given use keeps only the elements it needs. The European syntax binding names release D16B, schema version 100, dated 10 October 2016. That release is published twice: once with code lists coupled into the schemas, and once with the lists decoupled. The European Committee for Standardization (CEN) technical specification CEN/TS 16931-3-3 advises the decoupled set, so a later code-list correction does not force every trading partner to replace the schema.
How the D16B Schemas Are Assembled
The root element is CrossIndustryInvoice, in the namespace urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. A normal instance uses four prefixes. The prefix rsm marks the message. The prefix ram marks reusable aggregate business information entities. The prefix udt marks unqualified data types. The prefix qdt marks qualified data types, including currency codes and the document type code.
- Context. ExchangedDocumentContext carries processing parameters. GuidelineSpecifiedDocumentContextParameter holds the identifier of the profile the file claims, such as an EN 16931 profile or a Factur-X profile.
- Header. ExchangedDocument carries the invoice number in ID, the billing function in TypeCode, and the issue date in IssueDateTime. The date is a DateTimeString whose format attribute is 102, so the value is the eight-digit calendar date CCYYMMDD. The CEN binding allows only that format code.
- Transaction. SupplyChainTradeTransaction holds the line items first, then the header agreement, delivery, and settlement groups, in that order. An optional ValuationBreakdownStatement may follow the transaction. Core European invoices commonly omit it.
Each IncludedSupplyChainTradeLineItem repeats the commercial pattern at line level. AssociatedDocumentLineDocument carries the line identifier. SpecifiedTradeProduct names the goods or service. SpecifiedLineTradeAgreement, SpecifiedLineTradeDelivery, and SpecifiedLineTradeSettlement hold the line price, the billed quantity, and the line tax and amounts.
InvoiceCurrencyCode sits on the header settlement block and uses the alphabetic currency code from International Standards Organization (ISO) 4217. The binding places that code at document level.
- Agreement. ApplicableHeaderTradeAgreement names SellerTradeParty and BuyerTradeParty. It can also carry the buyer reference, the buyer order, the contract, and other referenced documents.
- Delivery. ApplicableHeaderTradeDelivery names the ship-to and ship-from parties and the despatch, delivery, and receipt events the invoice needs.
- Settlement. ApplicableHeaderTradeSettlement holds the currency, repeating ApplicableTradeTax entries for Value-Added Tax (VAT), payment means, and SpecifiedTradeSettlementHeaderMonetarySummation. That summation includes GrandTotalAmount and DuePayableAmount. PayableSpecifiedTradeAccountingAccount and ReceivableSpecifiedTradeAccountingAccount can carry a payable ledger reference and an Accounts Receivable (AR) reference when those accounts must travel with the invoice.
One Type Code, Not a Second Document
The Organization for the Advancement of Structured Information Standards (OASIS) publishes Universal Business Language (UBL) as separate business documents. UBL 2.1, also issued as ISO/IEC 19845, uses an Invoice document for a commercial invoice and a CreditNote document for a credit note. CII does not split the schema. The root stays CrossIndustryInvoice, and TypeCode on ExchangedDocument selects the function. Code 380 is the commercial invoice. Code 381 is the credit note. The same UN/CEFACT document name list includes 384 for a corrected invoice and 389 for a self-billed invoice issued by the buyer. Receiving software has to read the code. The root element will not tell it which function arrived.
EN 16931-1 is the semantic model of the business terms in a European core invoice. CEN/TS 16931-3-2 binds those terms to the UBL invoice and credit note. CEN/TS 16931-3-3 binds the same terms to CII D16B, including the invoice number to ExchangedDocument/ID and the type code to TypeCode. Directive 2014/55/EU requires contracting authorities in its scope to receive and process an invoice that follows the semantic model and uses either of those two syntaxes.
CII is an XML document of named business entities, not a classic Electronic Data Interchange (EDI) transaction. It is also not the usual Pan-European Public Procurement On-Line (Peppol) invoice. Peppol Billing 3.0 is specified only in UBL. The German XRechnung specification accepts the EN 16931 model in either syntax, and from version 3.0 it applies the Peppol billing rules that still make sense outside the Peppol network to CII as well as to UBL. A CII file that satisfies XRechnung is still not a Peppol Billing 3.0 document.
For an implementer, the two syntaxes line up as follows.
| Aspect | CII D16B | UBL 2.1 |
| Root element | CrossIndustryInvoice for every billing function | Invoice or CreditNote, as separate documents |
| How the function is chosen | TypeCode on ExchangedDocument, such as 380 or 381 | Choice of document, then InvoiceTypeCode or CreditNoteTypeCode |
| Invoice number | ID inside ExchangedDocument | ID on the document root |
| Issue date | DateTimeString with format 102, written CCYYMMDD | IssueDate as a calendar date, written YYYY-MM-DD |
| Seller and buyer | SellerTradeParty and BuyerTradeParty under ApplicableHeaderTradeAgreement | AccountingSupplierParty and AccountingCustomerParty |
| Tax and totals | ApplicableTradeTax and SpecifiedTradeSettlementHeaderMonetarySummation | TaxTotal and LegalMonetaryTotal on the document |
| European syntax binding | CEN/TS 16931-3-3 | CEN/TS 16931-3-2 |
| Where a file usually travels | Factur-X, ZUGFeRD, or XRechnung XML | Peppol Billing 3.0 or XRechnung XML |
Factur-X and ZUGFeRD Hybrid Files
Factur-X and ZUGFeRD carry the same hybrid design. A person reads a Portable Document Format (PDF) rendering, and software reads a CII attachment embedded in that file. The container is PDF/A-3, defined in ISO 19005-3, which allows an embedded file of another format. Factur-X requires the attachment to be named factur-x.xml. The visible pages and the XML are two representations of one invoice, and the amounts are expected to match.
ZUGFeRD 2.0, published in March 2019, aligned the German hybrid invoice with EN 16931 and with Factur-X. From that generation the XML root is CrossIndustryInvoice. ZUGFeRD 1.0 used a different root, CrossIndustryDocument, and it is not this schema.
How much structured data is present depends on the profile named by the guideline identifier in ExchangedDocumentContext. The Factur-X series defines five profiles, each one a subset of the message rather than a new document type.
- MINIMUM. Document identifiers, the parties, the currency, and the amount due. It has no invoice lines and no full tax breakdown, so it is not a complete EN 16931 core invoice.
- BASIC WL. Header and settlement data, including the tax breakdown and payment information, without invoice lines. WL means without lines. It is still a subset of the European core.
- BASIC. Adds invoice lines for a simple bill. It does not cover every business term in EN 16931.
- EN 16931. The full European core and its business rules. ZUGFeRD previously called this profile COMFORT. On Factur-X the guideline identifier is urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931.
- EXTENDED. Includes the European core and adds supply-chain fields beyond it, such as richer delivery and commercial references. France defines a domestic reporting subset of this profile for its reporting mandate.
The Factur-X 1.07 specification describes those profiles as subsets of the D22B implementation of EN 16931. The syntax that European public buyers are required to accept remains the D16B binding in CEN/TS 16931-3-3. In France and Germany the hybrid file is the common Business-to-Business (B2B) carrier for this syntax. A pure XML file, with no PDF wrapper, remains a valid CII invoice for XRechnung and for cross-border exchange under EN 16931.
