A CII invoice in detail¶
The previous page used a deliberately small invoice to show the
shape. This page does for CII what
A UBL invoice in detail does for UBL: it walks a full,
real example top to bottom — and, by a happy accident of the standards work, it is
the very same business case. The official CEN example is invoice TOSL108,
with the same five items (a laptop, two returns, a book, network cable) and the
same 1436.5 line total as the OASIS UBL example. Reading the two detail pages
together is the clearest possible way to feel the difference between the syntaxes.
Source
The document is CII_business_example_01.xml from the CEN
eInvoicing-EN16931
test corpus (EUPL-1.2). Unlike the raw OASIS UBL example, this one is
EN16931-valid — it carries the specification identifier, uses the disciplined
code lists, and its totals reconcile exactly (we check at the
end). The currency is NOK and the rates are 25 % / 15 %,
so the amounts differ from the UBL example even though the items match.
The overall shape¶
A CII invoice is the three-part spine: context, document header, then the transaction — and inside the transaction, the lines come first, followed by the three "Applicable…Trade…" blocks.
flowchart TD
C["ExchangedDocumentContext — which rulebook"] --> H["ExchangedDocument — number, type, date"]
H --> T["SupplyChainTradeTransaction"]
T --> L["IncludedSupplyChainTradeLineItem ×5 — the items, first"]
L --> AG["ApplicableHeaderTradeAgreement — parties, references"]
AG --> DL["ApplicableHeaderTradeDelivery — ship-to, delivery date"]
DL --> ST["ApplicableHeaderTradeSettlement — currency, tax, totals, payment"]This is almost the mirror image of UBL's order: UBL puts parties and totals before the lines; CII puts the lines first and the parties, tax and totals after. Keep the name-decoding rules handy — every block below is built from the same qualifier vocabulary.
Context and header¶
- BT-24, the specification identifier —
urn:cen.eu:en16931:2017. This is the difference from the raw UBL example, which omitted it and so failed BR-01 on the spot. Here it is present, so the document announces which rulebook it follows. - BT-1, invoice number —
TOSL108, the same number as the UBL example. - BT-3, type code —
380, commercial invoice (UNCL1001). - BT-2, issue date —
20130630read throughformat="102"(CCYYMMDD) = 2013-06-30. Recall CII carries the date as a coded string, not ISO text. - A free-text note — CII wraps notes in
IncludedNote/Content, where UBL used a flatcbc:Note.
The lines come first¶
In CII the items lead. Line 1 is the fully-loaded specimen; the other four reuse its vocabulary with less decoration. Note how the line repeats the document's three-part spine — it has its own Agreement, Delivery and Settlement.
LineID— the line number (1), insideAssociatedDocumentLineDocument— the line's "header about itself", which also carries the line note.SpecifiedTradeProduct— what is sold, the equivalent of UBL'scac:Item.GlobalID/SellerAssignedID— a global product id (schemeID="0088"is GS1/GTIN) and the seller's own code. UBL split these intoStandardItemIdentificationandSellersItemIdentification.ApplicableProductCharacteristic— a name/value property ("Color: Black"), UBL'sAdditionalItemProperty.DesignatedProductClassification— a taxonomy code (listID="STI"), UBL'sCommodityClassification.BuyerOrderReferencedDocument/LineID— links the line back to a purchase-order line, like UBL'sOrderLineReference.- Gross price → applied allowance. CII models the price build-up explicitly:
a
GrossPriceProductTradePriceof 1498 with anAppliedTradeAllowanceChargeof 225 (ChargeIndicatorfalse = an allowance)… - …→ Net price. …yielding the
NetPriceProductTradePriceof 1273 (1498 − 225). UBL expressed the same discount with aMultiplierFactorNumeric; CII just states both prices. BilledQuantitywithunitCode="NAR"(number of articles). Line net = net price × qty = 1273 × 1.- Line-level
ApplicableTradeTax— the VAT category and rate for this line (S, 25 %), but no amount here; the cash VAT is summed at header level. - Two line-level allowance/charges that cancel — a 12 allowance ("Damage") and
a 12 charge ("Testing"). Note the CII shape:
ChargeIndicatoris wrapped inudt:Indicator, not a bare boolean as in UBL. LineTotalAmount(BT-131) — 1273. The line's own MonetarySummation.ReceivableSpecifiedTradeAccountingAccount— a buyer booking code per line.
ChargeIndicator is wrapped, and decides everything
Just like UBL, CII uses one element — SpecifiedTradeAllowanceCharge — for
both discounts and surcharges, and the boolean inside ChargeIndicator is the
only thing that tells them apart (true = charge, false = allowance). The CII
twist is the extra udt:Indicator wrapper:
<ram:ChargeIndicator><udt:Indicator>true</udt:Indicator></ram:ChargeIndicator>.
The other four lines, in brief — the same five items as the UBL example:
| Line | Item | Qty | Net amount | VAT cat |
|---|---|---|---|---|
| 1 | Laptop computer | 1 | 1273.00 | S (25 %) |
| 2 | Returned "Advanced computing" book | −1 | −3.96 | S (15 %) |
| 3 | "Computing for dummies" book | 2 | 4.96 | S (15 %) |
| 4 | Returned IBM 5150 desktop | −1 | −25.00 | E (exempt) |
| 5 | Network cable | 250 (MTR) | 187.50 | S (25 %) |
Negative lines are credits in place
Lines 2 and 4 carry a negative BilledQuantity and LineTotalAmount — returns
folded into the invoice. As in UBL, the arithmetic simply goes negative and flows
into the totals.
ApplicableHeaderTradeAgreement — parties and references¶
After the lines comes the first header block: who, and on what paperwork.
Seller — the full party anatomy¶
GlobalID(schemeID="0088"= GLN) — the party's global identifier, the rough equivalent of UBL'sEndpointID/PartyIdentification.SpecifiedLegalOrganization/ID— the legal registration number; CII's answer to UBL'sPartyLegalEntity.DefinedTradeContact— contact person, phone, email, all wrapped in CII's…UniversalCommunicationelements.PostalTradeAddress— structured address; the country is an ISO code inCountryID, not free text.SpecifiedTaxRegistrationwithschemeID="VA"— the VAT number. UBL put this inPartyTaxScheme.
One shape, reused everywhere
…TradeParty is one reusable structure — seller, buyer, ship-to, payee and tax
representative all draw from it. Learn it once here; the rest read instantly.
This is exactly the role cac:Party plays in UBL.
Buyer and a third role — the tax representative¶
The buyer (ram:BuyerTradeParty) has the identical structure with different data.
Then a third party appears — and it is a different role than UBL's example chose:
SellerTaxRepresentativeTradeParty— a fiscal representative who handles VAT on the seller's behalf (common when a seller is registered for VAT abroad). It is the same "roles are modelled separately" idea as UBL'sPayeeParty— different role, same principle. (This invoice also carries a payee, in the settlement block below.)
Then the document references — order, contract, and an attachment carried by value:
- By reference — a
URIIDpointing at a hosted file. - By value — the file itself, Base64 in
AttachmentBinaryObject, withmimeCodeandfilename. The same two attachment modes UBL offered, under different names.
ApplicableHeaderTradeDelivery — where the goods went¶
ShipToTradeParty— the delivery location, separate from the buyer's billing identity (UBL'sDelivery/DeliveryLocation).ActualDeliverySupplyChainEvent— when delivery happened (2013-06-15). Note the "SupplyChainEvent" naming: a delivery is one event in the supply-chain the vocabulary models.
ApplicableHeaderTradeSettlement — money¶
The richest block: currency, payee, payment means, the VAT breakdown, document-level allowances/charges, terms, and the grand totals.
- BT-5, currency —
NOK. PayeeTradeParty— the party to be paid when it differs from the seller (here "Ebeneser Scrooge AS") — the direct equivalent of UBL'sPayeeParty.SpecifiedTradeSettlementPaymentMeans— how to pay.TypeCode30(UNCL4461) = credit transfer; IBAN underPayeePartyCreditorFinancialAccount, BIC under the creditor financial institution.
The VAT breakdown — one group per category¶
- Category
Sat 25 % — a taxableBasisAmountof 1460.5 →CalculatedAmount365.13. This is the header VAT total per category — the cash amounts the lines deliberately omitted. - Category
E(exempt) carries anExemptionReason— exempt lines must say why. A grammar cannot enforce that; Schematron does.
| Category | Rate | Taxable base | VAT |
|---|---|---|---|
| Standard | S |
1460.5 | 365.13 |
| Standard | S |
1.0 | 0.15 |
| Exempt | E |
−25.0 | 0.00 |
| Total | 1436.5 | 365.28 |
Document-level allowances, terms, and the totals¶
- Document-level allowance/charge — a 100 allowance ("Promotion discount") and a
100 charge ("Freight"); same wrapped
ChargeIndicatoras the line level. CategoryTradeTax— crucially, each document allowance/charge names the VAT category it belongs to (S, 25 %), so it folds into the right tax base. The allowance and charge here are both standard-rate and cancel, which is why the tax base equals the line total.DueDateDateTime— the payment deadline (2013-07-20), with the human terms inDescription.- The grand totals block (BG-22) — every amount a distinct concept, exactly
paralleling UBL's
LegalMonetaryTotal:
| CII element | Means | Value |
|---|---|---|
LineTotalAmount |
Σ line nets (BT-106) | 1436.5 |
AllowanceTotalAmount / ChargeTotalAmount |
doc-level sums | 100 / 100 |
TaxBasisTotalAmount |
net VAT is calculated on | 1436.5 |
TaxTotalAmount |
total VAT | 365.28 |
GrandTotalAmount |
net + VAT | 1801.78 |
TotalPrepaidAmount |
already paid | 1000 |
DuePayableAmount |
the bottom line | 801.78 |
It all reconciles¶
As with the UBL example, the numbers are consistent top to bottom — and these cross-totals are exactly what the EN16931 Schematron checks.
Lines sum to the document line total (BR-CO-10):
1273.00 + (−3.96) + 4.96 + (−25.00) + 187.50 = 1436.5
= …HeaderMonetarySummation/LineTotalAmount ✓
Each VAT category's base is the sum of its lines (the doc allowance/charge cancel):
| Category | Lines | Σ line net | = BasisAmount |
|---|---|---|---|
| S (25 %) | 1, 5 | 1273 + 187.5 | 1460.5 ✓ |
| S (15 %) | 2, 3 | −3.96 + 4.96 | 1.0 ✓ |
| E (0 %) | 4 | −25 | −25.0 ✓ |
And the chain to the bottom line:
Grand = TaxBasis 1436.5 + VAT 365.28 = 1801.78 Due = Grand 1801.78 − Prepaid 1000 = 801.78 ✓
How it compares to the UBL example¶
Same business case, two syntaxes — the differences are instructive:
| OASIS UBL example | This CEN CII example | |
|---|---|---|
| EN16931-valid? | No — no CustomizationID (fails BR-01) |
Yes — carries the spec identifier |
| Order of content | parties & totals, then lines | lines first, then parties & totals |
| Leaf vs container | cbc vs cac namespace |
encoded in the name, all ram: |
| Price discount | MultiplierFactorNumeric on the price |
explicit gross → net price pair |
ChargeIndicator |
bare boolean | wrapped in udt:Indicator |
| Third party shown | PayeeParty |
SellerTaxRepresentativeTradeParty (+ a payee) |
| Date format | ISO text 2013-06-30 |
coded 20130630 + format="102" |
Neither is "better" — and a receiver must accept both. That is the whole reason EN16931 keeps its rules syntax-neutral, binding one abstract rulebook to UBL and to CII alike.
Where next¶
You have now walked complete invoices in both EN16931 syntaxes. To see what enforces the consistency you just verified by hand, go to The validation pipeline; for the lists behind every coded field, Genericode code lists; and for any unfamiliar term, the Glossary.