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"
}
}
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 | D16B XSD + CEN artifacts 1.3.16 | The default for /v1/create/cii |
| XRechnung, CII binding | ...kosit:xrechnung_3.0 | EN 16931 + KoSIT Schematron 2.5.0 | 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.
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.
Invoice JSON in, EN 16931-profile CII XML out, validated before delivery.
Open toolAny dialect, detected and judged by its own rules. XML files only.
Open toolThe same invoice in the other syntax, revalidated on the way out.
Open toolWrap raw CII into a Factur-X or ZUGFeRD hybrid.
Open toolA human-readable preview of any CII file, for approvals.
Open toolReceived CII becomes BT-mapped JSON your ERP can import.
Open toolA 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.
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"]
}
]
}
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.
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.
Processed in volatile memory only. Never written to disk, never queued, never backed up.
Servers in Frankfurt, Germany. No transfers outside the European Economic Area.
Never used for analytics, never to train AI models, never shared with third parties.
SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.
GDPR compliant by design · nothing stored on our servers
The Cross Industry Invoice is UN/CEFACT's XML invoice format, and D16B is the schema release EN 16931 binds to. 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.
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.
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.
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.
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.
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.