CII Invoice API for UN/CEFACT XML
Open a ZUGFeRD hybrid, an XRechnung from a ministry, or a Factur-X from Lyon, and the XML inside is the same UN/CEFACT Cross Industry Invoice. EDI and ERP teams meet it raw, without the PDF wrapper, and this endpoint family is built for them. InvoiceXML creates standalone CII against the EN 16931 profile, validates whatever dialect arrives with its own rules, and moves invoices between CII and UBL without losing data.
curl -X POST https://api.invoicexml.com/v1/create/cii \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "invoice": { ... } }'
{
"valid": true,
"data": {
"conformanceLevel": "EN16931",
"profile": "en16931",
"customizationId": "urn:cen.eu:en16931:2017"
}
}
Every CII dialect, judged by its own law
The Cross Industry Invoice comes from UN/CEFACT, and EN 16931 adopted it as one of its two syntax bindings. The consequence: very different compliance documents share one schema. We read BT-24 and route each to the rules it claims.
| Dialect | Declared in BT-24 | What we run | Deep dive |
|---|---|---|---|
| EN 16931 core | urn:cen.eu:en16931:2017 | CII XSD + CEN artifacts | The default for /v1/create/cii |
| XRechnung, CII binding | ...kosit:xrechnung_3.0 | EN 16931 + KoSIT Schematron | XRechnung hub |
| Factur-X / ZUGFeRD ladder | factur-x.eu / zugferd.de families | Each profile's own XSD + Schematron | Factur-X hub · ZUGFeRD hub |
| Unknown dialects | An identifier we hold no rules for | EN 16931 base rules + PROFILE-DETECTION warning |
Never a false hard-fail |
data.profile. The namespace that marks a file as CII in the first place is unpacked on the CrossIndustryInvoice:100 reference page. The standard's other binding, UBL, has a hub of its own: the UBL API.
Every profile, minimum to extended
More invoice detail
- MINIMUM
- BASIC WL
- BASIC
- EN 16931
- EXTENDED
Raw XML in, anything you need out
Built for pipelines that touch the syntax directly: create it, judge it, reshape it, or read it into JSON. Free browser companions for all of it.
Create CII
Invoice JSON in, EN 16931-profile CII XML out, validated before delivery.
Open toolValidate CII
Any dialect, detected and judged by its own rules. XML files only.
Open toolConvert CII ↔ UBL
The same invoice in the other syntax, revalidated on the way out.
Open toolCII → hybrid PDF
Wrap raw CII into a Factur-X or ZUGFeRD hybrid.
Open toolRender → PDF
A human-readable preview of any CII file, for approvals.
Open toolExtract JSON
Received CII becomes BT-mapped JSON your ERP can import.
Open toolThree authorities patch this syntax. You patch nothing.
A CII document can answer to CEN (the EN 16931 artifacts), to KoSIT (the XRechnung Schematron), or to FeRD and FNFE-MPE (the Factur-X profile package). We vendor every authority's artifacts unmodified, regression-test them against the official suites (the KoSIT testsuite, FeRD samples, OpenPeppol examples), and switch on the legal effective dates, server-side. One integration, every rulebook current.
See exactly which artifacts judge CII todayXRechnung 4.0, the German CIUS of the revised EN 16931, is announced for late 2026 with no effective date yet. When it takes effect, the CII binding here flips that day.
Findings your ERP can route to a field
Schematron output is written for standards people; your AP screen is not. Every finding arrives translated: a friendly message, the layer that produced it, and three handles for three audiences.
XML only, on purpose: hybrid PDFs go to the Factur-X and ZUGFeRD validators, which extract the CII themselves.
{
"valid": false,
"data": {
"conformanceLevel": "EN16931",
"profile": "en16931",
"customizationId": "urn:cen.eu:en16931:2017"
},
"errors": [
{
"rule": "BR-CO-15",
"layer": "en16931",
"message": "The amount due for payment must
equal the total with VAT minus prepaid
amounts plus rounding. Check the due
amount.",
"btCodes": ["BT-115", "BT-112", "BT-113", "BT-114"],
"fields": ["totals.duePayableAmount",
"totals.grandTotalAmount",
"totals.paidAmount",
"totals.roundingAmount"]
}
]
}
Validation errors in German, French and English
Ask for German, French or English and every finding comes back as a plain-language explanation of what is wrong and how to fix it, ready to show in your app as it is. Each finding also carries its rule id, Business Term code and field path, so you can highlight the form field that caused it.
-
One field, three languages
Send validationLanguage with the upload, or options.validationLanguage with a create call: German, French or English. Validate, create, embed, convert and transform all speak it, with no translation layer to build or maintain on your side.
-
Every rule explained, not just translated
Every EN 16931 business rule, the XRechnung and Peppol BIS rules and the French BR-FR rules each have their own reviewed message, written for the people who fix invoices rather than for Schematron authors. No rule codes in the text, just what to change.
-
A PDF report in the same language
The printable report follows the same setting: verdict, field names, dates and every finding, in the language your reader works in.
The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL.
{ "rule": "BR-CO-09", "btCodes": ["BT-31"], "fields": ["seller.vatIdentifier"], "message": "The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL." }
rule, btCodes and fields stay the same in every language
The PDF report, as your reader gets it
POST /v1/validate/…/report
One finding, three languages
The same finding as each language returns it.
The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL.
Die USt-IdNr. des Verkäufers muss mit dem Code des ausstellenden Landes beginnen, z. B. DE123456789. Griechenland verwendet EL.
Le numéro de TVA du vendeur doit commencer par le code du pays qui l'a attribué, par exemple DE123456789. La Grèce utilise EL.
Where this syntax does the heavy lifting
CII rarely gets the headline; it gets the payload. Wherever hybrids and German portals operate, the bytes that matter are Cross Industry Invoice.
Public-sector acceptance of EN 16931 invoices traces back to Directive 2014/55/EU. Format by format, country by country: the Mandate Map. What the API supports per country: the European coverage page.
For the team that owns the pipeline
Secure by Architecture
Your invoices are processed in memory and returned in the same response. Zero data retention is not a policy we enforce, it is an architecture we built.
- Encrypted in transit. TLS on the request and on the response stream.
- Our own code, end to end. No subprocessor ever sees an invoice.
- Signed DPA and SLA available. For Enterprise customers, on request.
- Disknever
- Queuenever
- Backupnever
Zero data retention
Processed in volatile memory only. Never written to disk, never queued, never backed up.
EU-only processing
Servers in Frankfurt, Germany. No transfers outside the European Economic Area.
No use of your data
Never used for analytics, never to train AI models, never shared with third parties.
Certified infrastructure
SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.
Compliance Overview
Formats, validation and data protection on four pages. Ready to forward to your procurement, legal or IT team.
GDPR compliant by design · nothing stored on our servers
The questions integrators bring us
What exactly is CII?
The Cross Industry Invoice is UN/CEFACT's XML invoice format, and EN 16931 binds to one fixed release of its schema. It is the second of the standard's two syntaxes (UBL is the other) and the payload inside Factur-X, ZUGFeRD, and XRechnung's CII binding.
Which CII dialects can you validate?
Plain EN 16931 documents, the full Factur-X and ZUGFeRD profile ladder, and XRechnung-declared invoices, each routed to its own rule set based on BT-24. Identifiers we hold no rules for validate against the EN 16931 core with a PROFILE-DETECTION warning.
Can I send a hybrid PDF to /v1/validate/cii?
No, and that is deliberate: this endpoint takes XML files only. Hybrid PDFs belong on the Factur-X and ZUGFeRD validators, which extract the embedded CII automatically. If you already pulled the XML out yourself, it is welcome here.
Is CII to UBL conversion lossless?
Both syntaxes bind the same EN 16931 semantic model, so conversion maps at the business-term level rather than tag by tag, and the output is revalidated before it leaves. The data set EN 16931 defines survives the trip in both directions.
Should I use CII or UBL?
Usually your counterparty decides. German and French ecosystems lean CII (XRechnung's CII binding, ZUGFeRD, Factur-X), while the Peppol network runs on UBL. Both are first-class here, and converting between them is one call. The other binding has its own hub.
What does JSON extraction return?
BT-mapped JSON mirroring the EN 16931 business terms: the same model you would post to the create endpoints. Received CII goes in, ERP-ready structure comes out, with no XPath archaeology on your side.