# E‑facturatie in de EU in 2026: wat je moet implementeren (en waarom)

In de EU verschuift facturatie van “PDF als factuur” naar gestructureerde, machineleesbare data. De details verschillen per land, maar de bouwstenen zijn gelijk: een conform datamodel (vaak EN 16931), een syntaxis (UBL of CII), juiste identificatoren en sterke validatie.

## Wat “e‑facturatie” in de EU betekent (praktisch)

In de meeste EU-contexten is een e‑factuur niet alleen een PDF. Het is gestructureerde factuurdata die software kan parsen en valideren (vaak XML), soms met een visuele PDF erbij.

Dit is belangrijk voor automatisering (AP/AR‑workflows), compliance (verplichte businessregels) en betrouwbare uitwisseling tussen systemen.

## Praktische checklist: Wat “e‑facturatie” in de EU betekent (praktisch)

- “Gestructureerde factuur” = machineleesbare velden (koper, verkoper, totalen, btw, regels)
- “Syntaxis” = hoe data wordt gecodeerd (UBL of CII XML)
- “Validatie” = technische + businessregels (schema + schematron, CIUS-regels)

## Standaarden die je steeds terugziet

EN 16931 is het kern-semantische model achter veel EU‑implementaties. Het definieert wat factuurdata betekent (business terms), niet alleen hoe het wordt gecodeerd.

Twee veelvoorkomende XML‑syntaxisvormen zijn UBL (OASIS) en CII (UN/CEFACT). Landen en netwerken kunnen ook een CIUS definiëren die regels en codelijsten aanscherpt.

## Praktische checklist: Standaarden die je steeds terugziet

- EN 16931 (semantisch model)
- UBL (syntaxis)
- CII (syntaxis)
- CIUS (land-/netwerkregels)
- ZUGFeRD/Factur‑X (PDF + ingebedde XML)

## Leveringsmodellen: PEPPOL vs portals vs clearance (CTC)

Sommige landen focussen op netwerkuitwisseling (4‑corner via PEPPOL), andere op nationale portals, en weer andere op clearance/CTC‑modellen waarbij facturen eerst via een platform moeten worden gemeld of gevalideerd.

Scheiding helpt: “juistheid van factuurdata” vs “integratie van het kanaal”. Eenzelfde EN 16931‑mapping kun je vaak hergebruiken over meerdere kanalen.

## Praktische checklist: Leveringsmodellen: PEPPOL vs portals vs clearance (CTC)

- PEPPOL (4‑corner): adresseren via participant IDs; access points routeren
- Portals: upload/API naar overheid- of sectorplatform
- Clearance/CTC: platformbevestiging kan deel zijn van juridische uitgifte

## Identificatoren en masterdata: waar projecten misgaan

De meeste validatiefouten zijn geen “XML‑problemen”, maar masterdata‑problemen: ontbrekende adressen, inconsistente btw‑info, verkeerde koperreferenties of ongeldige codelijstwaarden.

Behandel codelijsten (valuta, eenheden, btw‑categorieën, betaalmiddelen) als onderdeel van je product, niet als documentatie.

## Praktische checklist: Identificatoren en masterdata: waar projecten misgaan

- Normaliseer koper/verkoper‑IDs en adres‑compleetheid
- Valideer codelijsten bij invoer (niet pas bij XML-export)
- Gebruik consistente afronding en btw‑opbouw

## Validatie: schema vs businessregels (en waarom beide tellen)

Een bestand kan “well‑formed” XML zijn en toch worden afgewezen. Validators draaien meestal meerdere lagen: XML-schema (structuur), schematron (regels) en soms netwerk-/landprofielen.

Zorg voor snelle feedback: vroeg valideren, fouten in de UI tonen en het gevalideerde XML opslaan als reproduceerbaar artefact.

## Praktische checklist: Validatie: schema vs businessregels (en waarom beide tellen)

- Schemafouten = ontbrekende/ongeldige elementen
- Schematronfouten = businessregels (bv. btw‑opbouw)
- Profielfouten = CIUS-/netwerkbeperkingen

## Implementatiechecklist (business + development)

Een succesvolle uitrol draait minder om XML genereren en meer om consistente, gevalideerde factuurdata.

Gebruik deze checklist als volgorde‑gids—de meeste teams doorlopen dit meerdere iteraties.

## Praktische checklist: Implementatiechecklist (business + development)

- Bepaal landen/kanalen (PEPPOL, portal, clearance) en welke “factuurtypes” je uitstuurt
- Map je datamodel naar EN 16931 (of CIUS) en kies UBL vs CII
- Fixeer identificatoren (koperreferenties, routing‑IDs) en codelijsten (valuta, eenheid, btw‑categorie, betaalmiddel)
- Genereer XML en valideer lokaal vóór verzending
- Test end‑to‑end met realistische facturen (kortingen, btw‑tarieven, gemengde regels, afronding)
- Operationaliseer: foutafhandeling, retries, audit‑trails, opslag en terugvinden van verzonden facturen

## Gerelateerde bronnen

- [Overzicht EU e‑facturatieplicht](/resources/compliance/european-e-invoicing-mandate)
- [PEPPOL-netwerkgids](/resources/compliance/peppol-network-guide)
- [Codelijsten (btw, eenheden, betalingen)](/resources/code-lists)
- [E‑facturatie woordenlijst](/resources/glossary)