CII Sample Files: Free EN 16931 Cross Industry Invoice XML

CII is the UN/CEFACT Cross Industry Invoice: one of the two XML syntaxes EN 16931 permits, and the one underneath Factur-X, ZUGFeRD and the CII binding of XRechnung. These files are that XML on its own, with no PDF wrapper and no national rule set on top, which makes them the cleanest thing to develop a CII parser against.

Because plain CII adds nothing to the European core, there is no ladder of profiles here and no syntax choice. What actually differs between real CII documents is the document type and the VAT treatment, so that is what the set varies.

cii-samples.zip Every file on this page, in one archive 9 KB

The set

cii-en16931.xml Standard commercial invoice, 19% VAT, allowance and charge at document and line level 10 KB cii-credit-note.xml The same message with BT-3 set to 381, and a reference to the invoice it corrects 6 KB cii-reverse-charge.xml Cross-border B2B services, VAT category AE at zero rate with its exemption reason 10 KB

All three carry the same three-line services invoice from a German seller to a French buyer, so you can diff them against each other and see only the difference that matters.

A credit note is not a different message

In CII a credit note is the same rsm:CrossIndustryInvoice root you already parse, with one field changed:

<ram:TypeCode>381</ram:TypeCode>

Worth stating plainly because UBL does the exact opposite: there a credit note is a separate CreditNote document with its own root element and namespace. Code ported between the two syntaxes gets this wrong in both directions, either looking for a root element that never changes or switching on a type code that never moves. The UBL sample set has the other half of the comparison.

Zero VAT needs a reason, and only sometimes a manual one

The reverse-charge file is the common cross-border case: two VAT-registered businesses in different member states, the supplier charges nothing and the buyer accounts for the tax. The VAT breakdown carries category AE at a zero rate, plus the justification the rules demand in BT-120 and BT-121.

Which the API filled in by itself. Categories AE, K, G and O each map to exactly one canonical VATEX reason, so there is nothing to guess and nothing for you to supply. Category E, plain exemption, is the exception: it stands in for dozens of different national provisions, so guessing a reason is wrong more often than right and the field is left to you. That asymmetry is the whole subject of the first invalid fixture below.

Files that are wrong on purpose

cii-invalid-br-e-10.xml Exempt invoice with no exemption reason, so BR-E-10 fires and nothing else 10 KB cii-invalid-no-lines.xml Header totals with the invoice lines removed. Fails three rules at once, on purpose 6 KB

The first is a clean single-rule failure: category E, arithmetic all consistent, no BT-120 or BT-121. Only BR-E-10 fires. If your validator passes it, it is not running the VAT category rules.

The second is deliberately not single-rule, and that is what makes it useful. EN 16931's totals are anchored on line evidence, so deleting the lines does not fail one rule, it fails three: BR-16 for the missing lines, then BR-CO-10 and BR-S-08 because the sum of line net amounts and the VAT breakdown now claim figures nothing supports. One edit, three findings. If you are building error reporting, a cascade like this is a better test of your grouping and de-duplication than any single-rule file.

How these files were generated

One call, no options at all, since plain CII has nothing to configure:

curl -X POST https://api.invoicexml.com/v1/create/cii \
  -H "Authorization: Bearer $INVOICEXML_API_KEY" \
  -H "Content-Type: application/json" \
  -d @invoice.json \
  --output cii-en16931.xml

The credit note is the same call with the type code set to 381 in the invoice body, and the reverse-charge file is the same call with the VAT category set to AE on the lines. Every file is validated against the D16B schema and the EN 16931 CII rules before publishing, which is how we know the valid ones hold up and each broken one breaks exactly where this page says.

The invalid fixtures had to be produced by bypassing our own pipeline, because refusing to emit them is precisely its job. To check a file of your own, the CII validator takes an upload directly. If you need this XML inside a readable PDF instead, that is Factur-X.

Why sample files go stale

These were generated on 6 August 2026, against the EN 16931 CII rules 1.3.16 and the UN/CEFACT D16B schema.

Plain CII is the most stable target in this family: the CEN rule set updates roughly twice a year and the underlying UN/CEFACT schema moves slowly. That is genuinely less maintenance than the national profiles carry. What it does not mean is no maintenance, because the moment your invoices go to an actual country you inherit that country's rule set and its release calendar on top of this one, and most integrations that start on plain CII end up there.

On the InvoiceXML API the current artefacts are what runs, for the core and for every profile above it, with no SDK to upgrade and no redeploy when a rule set moves. Start with the free trial, or read how the CII API fits the rest of the family.

Frequently asked questions

Are these CII sample files free to use?

Yes. They are our own output rather than a copy of any specification package, so there are no licence terms attached. Use them in test suites, CI fixtures, demos or documentation. The parties, identifiers and amounts are fictional.

What is the difference between CII and Factur-X?

Factur-X is CII inside a PDF. The XML is the same UN/CEFACT Cross Industry Invoice; Factur-X adds a PDF/A-3 container, a profile declared in BT-24, and a restricted schema per profile. If you only need the structured data, plain CII is what you want. If you need a document a person can also read, that is the hybrid.

Is a CII credit note a different message?

No, and this is the main thing to know. A credit note is the same CrossIndustryInvoice message with BT-3 set to 381. Only the type code changes. UBL does the opposite: there a credit note is a separate CreditNote document with its own root element, so code ported between the two syntaxes gets this wrong in both directions.

Why does the reverse-charge invoice carry an exemption reason I did not set?

Because category AE maps to exactly one canonical VATEX reason, so the API fills BT-120 and BT-121 for you. Category E is different: exempt stands in for dozens of national provisions, so nothing is guessed and you have to supply the reason yourself. The invalid fixture on this page is what happens when you do not.

Which schema are these validated against?

The generic UN/CEFACT D16B schema plus the EN 16931 CII Schematron. That is deliberately looser than the hybrid scope: a Factur-X document is checked against its profile's restricted schema, where a misplaced element is a hard error, while standalone CII keeps the CEN artefacts' own behaviour and surfaces those as CII-SR findings.