Gids
Markdown-exportE‑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)
Interactieve stamboom
Eén model, twee syntaxen, veel regelsets
EN 16931 bepaalt wat factuurgegevens betekenen. UBL en CII schrijven ze op. CIUS en profielen voegen regels toe. Tik op een vak voor details.
EN 16931
Deel 1 · semantisch model
- Wat het is
- De Europese norm voor e-facturen van CEN. Deel 1 bepaalt wat factuurgegevens betekenen: business terms zoals BT-1 (factuurnummer) en BT-2 (factuurdatum), gebundeld in business groups (BG), plus de bedrijfsregels waaraan ze moeten voldoen.
- Wie het gebruikt
- Elk formaat in deze boom. Publieke afnemers onder Richtlijn 2014/55/EU moeten facturen volgens de norm ontvangen en verwerken; nationale B2B-verplichtingen bouwen erop voort.
- Syntax
- Geen eigen syntax. Deel 3 koppelt het model aan twee XML-syntaxen: UBL 2.1 en UN/CEFACT CII D16B.
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 artikelen
Praktische gids voor leveranciers buiten de EU: EN 16931, ontvangerafhankelijke formaten, routing en reviewstappen vóór verzending naar Europa.
E-facturatie deadlines Europa 2026: Duitsland, Frankrijk, België, Polen en ViDABijgewerkt in augustus 2026: vergelijk e-facturatiedeadlines in Duitsland, Frankrijk, België en Polen en de impact van ViDA op ERP-planning.