Op deze pagina
- Wat “e‑facturatie” in de EU betekent (praktisch)
- Standaarden die je steeds terugziet
- Leveringsmodellen: PEPPOL vs portals vs clearance (CTC)
- Identificatoren en masterdata: waar projecten misgaan
- Validatie: schema vs businessregels (en waarom beide tellen)
- Implementatiechecklist (business + development)
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.
- “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.
- 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.
- 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.
- 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.
- 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.
- 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