CII e-Invoice REST API Toolkit

Q: What is CII (Cross-Industry Invoice)?

CII is an XML standard developed by UN/CEFACT for structured electronic invoicing. It is the XML syntax embedded inside every ZUGFeRD and Factur-X invoice and one of the two official EN 16931 syntax bindings used across the EU.

Q: How do I validate a CII invoice against EN 16931?

Use the POST /v1/validate/cii endpoint. It validates any CII XML document against the official EN 16931 XSD schema and over 200 Schematron business rules, returning structured pass/fail results with specific BR-xx rule codes, human-readable descriptions, and XPath locations for each violation.

Q: Can I convert a PDF invoice to CII XML?

Yes. Send your PDF to the POST /v1/transform/to/cii endpoint. The AI pipeline handles OCR, field extraction, semantic mapping to the EN 16931 data model, and Schematron validation in a single API call. Accepted input formats include native PDF, scanned PDF, JPEG, PNG, TIFF, DOCX, and XLSX.

Q: What is the difference between CII and UBL?

Both are EN 16931 syntax bindings representing the same semantic data model in different XML grammars. CII uses a trade-agreement-oriented structure and is used inside ZUGFeRD and Factur-X. UBL uses a flatter document-oriented structure and is required by Peppol BIS Billing 3.0. The InvoiceXML API converts between them losslessly.

Q: How do I extract CII XML from a ZUGFeRD or Factur-X PDF?

Use the POST /v1/extract/xml endpoint. It accepts a ZUGFeRD or Factur-X PDF and returns the embedded CII XML attachment. If no XML is embedded, it falls back to AI extraction from the PDF content.

Q: Is invoice data stored after processing?

No. InvoiceXML operates on a stateless model. Documents are processed in memory and purged immediately on response delivery. Nothing is written to disk, logged, or retained.

The UN/CEFACT Cross-Industry Invoice (CII) standard is at the heart of European e-invoicing. It powers ZUGFeRD, Factur-X, and is one of the two official XML syntaxes mandated by the EU's EN 16931 standard. If your product handles invoices in Germany, France, or anywhere across the EU, you will encounter CII — and you will need to create, validate, convert, extract, and preview it.

InvoiceXML provides a complete CII API toolkit accessible via a single REST API. This post walks through every tool available, with code examples, links to try them online, and an honest explanation of why building this yourself is considerably harder than it looks.

What is CII? A brief technical overview

CII (Cross-Industry Invoice) is an XML standard developed by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business). The version used for European e-invoicing is D16B, defined in the CrossIndustryInvoice_100pD16B.xsd schema under the namespace urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100.

CII uses a deeply nested, trade-agreement-oriented XML structure that groups invoice data into three top-level elements:

ExchangedDocumentContext — specification identifier, document type
ExchangedDocument — invoice header (number, date, type)
SupplyChainTradeTransaction — the core payload: parties, delivery, line items, and settlement

Here is a minimal valid CII invoice to illustrate the structure:

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>

  <rsm:ExchangedDocument>
    <ram:ID>INV-2025-001</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20250315</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>

  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Acme GmbH</ram:Name>
        <ram:SpecifiedTaxRegistration>
          <ram:ID schemeID="VA">DE123456789</ram:ID>
        </ram:SpecifiedTaxRegistration>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Example AG</ram:Name>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
    <ram:ApplicableHeaderTradeDelivery/>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:ApplicableTradeTax>
        <ram:CalculatedAmount>190.00</ram:CalculatedAmount>
        <ram:TypeCode>VAT</ram:TypeCode>
        <ram:BasisAmount>1000.00</ram:BasisAmount>
        <ram:CategoryCode>S</ram:CategoryCode>
        <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
      </ram:ApplicableTradeTax>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">190.00</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1190.00</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Professional Services</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>1000.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">1</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
          <ram:TypeCode>VAT</ram:TypeCode>
          <ram:CategoryCode>S</ram:CategoryCode>
          <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
          <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
  </rsm:SupplyChainTradeTransaction>

</rsm:CrossIndustryInvoice>

That is a minimal example. A real-world CII invoice for a complex transaction with multiple line items, tax breakdowns, allowances, charges, and payment terms can easily run to several hundred lines of deeply nested XML. Generating, validating, and parsing it correctly — across every EN 16931 profile — is non-trivial work.

CII is the XML syntax used inside every ZUGFeRD and Factur-X invoice. When a Factur-X PDF arrives in your AP system, the embedded XML attachment is CII. When you generate ZUGFeRD output, the structured data layer is CII. Understanding CII means understanding the foundation of European hybrid e-invoicing.

The InvoiceXML CII API toolkit

InvoiceXML provides six distinct CII tools, each accessible via REST API and also available as an online tool for manual use. All endpoints share the same base URL and authentication:

Base URL: https://api.invoicexml.com
Authentication: Authorization: Bearer YOUR_API_KEY

Every response from an endpoint that produces a CII or UBL document is validated against official EN 16931 Schematron rules before being returned. If the output would be invalid, you receive a structured error response — never a silently broken file.

Tool 1: Convert PDF to CII

What it does: Accepts any PDF invoice — native, scanned, or photographed — and returns a validated CII XML document. The AI pipeline handles OCR, field extraction, semantic mapping to the EN 16931 data model, and Schematron validation in a single API call.

When to use it: Your system receives supplier invoices as PDFs and needs to ingest them as structured CII data for downstream processing — ERP import, AP automation, compliance archiving, or further format conversion.

Try it online API documentation

curl -X POST https://api.invoicexml.com/v1/transform/to/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  -F "profile=en16931"

The profile parameter controls the EN 16931 compliance level of the output. Valid values are minimum, basicwl, basic, en16931, and extended. Defaults to en16931.

Accepted input formats: PDF (native and scanned), JPEG, PNG, TIFF, WEBP, HEIC, DOCX, XLSX.

Tool 2: Create CII from JSON

What it does: Accepts structured invoice data as form fields (seller, buyer, line items, tax breakdown, payment terms) and returns a fully validated CII XML document. No source PDF required — you supply the data, the API produces compliant output.

When to use it: You are building an invoicing module, an ERP integration, or an e-invoicing feature in your SaaS product. You already have the invoice data in your database and need to produce valid CII XML for transmission or archiving.

Try it online API documentation

curl -X POST https://api.invoicexml.com/v1/create/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "InvoiceNumber=INV-2025-001" \
  -F "IssueDate=2025-03-15" \
  -F "SellerName=Acme GmbH" \
  -F "SellerTaxId=DE123456789" \
  -F "SellerStreet=Hauptstraße 1" \
  -F "SellerPostcode=10115" \
  -F "SellerCity=Berlin" \
  -F "SellerCountry=DE" \
  -F "BuyerName=Example AG" \
  -F "BuyerCountry=FR" \
  -F "Currency=EUR" \
  -F "TaxBasisTotal=1000.00" \
  -F "TaxTotalAmount=190.00" \
  -F "GrandTotalAmount=1190.00" \
  -F "Lines[0][description]=Professional Services" \
  -F "Lines[0][quantity]=1" \
  -F "Lines[0][unitPrice]=1000.00" \
  -F "Lines[0][lineTotal]=1000.00" \
  -F "Lines[0][unitCode]=HUR" \
  -F "Lines[0][taxPercentage]=19" \
  -F "Lines[0][taxCategoryCode]=S"

The response is a CII XML document ready to embed in a PDF/A-3 (for ZUGFeRD or Factur-X output), transmit via Peppol, or store in your compliance archive.

Tool 3: Validate CII

What it does: Accepts a CII XML document and validates it against the official EN 16931 XSD schema and Schematron business rules. Returns a structured pass/fail response with the specific rule violations (BR-xx codes), their human-readable descriptions, and the XPath location in the document where each violation occurs.

When to use it: Before submitting an invoice to a trading partner, government portal, or Peppol network. During development and testing of your CII generation pipeline. As a pre-processing check when ingesting CII documents from external sources.

Try it online API documentation

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

A successful validation returns:

{
  "valid": true,
  "errorCount": 0,
  "errors": []
}

A failed validation returns structured errors with rule, message, and context per violation:

{
  "valid": false,
  "errorCount": 2,
  "errors": [
    {
      "rule": "BR-01",
      "message": "An invoice shall have a specification identifier.",
      "source": "schematron",
      "context": "/rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext"
    },
    {
      "rule": "BR-CO-14",
      "message": "Invoice total VAT amount does not match the sum of VAT breakdown amounts.",
      "source": "schematron",
      "context": "/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/..."
    }
  ]
}

The strict parameter (boolean, optional) treats warnings as errors when true — useful for zero-tolerance compliance environments.

Tool 4: Extract CII from a PDF

What it does: Accepts a ZUGFeRD or Factur-X PDF and extracts the embedded CII XML attachment. If no embedded XML is found, falls back to AI extraction from the PDF content to generate a CII document.

When to use it: You receive ZUGFeRD or Factur-X invoices from suppliers and need to access the raw CII data — for ERP import, archiving, or further format conversion. Also useful when you want to verify that the CII XML layer of a hybrid invoice matches the visual PDF layer.

Extract from ZUGFeRD Extract from Factur-X API documentation

curl -X POST https://api.invoicexml.com/v1/extract/xml \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

The response is the raw CII XML document as application/xml. If you need the data as structured JSON rather than XML, use POST /v1/extract/json instead — it runs the full AI validation pipeline including VAT number format checks, address plausibility, and arithmetic verification on every line item.

Tool 5: Preview CII as PDF

What it does: Accepts a CII XML document and renders it as a human-readable PDF. The output is a cleanly formatted invoice PDF generated directly from the structured CII data — not a scan or screenshot, but a properly typeset document showing all EN 16931 Business Terms in a legible layout.

When to use it: CII XML is not human-readable without dedicated tooling. Finance teams, auditors, and AP staff who receive CII files need a way to visually verify invoice contents. This endpoint provides that — without requiring any desktop software to be installed.

Try it online API documentation

curl -X POST https://api.invoicexml.com/v1/render/cii/to/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output preview.pdf

The --output preview.pdf flag saves the binary PDF response to disk. The rendered PDF is for visual preview only — it is not a PDF/A-3 container and carries no legal standing. The original CII XML remains the authoritative compliance document.

Also accepts ZUGFeRD and Factur-X PDFs directly — the embedded CII is extracted automatically before rendering.

Tool 6: Convert between CII and UBL

What it does: Performs lossless bidirectional conversion between CII and UBL 2.1 syntax. Both are EN 16931 syntax bindings — same semantic data model, different XML grammar. The conversion maps every EN 16931 Business Term (BT) from one syntax to the other without data loss.

When to use it:

CII → UBL: Your system generates CII (for ZUGFeRD/Factur-X) and also needs to submit via Peppol, which requires UBL BIS Billing 3.0.
UBL → CII: You receive Peppol UBL invoices and need to embed them in a Factur-X PDF for archiving or for systems that expect CII syntax.
Cross-border interoperability: Connecting German/French CII-based systems with Nordic, Belgian, or Dutch UBL-based Peppol networks.

CII → UBL UBL → CII

# CII → UBL
curl -X POST https://api.invoicexml.com/v1/convert/cii/to/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output invoice-ubl.xml

# UBL → CII
curl -X POST https://api.invoicexml.com/v1/convert/ubl/to/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output invoice-cii.xml

The output of both conversions is validated against EN 16931 Schematron rules before delivery. If the source document contains invalid data, the conversion fails with a structured error response rather than returning a silently broken output.

Note: To convert a CII document embedded inside a ZUGFeRD or Factur-X PDF, first extract it with POST /v1/extract/xml, then pass the extracted XML to the convert endpoint.

Why use the InvoiceXML CII API instead of building it yourself?

This is the right question to ask, and it deserves an honest answer.

CII validation involves two distinct layers: XSD schema validation (is the XML structurally correct?) and Schematron validation (does it satisfy the 200+ EN 16931 business rules?). Running Schematron in .NET, Java, or any modern runtime requires an XSLT 2.0 processor — Saxon-HE is the standard choice. Setting this up is not difficult. Maintaining it is.

The standards change. EN 16931 has had multiple errata releases. ZUGFeRD 2.4 (Factur-X 1.08) was published in late 2025 with new required fields and deprecated element patterns. XRechnung releases a new CIUS version roughly annually. The CII D16B subset used for e-invoicing has clarifications and updates that affect validation outcomes. Every time a standard is updated, your validation layer needs to be updated — tested, deployed, and monitored. If you miss a release, your customers start submitting invoices that get rejected by their trading partners and government portals, and they will blame your product, not the standards body.

The Schematron rules are not simple find-and-replace. Rules like BR-CO-14 (invoice total VAT amount must equal the sum of VAT category tax amounts) require arithmetic evaluation across the entire document tree. Rules like BR-AE-05 (reverse charge VAT rate must be zero) require understanding the VAT category code hierarchy. Rules like BR-E-01 (exempt from VAT requires specific category code) require cross-referencing multiple elements. Implementing these correctly, across all edge cases, for all five EN 16931 profiles, is months of development and testing.

The AI extraction layer is genuinely hard infrastructure. The transform endpoint does something no open-source library can do: it reads an unstructured PDF — including scanned documents, photographed invoices, and documents in German, French, Italian, Spanish, or English — and produces valid CII XML. Building this requires OCR infrastructure, a document AI model trained on European invoice formats, a semantic field extraction layer, a mapping engine, and a validation pipeline. This is not an afternoon project.

Security and compliance are ongoing obligations. Financial documents contain sensitive data — company names, bank details, VAT numbers, payment terms, business relationships. A CII processing service handles this data on behalf of every customer using it. InvoiceXML is designed as stateless-by-default: documents are processed in memory and purged immediately on response delivery. Nothing is written to disk. Nothing is logged. Nothing is stored. This is not just a feature — it is an architectural guarantee backed by GDPR and HIPAA compliance requirements.

Our security team monitors the infrastructure 24/7. Any attempted unauthorised access, unusual traffic patterns, or anomalous API behaviour triggers an immediate response. We run regular penetration testing and dependency audits. You get this for free as a customer — you do not need to staff or fund your own security operation for a compliance feature that is not your core product.

99.95% uptime is a contractual commitment, not a marketing claim. E-invoice processing is often on the critical path of financial workflows. When your ERP generates an invoice, it cannot queue it indefinitely waiting for the compliance layer to come back online. We maintain redundant infrastructure across multiple availability zones, with automatic failover and real-time incident response. Our status page shows live uptime history going back to launch — 100% uptime since December 2025.

You keep your team focused on your product. Every hour a developer spends implementing and maintaining Schematron validation is an hour not spent on features that differentiate your product and win customers. The e-invoice compliance layer is infrastructure, not differentiation. We maintain it so you can ship what matters.

Complete CII API endpoint reference

Operation	Endpoint	Input	Output
PDF to CII (AI)	`POST /v1/transform/to/cii`	PDF, image, DOCX, XLSX	CII XML
Create CII	`POST /v1/create/cii`	JSON	CII XML
Validate CII	`POST /v1/validate/cii`	CII XML	Validation result JSON
Extract CII from PDF	`POST /v1/extract/xml`	ZUGFeRD / Factur-X PDF	CII XML
Extract as JSON	`POST /v1/extract/json`	Any invoice	Structured JSON
Preview CII as PDF	`POST /v1/render/cii/to/pdf`	CII XML or hybrid PDF	PDF
CII to UBL	`POST /v1/convert/cii/to/ubl`	CII XML	UBL 2.1 XML
UBL to CII	`POST /v1/convert/ubl/to/cii`	UBL 2.1 XML	CII XML

All endpoints are available at https://api.invoicexml.com. Authentication uses Bearer token in the Authorization header. Error responses follow RFC 7807 ProblemDetails with structured errorCode fields and human-readable friendly error messages.

Full OpenAPI 3.1 schema available at api.invoicexml.com/openapi.

Get started

The fastest way to evaluate the CII API is to drop a PDF or CII XML file into one of the online tools above — no account or API key required.

To integrate via API, start your free 30-day trial. The free tier includes 100 credits per month permanently — enough to keep your integration running in development and low-traffic production environments indefinitely.

Related resources:

InvoiceXML is the compliance layer for modern European e-invoicing. It covers CII, UBL, ZUGFeRD, Factur-X, XRechnung, and EN 16931 via a single REST API — with no data retained, no infrastructure to maintain, and no standards tracking required on your side.