Automation MCP Server Features Blog Pricing Contact
POST /v1/validate/cii

CII Validation REST API

Validate any UN/CEFACT Cross Industry Invoice D16B document against the official CII XSD schema and the EN 16931 CEN Schematron, the syntax-level foundation that underpins both ZUGFeRD and Factur-X. Structured JSON, returned in under two seconds.

Built for standalone CII from ERP-to-ERP and EDI exchange across manufacturing, logistics, and procurement, as well as the embedded payload of any hybrid invoice. The rule set is auto-detected from the BT-24 GuidelineSpecifiedDocumentContextParameter, from MINIMUM to EXTENDED, and every violation is reported with its rule ID, the validation layer it came from, and the XPath location.

Bash
curl -X POST https://api.invoicexml.com/v1/validate/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"
200 OK · Application/JSON
{
  "valid": true,
  "data": {
    "profile": "en16931",
    "customizationId": "urn:cen.eu:en16931:2017"
  },
  "errors": [],
  "warnings": []
}

Try it live, no API key required

This runs the same POST /v1/validate/cii endpoint your integration will call. Drop any CII XML to see the full validation response.

Drop your CII XML here

or browse files to upload

POST /v1/validate/cii · Accepted: CII XML · Max 20 MB

Submit any standalone CII D16B document, the cross-industry payload exchanged ERP-to-ERP and over EDI, or the XML extracted from a ZUGFeRD/Factur-X PDF. The API reads the BT-24 GuidelineSpecifiedDocumentContextParameter to select the rule set, the EN 16931 CEN core Schematron plus the per-profile Factur-X or ZUGFeRD artifacts (MINIMUM to EXTENDED), or the KoSIT rules for XRechnung-CII, and validates against the matching XSD and Schematron. Every violation is returned with its rule ID, the validation layer it came from, and the XPath location in the CII document tree.
Validation report

Not just pass or fail. A full CII compliance report.

A raw UN/CEFACT CII D16B document buries every value under deeply nested rsm:, ram:, and udt: elements, and most validators just hand back a Schematron dump when one rule fails. The InvoiceXML CII API returns a complete report array instead: one row for every EN 16931 Business Term it extracted from the SupplyChainTradeTransaction tree, each with its value and a pass or fail verdict. Whether the file came from an ERP export, an EDI partner, or the payload of a hybrid invoice, you get an audit-ready compliance view without writing a single CII XPath query yourself.

CII Compliance Report

invoice-cii.xml · TechParts Europe GmbH · profile EN 16931

162 terms 160 passed 2 failed
Status Business Term Field Value
BT-1 Invoice number invoiceNumber INV-2026-001
BT-5 Invoice currency currency EUR
BT-27 Seller name seller.name TechParts Europe GmbH
BT-31 Seller VAT identifier seller.vatIdentifier DE149871234
BT-30 Seller legal registration ID seller.legalRegistration.id Scheme ID is required when a registration number is present.
BT-112 Invoice total with VAT totals.grandTotalAmount 1190.00
BT-131 Line net amount, line 2 lines[1].lineNetAmount Missing. Document total cannot be reconciled.

Rendered from the report array. Each row is one object: code, name, section, path, value, isValid, and error.

Supplier onboarding gates

Manufacturing and procurement teams onboard CII suppliers across the EU. Group the report rows by the section field and render a colour-coded table like the one above, so a procurement reviewer reads a partner's whole D16B invoice at a glance, confirms it carries the right BT-31 VAT identifier and BT-30 registration scheme, and clears the supplier before the first PO ships, without opening the rsm: and ram: element hierarchy.

Readable field paths for EDI mapping

Every report row, and the fields array on every friendly error, translates a nested CII XPath such as IncludedSupplyChainTradeLineItem[2]/SpecifiedLineTradeSettlement into a flat dotted path like lines[2].vatInformation.rate. Map that straight to the field in your EDI translator or ERP import mapping, mark it red in the partner exception queue, and show the message beside it instead of a Schematron stack trace.

ERP-to-ERP and hybrid payload gates

CII is both the document your ERP and EDI pipelines exchange directly and the structured payload embedded inside every ZUGFeRD and Factur-X file. Store the report with each processed document as machine-readable proof of the compliance check, and gate ERP-to-ERP import, hybrid PDF embedding, or Peppol transmission on the pass or fail verdict before a bad invoice moves downstream.

Validate CII REST API Request

Submit standalone CII XML or extracted from a ZUGFeRD/Factur-X PDF, profile detection is fully automatic:

Request
$ curl -X POST https://api.invoicexml.com/v1/validate/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

You only send the file. The API detects the EN 16931 profile automatically and returns the detected values.

Validate CII API Response

Both valid and invalid documents return HTTP 200. The response includes the detected EN 16931 profile and the full specification identifier read from the GuidelineSpecifiedDocumentContextParameter, so you can verify the invoice declares the profile you intended before it goes into production.

CII validation errors often originate deep in the nested trade transaction structure. The friendly message array translates cryptic XPath expressions like /*:CrossIndustryInvoice[...]/*:SupplyChainTradeTransaction[...]/*:IncludedSupplyChainTradeLineItem[2] into plain line-item references that your team can act on immediately.

Each friendly error also carries btCodes and a fields array of dotted JSON paths, so a front-end form can highlight the exact input that failed, for example lines[2].vatInformation.rate, instead of asking the user to decode a CII XPath. Every response, valid or not, also includes a report array with one row per EN 16931 Business Term found on the invoice, ready to render straight into a compliance table.

Valid CII Response

Response, valid invoice
// 200 OK
{
  "valid": true,
  "detail": "Your invoice is EN16931 compliant",
  "data": {
    "schemaValid": true,
    "schematronValid": true,
    "conformanceLevel": "EN16931",
    "profile": "en16931",
    "customizationId": "urn:cen.eu:en16931:2017"
  },
  "errors": [],
  "warnings": [
    {
      "rule": "BR-CL-25",
      "layer": "en16931",
      "line": null,
      "message": "The seller electronic address scheme is uncommon for this country.",
      "btCodes": ["BT-34-1"],
      "fields": ["seller.electronicAddress.scheme"],
      "raw": "[BR-CL-25] EN16931: Electronic address scheme should be a known EAS code (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:ApplicableHeaderTradeAgreement/*:SellerTradeParty/*:URIUniversalCommunication)" }
  ],
  "report": [
    { "code": "BT-27", "name": "Seller name", "section": "seller", "path": "seller.name", "value": "TechParts Europe GmbH", "isValid": true, "errors": [], "warnings": [] }
    // one row per EN 16931 business term, see the compliance report section below
  ]
}

Invalid CII Response

Response, invalid invoice
// 200 OK
{
  "valid": false,
  "detail": "Validation failed with 3 error(s)",
  "data": {
    "schemaValid": true,
    "schematronValid": false,
    "conformanceLevel": "EN16931",
    "profile": "en16931",
    "customizationId": "urn:cen.eu:en16931:2017"
  },
  "errors": [
    {
      "rule": "BR-01",
      "layer": "en16931",
      "line": null,
      "message": "The GuidelineSpecifiedDocumentContextParameter/ID element is missing.",
      "btCodes": ["BT-24"],
      "fields": ["specificationId"],
      "raw": "[BR-01] EN16931: An invoice shall have a specification identifier (BT-24). (at /*:CrossIndustryInvoice/*:ExchangedDocumentContext/*:GuidelineSpecifiedDocumentContextParameter)" },
    {
      "rule": "BR-53",
      "layer": "en16931",
      "line": null,
      "message": "A VAT accounting currency is declared, so the invoice total VAT amount in that currency is required and must be provided.",
      "btCodes": ["BT-6", "BT-111"],
      "fields": ["taxCurrency"],
      "raw": "[BR-53] EN16931: If the VAT accounting currency code (BT-6) is present, then the invoice total VAT amount in accounting currency (BT-111) shall be provided. (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:ApplicableHeaderTradeSettlement)" },
    {
      "rule": "BR-S-05",
      "layer": "en16931",
      "line": 3,
      "message": "Standard-rate VAT category (S) must have a VAT rate greater than 0%.",
      "btCodes": ["BT-152"],
      "fields": ["lines[2].vatInformation.rate"],
      "raw": "[BR-S-05] EN16931: An invoice line with standard-rated VAT shall have a VAT rate greater than 0. (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:IncludedSupplyChainTradeLineItem[2])" }
  ],
  "warnings": [],
  "report": [
    // full field-by-field report, see the compliance report section below
    { "code": "BT-24", "name": "Specification identifier", "section": "header", "path": "specificationId", "value": null, "isValid": false, "errors": ["The GuidelineSpecifiedDocumentContextParameter/ID element is missing."], "warnings": [] }
  ]
}

The CII profile ladder, from MINIMUM to EXTENDED

A single CII syntax carries five conformance levels, declared in BT-24 and detected automatically. MINIMUM holds only document and total amounts for booking aids and is not EN 16931 compliant on its own. BASIC WL (without lines) adds the full header and VAT breakdown but no line detail. BASIC adds line items and is the first level that satisfies the EN 16931 core. EN 16931 (urn:cen.eu:en16931:2017) is the complete semantic model checked against the full CEN Schematron. EXTENDED is the cross-industry superset, adding the structured fields manufacturing, logistics, and procurement need for ERP-to-ERP and EDI exchange beyond the EN 16931 core.

The same five levels appear as the Factur-X and ZUGFeRD profiles, because those hybrid formats embed exactly this CII payload. When a national rule set applies, for example XRechnung-CII in Germany, the KoSIT Schematron is layered on top of the CEN core. The API validates the level the document actually declares in BT-24, not the one you assume, so a MINIMUM file is never failed for missing line items and an EXTENDED file is never under-checked.

Always on the currently-effective rules

The CII standards are maintained for you, and switched on their effective date

The CII rule sets move on their own schedules. UN/CEFACT revises the Cross Industry Invoice schema, CEN publishes new EN 16931 Schematron releases (typically once or twice a year), the Factur-X (FNFE-MPE) and ZUGFeRD (FeRD) consortia version their profile artifacts, and KoSIT updates the XRechnung rules on fixed half-yearly dates. Tracking four standards bodies and keeping each artifact current is the work a self-hosted validator (Mustang, the KoSIT validator) leaves on your plate.

InvoiceXML ships every updated artifact and switches POST /v1/validate/cii to it on the standard's official effective date, automatically. Your integration keeps calling the same endpoint and is always validating against the currently-effective rules, with no version tracking, no library upgrade, no redeploy, and no maintenance window. That removes the 0.3 to 0.5 FTE compliance-maintenance burden and eliminates the risk of an integration silently falling out of compliance the day the rules change.

What the CII validation API checks

UN/CEFACT CII D16B XSD Schema

Validates the document against the UN/CEFACT CrossIndustryInvoice D16B XSD, the syntax referenced by EN 16931 and embedded inside every ZUGFeRD and Factur-X file. Catches structural errors in the deeply nested CII element hierarchy: missing required SpecifiedSupplyChainTradeAgreement elements, incorrect data types in monetary amounts, invalid date format codes, and namespace declaration errors across the rsm:, ram:, qdt:, and udt: prefixes.

EN 16931 CEN Core Schematron

Applies the EN 16931 CEN core business rules, the semantic layer common to every European CII invoice. Covers arithmetic consistency (BR-CO-14: invoice VAT total must equal the sum of the VAT breakdown amounts), cross-field rules (BR-CO-15: invoice total with VAT must equal the total without VAT plus the total VAT amount), VAT category rules (BR-AE-05: reverse charge rate must be zero), and mandatory field rules (BR-06: seller name required, BR-07: seller address required).

Profile and National Artifacts

On top of the CEN core, the API applies the artifacts that match the declared context. For a Factur-X or ZUGFeRD document it adds the per-profile rules for the declared level (MINIMUM, BASIC WL, BASIC, EN 16931, or EXTENDED). For an XRechnung-CII document it adds the German KoSIT Schematron. A MINIMUM file is not required to contain IncludedSupplyChainTradeLineItem elements; the EN 16931 level activates the full core rule set.

BT-24 Rule-Set Auto-Detection

Reads BT-24, the GuidelineSpecifiedDocumentContextParameter/ID, to decide which schema and Schematron to run. urn:cen.eu:en16931:2017 selects the plain CEN core; a Factur-X or ZUGFeRD specification identifier selects the matching profile artifacts; an XRechnung identifier adds the KoSIT rules. The detected context is echoed back in the response, so you validate the document against the rule set it actually declares, not the one you assume it is, and can confirm the declared profile before it reaches production.

Response schema

Both valid and invalid documents return HTTP 200. The specificationIdentifier field in the response is read directly from the submitted XML, if your invoice declares the wrong profile identifier, the response tells you exactly what was found. Create/convert endpoints return HTTP 400 with the same errors structure on validation failure.

Field Type Description
Always present
validbooleanPrimary flag to branch on. true when the CII XML passes both XSD schema and all EN 16931 Schematron rules for its declared profile.
detailstringHuman-readable summary, e.g. "Your CII invoice is EN 16931 compliant." or "Validation failed with 2 error(s)".
data.conformanceLevelstringDetected EN 16931 profile, e.g. EN16931, EXTENDED, BASIC, MINIMUM.
data.specificationIdentifierstringFull specification identifier read from GuidelineSpecifiedDocumentContextParameter/ID, e.g. urn:cen.eu:en16931:2017 or urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:en16931.
data.schemaValidbooleanCII D16B XSD schema check passed.
data.schematronValidbooleanAll EN 16931 Schematron business rules passed for the detected profile.
data.profilestring?
data.customizationIdstring?
Findings (errors and warnings)
errorsobject[]Flat array of finding objects, one per failed EN 16931 rule. Empty when the invoice is valid.
warningsobject[]Flat array of finding objects, one per non-blocking advisory rule. May be present on both valid and invalid responses. Same object shape as errors.
[].rulestringRule identifier, e.g. BR-01, BR-CO-14, BR-S-05.
[].layerstring
[].lineint?Invoice line item number derived from the IncludedSupplyChainTradeLineItem index, or null for header-level findings.
[].messagestringHuman-readable, friendly description that references the plain invoice concept, not the CII element path.
[].btCodesstring[]EN 16931 Business Term codes the rule references, e.g. ["BT-27"].
[].fieldsstring[]Dotted JSON paths the finding maps to, e.g. ["seller.name"]. Use them to highlight the exact form input that failed.
[].rawstringVerbatim technical validator output, with rule code and XPath context, e.g. "[BR-01] EN16931: An invoice shall have a specification identifier (BT-24). (at /*:CrossIndustryInvoice...)"
Compliance report (always present)
reportobject[]One row per EN 16931 Business Term found on the invoice, with its value and a pass/fail flag. null if the report could not be built.
report[].codestringBusiness Term code, e.g. BT-1.
report[].namestringHuman-readable term name, e.g. Invoice number.
report[].sectionstringGrouping for display: header, seller, buyer, lines, payment, totals, or tax.
report[].pathstringDotted JSON path to the field, e.g. lines[0].priceDetails.netPrice.
report[].valuestring?Current value of the term, or null when absent.
report[].isValidbooleanfalse when a validation error references this term, otherwise true.
report[].errorsstring[]All friendly error messages for this term, empty when the term has no errors.
report[].warningsstring[]All friendly warning messages for this term, empty when the term has no warnings.

Integrate CII validation into your workflow

REST API

Call POST /v1/validate/cii from any language in your ERP or EDI middleware. Submit standalone CII D16B XML or a ZUGFeRD/Factur-X PDF; the API handles both without any pre-processing and returns structured JSON in under 2 seconds. Use the echoed BT-24 specification identifier to log which profile and version each trading partner is sending you.

API docs

Zapier / Make / n8n

Add a CII validation step in front of your ERP-to-ERP import or Peppol transmission. On failure, route the friendly errors[].message values to a Slack notification or a partner exception queue, giving your procurement or onboarding team the plain-language violation they need to call the supplier or fix the EDI mapping, without decoding CII XPath expressions by hand.

Automation integrations

CI/CD Pipeline

CII is both your direct ERP-to-ERP and EDI document and the XML layer embedded in every ZUGFeRD and Factur-X file your pipeline generates. Validate the CII output on every build, before PDF/A-3 embedding or EDI dispatch. Catching a BR-CO-14 VAT arithmetic error or a missing BR-06 seller name at build time costs nothing. Catching it after a batch reaches your trading partners costs considerably more. Because the endpoint always runs the currently-effective CEN and KoSIT rules, the build also fails the day a new standard version takes effect, with no library bump on your side.

View cURL example

Complete CII Toolkit

Everything you need to create, convert, validate, and preview CII invoices, via REST API or online.

Frequently Asked Questions

What is CII, and how does it relate to ZUGFeRD and Factur-X?

CII is the UN/CEFACT Cross Industry Invoice, the XML syntax standardized as D16B. It is one of the two syntaxes that carry an EN 16931 semantic invoice (the other is UBL), and it is the structured payload embedded inside every ZUGFeRD and Factur-X hybrid PDF. This endpoint validates standalone CII XML directly, the cross-industry, syntax-level foundation used for ERP-to-ERP and EDI exchange in manufacturing, logistics, and procurement. If you have a hybrid PDF instead of raw XML, use the ZUGFeRD or Factur-X validator, which extracts the embedded CII for you.

Which rule set does the CII validation API apply?

The applicable rule set is auto-detected from the BT-24 GuidelineSpecifiedDocumentContextParameter in the submitted XML. A plain EN 16931 CII invoice (urn:cen.eu:en16931:2017) is checked against the CEN core Schematron. A Factur-X or ZUGFeRD invoice is additionally checked against the per-profile artifacts for the declared level, MINIMUM, BASIC WL, BASIC, EN 16931, or EXTENDED. An XRechnung-CII invoice is checked against the KoSIT rules on top of the CEN core. You submit the file; the API selects the matching schema and Schematron automatically.

Who keeps the CII rule sets up to date when CEN, UN/CEFACT, or KoSIT publish a new version?

We do, on your behalf. When CEN releases a new EN 16931 Schematron, UN/CEFACT issues a new CII schema revision, or the Factur-X, ZUGFeRD, or KoSIT artifacts change, InvoiceXML ships the updated artifacts and switches validation to them on the standard's official effective date. Your integration keeps calling POST /v1/validate/cii and is always validating against the currently-effective rules, with no library upgrade, redeploy, or regulatory tracking on your side. That removes the 0.3 to 0.5 FTE maintenance burden that self-hosted validators (Mustang, the KoSIT validator) place on your team.

Start free today

Ready to automate your invoices?

Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.

GDPR Compliant No credit card required Setup in minutes
Peppol UBL
Factur-X
EN 16931
142 / 142 passed
Compliant
PDF/A-3 embedded