On this page
- What “e-invoicing” means in the EU (practically)
- Standards you will see again and again
- Delivery models: PEPPOL vs portals vs clearance (CTC)
- Identifiers and master data: where projects fail
- Validation: schema vs business rules (and why both matter)
- Implementation checklist (vendor and developer friendly)
What “e-invoicing” means in the EU (practically)
In most EU contexts, an e‑invoice is not just a PDF. It is structured invoice data that software can parse and validate (often XML), sometimes accompanied by a visual PDF.
This matters for automation (AP/AR workflows), compliance (mandatory business rules), and reliable cross‑system exchange.
- “Structured invoice” = machine-readable fields (buyer, seller, totals, VAT, line items)
- “Syntax” = how the data is encoded (UBL or CII XML)
- “Validation” = technical + business rules (schema + schematron, CIUS rules)
Standards you will see again and again
EN 16931 is the core semantic model behind many EU e‑invoicing implementations. It defines what the invoice data means (business terms), not just how it is encoded.
Two common XML syntaxes are UBL (OASIS) and CII (UN/CEFACT). Countries and networks may also define a CIUS (country-specific usage specification) that tightens rules and code lists.
- EN 16931 (semantic model)
- UBL (syntax)
- CII (syntax)
- CIUS (country/network constraints)
- ZUGFeRD/Factur‑X (PDF + embedded XML)
Delivery models: PEPPOL vs portals vs clearance (CTC)
Some countries focus on network exchange (4‑corner via PEPPOL), others rely on national portals, and some use clearance/CTC models where invoices must be reported or approved by a platform before delivery.
From an implementation perspective, you should separate “invoice data correctness” from “delivery channel integration”. You can often reuse the same EN 16931 mapping across multiple channels.
- PEPPOL (4-corner): address via participant IDs; access points route invoices
- Portals: upload/API to a government or sector platform
- Clearance/CTC: platform acknowledgement can be part of legal issuance
Identifiers and master data: where projects fail
Most validation failures are not “XML problems”. They are master‑data problems: missing addresses, inconsistent VAT information, wrong buyer references, or invalid code list values.
Treat code lists (currency, units, VAT categories, payment means) as part of your product, not as documentation.
- Normalize seller/buyer IDs and address completeness rules
- Validate code lists at input time (not just at XML export)
- Use consistent rounding and VAT breakdown logic
Validation: schema vs business rules (and why both matter)
A file can be well‑formed XML and still be rejected. Validators typically run multiple layers: XML schema (structure), schematron (rules), and sometimes network/country profiles.
Plan for fast feedback loops: validate early, surface errors in your UI, and store the validated XML as a reproducible artifact.
- Schema errors = missing/invalid elements
- Schematron errors = business rules (e.g., VAT breakdown)
- Profile errors = CIUS/network constraints
Implementation checklist (vendor and developer friendly)
A successful rollout is less about generating XML and more about producing consistent, validated invoice data.
Use this checklist as a sequencing guide—most teams iterate through it multiple times.
- Define target countries/channels (PEPPOL, portal, clearance) and the “invoice types” you issue
- Map your data model to EN 16931 (or the required CIUS) and decide on UBL vs CII
- Lock down identifiers (buyer references, routing IDs) and code lists (currency, unit, VAT category, payment means)
- Generate XML and validate locally before sending anywhere
- Run end-to-end tests with realistic invoices (discounts, VAT rates, mixed items, rounding)
- Operationalize: error handling, retries, audit trails, storage and retrieval of sent invoices