EN-16931 REST API: The Complete Toolkit for European E-Invoice Compliance

EN 16931 is the European e-invoicing standard every developer building for the EU market needs to understand. It is not a file format. It is not a protocol. It is a semantic data model — a precise definition of what an electronic invoice must contain, what business rules it must satisfy, and how those rules must be enforced. Every major European e-invoice format in use today is either a direct implementation of EN 16931 or a national extension of it.

If you are building invoicing into a product used by European businesses, EN 16931 compliance is not optional. Germany's B2B mandate is already in force. France's follows in September 2026. Belgium went live January 2026. Croatia, Portugal, Denmark, Latvia — the list grows every quarter. And from July 2030, ViDA makes EN 16931-compliant invoicing mandatory for all intra-EU B2B transactions regardless of country.

InvoiceXML provides a complete EN 16931 API toolkit covering both official XML syntax bindings — CII and UBL — across creation, validation, conversion, extraction, and rendering. This post explains what EN 16931 actually is, when to use CII versus UBL, and which API tool covers which use case.

What EN 16931 actually is

EN 16931 is a European standard published by CEN (the European Committee for Standardization) in 2017, formally titled EN 16931-1:2017. It defines:

• A semantic data model — the list of invoice fields (called Business Terms, or BT-xx) that a compliant invoice must support, with precise definitions of each
• A set of business rules (called BR-xx codes) that enforce relationships between those fields — for example BR-CO-14 requires that the invoice total VAT amount equals the sum of all VAT breakdown amounts
• Two official XML syntax bindings that translate the semantic model into actual XML: UN/CEFACT CII D16B and OASIS UBL 2.1
• A Schematron validation framework that allows automated machine-checking of the business rules

The Schematron is the technical piece that trips most implementations up. Validating EN 16931 is not just XSD schema validation — you need an XSLT 2.0 processor (Saxon-HE is the standard choice) to execute the Schematron business rules, which check semantic correctness across the entire document rather than just structural validity. An invoice can be perfectly valid XML and fail 10 EN 16931 business rules simultaneously.

The CIUS and extension mechanism

EN 16931 is designed to be constrained and extended through a mechanism called CIUS (Core Invoice Usage Specification). A CIUS takes EN 16931, makes some optional fields mandatory, restricts some allowed values, and sometimes adds national extensions. Every major national format is a CIUS:

This is why understanding EN 16931 is the foundation: once you implement EN 16931 correctly in both CII and UBL syntax, you are a short distance from supporting every format in this table.

CII vs UBL: when to use which

This is the question every developer building for the European market needs to answer clearly. Both syntaxes are EN 16931-compliant. Both carry the same semantic data. The XML grammar is completely different. Your choice should be driven by which markets and formats you need to support.

Choose CII when:

Your primary market is Germany or France. ZUGFeRD and Factur-X — the dominant formats in these markets — both embed CII XML inside a PDF/A-3 container. If you are generating ZUGFeRD or Factur-X output, your XML layer is CII by definition.

You need XRechnung for German public sector (B2G). XRechnung supports both CII and UBL syntax, but the CII profile is more widely implemented and tested in German public sector AP systems. If in doubt about which syntax a German buyer's portal accepts, CII is the safer choice.

You are working with Croatian or Portuguese mandates. Croatia's EN 16931 implementation and Portugal's CIUS-PT both use CII syntax.

You want a single syntax for the Franco-German market. France accepts Factur-X (CII in PDF), standalone CII, and UBL. Germany accepts ZUGFeRD (CII in PDF), XRechnung CII, and XRechnung UBL. CII covers both with one implementation.

Choose UBL when:

You are connecting to the Peppol network. Peppol BIS Billing 3.0 — the profile required for Peppol network transmission — is UBL-only. Belgium (mandatory since January 2026), the Netherlands, Norway, Finland, and all other Peppol-mandate countries require UBL delivered via a Peppol access point.

Your customers invoice across Northern Europe. The Netherlands, Belgium, Norway, Denmark, Sweden, Finland — the entire northern Peppol cluster — runs on UBL. If your product serves B2B invoicing in these markets, UBL is your primary format.

You are building for an international multi-market product. PINT (Peppol International) uses UBL and is the format for Peppol-based invoicing in Singapore, Australia, Japan, Malaysia, and New Zealand. A single UBL implementation covers the entire global Peppol footprint.

When you need both:

If your product serves businesses that invoice both within Germany/France and across the Peppol network — or if you are building a multi-country invoicing platform — you need both. The good news is that CII and UBL share the same EN 16931 semantic model, so a document generated in one syntax can be converted to the other without data loss. InvoiceXML's conversion endpoint does exactly this.

The InvoiceXML EN 16931 API toolkit

All endpoints are available at https://api.invoicexml.com. Authentication uses a Bearer token in the Authorization header.

Base URL: https://api.invoicexml.com
Authorization: Bearer YOUR_API_KEY
Content-Type: multipart/form-data

Create EN 16931 invoices from structured data

Generate a validated EN 16931-compliant XML invoice from structured input. Choose your syntax (CII or UBL) and profile, supply the invoice data, and receive a validated XML document — or a complete PDF/A-3b hybrid file for ZUGFeRD and Factur-X output.

Create CII — for ZUGFeRD, Factur-X, XRechnung CII, CIUS-PT, and standalone EN 16931 CII output.

Try Create CII online → · API docs: POST /v1/create/cii

curl -X POST https://api.invoicexml.com/v1/create/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "InvoiceNumber=INV-2025-001" \
  -F "IssueDate=2025-09-01" \
  -F "SellerName=Acme GmbH" \
  -F "SellerTaxId=DE123456789" \
  -F "SellerCountry=DE" \
  -F "BuyerName=Example SAS" \
  -F "BuyerCountry=FR" \
  -F "Currency=EUR" \
  -F "Lines[0].Description=Consulting Services" \
  -F "Lines[0].Quantity=10" \
  -F "Lines[0].UnitPrice=100.00" \
  -F "Lines[0].TaxPercentage=19" \
  -F "Lines[0].TaxCategoryCode=S"

Create UBL — for Peppol BIS 3.0, NLCIUS, EHF, PINT, XRechnung UBL, and standalone EN 16931 UBL output.

Try Create UBL online → · API docs: POST /v1/create/ubl

curl -X POST https://api.invoicexml.com/v1/create/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "InvoiceNumber=INV-2025-001" \
  -F "IssueDate=2025-09-01" \
  -F "SellerName=Acme BV" \
  -F "SellerTaxId=NL123456789B01" \
  -F "SellerCountry=NL" \
  -F "BuyerName=Example SA" \
  -F "BuyerCountry=BE" \
  -F "Currency=EUR" \
  -F "PaymentMeansCode=58" \
  -F "IBAN=NL91ABNA0417164300" \
  -F "Lines[0].Description=Software Development" \
  -F "Lines[0].Quantity=10" \
  -F "Lines[0].UnitPrice=100.00" \
  -F "Lines[0].TaxPercentage=21" \
  -F "Lines[0].TaxCategoryCode=S"

Validate EN 16931 invoices

Submit a CII or UBL invoice and receive a structured JSON validation report covering XSD schema compliance, all 200+ EN 16931 Schematron business rules, and — where applicable — the CIUS-specific overlay rules (XRechnung CIUS-REC-DE, Peppol BIS, NLCIUS, etc.). Both syntax bindings return HTTP 200 with valid: true or valid: false — use the boolean to gate downstream logic without exception handling.

Validate CII — standalone CII XML or ZUGFeRD/Factur-X PDF (embedded XML extracted automatically).

Try Validate CII online → · API docs: POST /v1/validate/cii

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

Validate UBL

Try Validate UBL online → · API docs: POST /v1/validate/ubl

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

Both validation

{
  "valid": false,
  "detail": "Validation failed with 2 error(s)",
  "data": {
    "conformanceLevel": "EN16931",
    "specificationIdentifier": "urn:cen.eu:en16931:2017"
  },
  "errors": {
    "xml": [
      "[BR-CO-14] Invoice total VAT amount must equal the sum of VAT breakdown amounts.",
      "[BR-06] An invoice shall contain the seller name."
    ],
    "friendly": [
      {
        "rule": "BR-CO-14",
        "message": "The invoice total VAT amount does not match the sum of VAT breakdown amounts. Check that all tax subtotals are consistent."
      },
      {
        "rule": "BR-06",
        "message": "The seller name is missing. Every EN 16931 invoice must include the seller's name."
      }
    ]
  }
}

Convert PDF invoices to EN 16931 XML

The AI pipeline accepts any invoice document — PDF (native or scanned), DOCX, XLSX, JPEG, PNG, HEIC — and returns a validated EN 16931 XML document in your chosen syntax. OCR is applied automatically for scanned documents. The output is validated against the full EN 16931 Schematron before delivery.

PDF to CII — returns standalone CII XML, or a Factur-X/ZUGFeRD PDF/A-3b when embed=true.

Try PDF to CII online → · API docs: POST /v1/transform/to/cii

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

PDF to UBL

Try PDF to UBL online → · API docs: POST /v1/transform/to/ubl

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

The profile

Convert between CII and UBL

Convert between the two EN 16931 syntax bindings without data loss. Every EN 16931 Business Term (BT-xx) is mapped from one XML grammar to the other. The output is validated against EN 16931 Schematron before delivery.

This is the interoperability endpoint — the one that lets you generate in one syntax for one market and transmit in another for a different market, from the same canonical invoice data.

API docs: POST /v1/convert/cii/to/ubl · POST /v1/convert/ubl/to/cii

# CII → UBL (ZUGFeRD/Factur-X source → Peppol submission)
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
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

Extract EN 16931 data from any invoice

Extract the structured EN 16931 data layer from a ZUGFeRD or Factur-X PDF as raw CII XML, or extract invoice fields from any document as a structured JSON object.

Extract XML — returns the embedded CII XML from a ZUGFeRD or Factur-X PDF. Falls back to AI extraction if no embedded XML is found.

API docs: POST /v1/extract/xml

Extract JSON — returns a normalised JSON object with all EN 16931 Business Terms as named fields, from any invoice document regardless of source format.

Try Extract JSON online → · API docs: POST /v1/extract/json

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

Convert a CII or UBL XML document to a clean, typeset PDF for human review. Every EN 16931 Business Term is rendered in a legible invoice layout. Essential for teams that receive structured XML invoices and need a readable version for approval, audit, or dispute workflows.

Preview CII as PDF — API docs: POST /v1/render/cii/to/pdf

Preview UBL as PDF — API docs: POST /v1/render/ubl/to/pdf

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

---

EN 16931 profiles: which to use

For most B2B use cases, EN 16931 is the correct profile. MINIMUM is used by AP automation systems that match against purchase orders rather than processing line item detail. EXTENDED is for industry-specific scenarios requiring fields the core standard doesn't accommodate.

Complete EN 16931 API endpoint reference

EN 16931 mandate coverage

InvoiceXML's CII and UBL tools cover every country where EN 16931 is the mandated or accepted format:

CII syntax covers: Germany (ZUGFeRD B2B, XRechnung B2G), France (Factur-X, standalone CII), Croatia (EN 16931 B2B), Portugal (CIUS-PT), and all EU cross-border transactions under ViDA from 2030.

UBL syntax covers: Belgium (Peppol BIS 3.0, mandatory since January 2026), Netherlands (Peppol B2G), Norway (EHF), Denmark, Finland, Sweden, and any Peppol-network country including Singapore, Australia, Malaysia, and Japan.

Both syntaxes together cover: XRechnung (Germany B2G accepts CII or UBL), the full ViDA cross-border mandate, and any multi-market product serving both the Franco-German CII ecosystem and the Peppol UBL ecosystem.

Get started

The fastest way to evaluate the EN 16931 API is to try 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:

• CII API: the complete toolkit
• UBL API: the complete toolkit
• ZUGFeRD API: the complete toolkit
• Factur-X API: the complete toolkit
• XRechnung API: the complete toolkit
• E-invoicing mandates by country
• Full API documentation

InvoiceXML is the compliance layer for modern European e-invoicing. It covers EN 16931 in both CII and UBL syntax — creation, validation, conversion, extraction, and rendering — via a single REST API, with stateless processing, no data retention, and automatic Schematron rule updates when EN 16931 and its CIUS profiles are revised.