Kennis · E-facturering
E-facturen valideren en het controlerapport goed lezen
Als een e-factuur uit uw software wordt afgewezen, moet uw team aan de hand van het controlerapport achterhalen welk veld de melding heeft veroorzaakt en wie het kan corrigeren.
Wij laten zien hoe u een controlerapport leest en op welke plaatsen de validatie in uw software thuishoort.
Wat er bij de validatie van een e-factuur wordt gecontroleerd
Een validator controleert een e-factuur achtereenvolgens aan de hand van drie regelsets en legt elke afwijking vast in een controlerapport.
XML-schema van de syntaxis
Een e-factuur volgens EN 16931 is opgesteld in een van twee syntaxen, UBL of UN/CEFACT CII. Alle gangbare toepassingsspecificaties bouwen voort op deze twee syntaxen, zoals XRechnung, ZUGFeRD en Peppol BIS Billing 3.0.
Het XML-schema van de syntaxis bepaalt welke elementen zijn toegestaan, in welke volgorde ze staan en welk gegevenstype ze hebben.
Schemafouten hebben geen regel-ID. De XML-parser meldt ze met eigen codes, bijvoorbeeld cvc-complex-type.2.4.a voor een element op een plaats waar het schema het niet verwacht.
Bij ZUGFeRD is een CII-bestand ingebed in een pdf. De validator controleert het XML-deel. Dit deel is bij afwijkingen van het beelddeel doorslaggevend, aldus de BMF-circulaire van 15 oktober 2025 over de invoering van de verplichte e-factuur.
Bedrijfsregels van de EN 16931
De bedrijfsregels controleren de gegevens van een e-factuur op logische fouten, bijvoorbeeld of verplichte velden zijn ingevuld en of de totalen met elkaar overeenkomen. Het Europees Comité voor Normalisatie (CEN) publiceert deze regels als Schematron-bestanden op GitHub, telkens voor UBL en voor CII.
Aan het voorvoegsel van de regel-ID herkent u het soort controle. Regels met BR en een getal controleren verplichte velden en hun aantal, BR-CO controleert berekeningen en afhankelijkheden tussen velden, BR-CL controleert codelijsten en BR-DEC het aantal decimalen van bedragen. Regels als BR-S, BR-AE of BR-IC controleren de gegevens van afzonderlijke btw-categorieën.
De CEN-bestanden bevatten bovendien syntaxisspecifieke regels. Regels met het voorvoegsel UBL-CR geven bijvoorbeeld een waarschuwing als een UBL-bestand elementen bevat die niet tot het datamodel van de EN 16931 behoren.
Regels van XRechnung en Peppol BIS Billing 3.0
XRechnung en Peppol BIS Billing 3.0 zijn toepassingsspecificaties van de EN 16931, in vaktaal CIUS (Core Invoice Usage Specification) genoemd. Ze schrijven extra velden voor en vullen de EN 16931 aan met eigen regels. Nieuwe gegevensvelden mag een CIUS niet invoeren.
De regels van XRechnung beginnen met BR-DE en zijn afkomstig van de Duitse coördinatiedienst voor IT-standaarden (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 voegt regels toe met de voorvoegsels PEPPOL-EN16931 en PEPPOL-COMMON, plus landspecifieke regels.
De specificatie-ID in BT-24 bepaalt welke toepassingsspecificatie voor het bestand geldt. De validator van de KoSIT kiest op basis van deze ID het passende controlescenario. Een verkeerde of verouderde ID kan er daarom toe leiden dat het bestand aan de hand van andere regels wordt gecontroleerd of wordt afgewezen.
Wat een validatie niet controleert
Een validator herkent niet of het btw-tarief bij de prestatie past of dat de omschrijving van de prestatie volstaat.
Volgens het Duitse federale ministerie van Financiën moeten alle verplichte btw-gegevens in het gestructureerde deel van de e-factuur staan. Een loutere verwijzing naar een bijlage met de omschrijving van de prestatie volstaat niet. Een artikelnaam als “zie bijlage” in BT-153 doorstaat de validatie toch, omdat geen enkele regel de inhoud van dit veld beoordeelt.
De KoSIT en het Forum elektronische Rechnung Deutschland (FeRD) hebben een tabel gepubliceerd die de verplichte gegevens volgens de Duitse btw-wet koppelt aan de passende BT-velden. Aan de hand van deze tabel kunt u bepalen welke verplichte gegevens uw software met eigen plausibiliteitscontroles zou moeten afdekken.
Opbouw van een controlerapport
Elke regel in het controlerapport bevat doorgaans vier gegevens.
Regel-ID
De regel-ID, zoals BR-CO-15 of BR-DE-2, verwijst naar de regel in de documentatie van de betreffende regelset.
Ernstniveau
Een validator markeert elke melding als fout of als waarschuwing. In de Peppol-regels heten fouten fatal. Een waarschuwing alleen leidt doorgaans niet tot afwijzing. Sommige validatoren geven bovendien aanwijzingen, dat wil zeggen aanbevelingen voor een nette implementatie zonder invloed op het resultaat. De KoSIT-validator adviseert aan het einde van zijn rapport om het document te accepteren of af te wijzen.
Peppol voert nieuwe regels vaak eerst in als waarschuwing en stuurt ze in een latere release op tot fout. Met versie 3.0.21 werden bijvoorbeeld de regels PEPPOL-COMMON-R052 en PEPPOL-COMMON-R053 van waarschuwingen tot fouten, zo staat het in de release notes van Peppol BIS Billing 3.0.
Vindplaats
De vindplaats is een XPath-expressie die naar het betreffende element in de XML wijst. Hetzelfde BT-nummer staat in UBL en CII op verschillende plaatsen. Het factuurbedrag inclusief btw (BT-112) staat in UBL in het element cbc:TaxInclusiveAmount onder cac:LegalMonetaryTotal, in CII in het element ram:GrandTotalAmount onder ram:SpecifiedTradeSettlementHeaderMonetarySummation.
Bij regels die meerdere velden vergelijken, wijst de vindplaats vaak naar een bovenliggend element. De waarde die de melding veroorzaakt, vindt u dan via de meldingstekst.
Meldingstekst
De meldingstekst beschrijft de regel en noemt meestal de betrokken BT-nummers. De melding bij BR-CO-15 zegt bijvoorbeeld dat het factuurbedrag inclusief btw (BT-112) gelijk moet zijn aan de som van het factuurbedrag exclusief btw (BT-109) en het btw-bedrag (BT-110).
Sinds versie 3.0.21 beginnen de teksten van de Peppol-regels met de regel-ID.
Controlerapporten in de juiste volgorde analyseren
Een lang controlerapport is vaak terug te voeren op een paar oorzaken.
-
Schemafouten oplossen
Zolang het bestand niet aan het schema voldoet, zeggen de resultaten van de bedrijfsregels weinig of ontbreken ze helemaal. Los daarom eerst de schemafouten in de export op en valideer het bestand daarna opnieuw.
-
Regels groeperen op regel-ID
Een fout in de mapping kan in elke factuurregel optreden. Een factuur met 40 regels levert dan 40 meldingen voor dezelfde regel op, die op één enkele oorzaak teruggaan. Analyseer het rapport daarom op regel-ID.
-
Vervolgfouten herkennen
Een ontbrekend element kan meerdere regels tegelijk schenden. Als de btw-uitsplitsing (BG-23) ontbreekt, meldt de validator bijvoorbeeld BR-CO-18 en daarnaast regels van de betreffende btw-categorie, zoals BR-S-01. Los eerst de oorzaak op en valideer opnieuw, voordat u de overige meldingen afzonderlijk behandelt.
-
Via het BT-nummer naar het eigen datamodel
Het BT-nummer verbindt het controlerapport met uw software. Houd een koppeling bij van elk BT-nummer naar het databaseveld, naar het formulierveld in uw interface en naar de verantwoordelijkheid. De verantwoordelijkheid bepaalt of uw team een fout oplost of uw klant, bijvoorbeeld als stamgegevens ontbreken.
-
Waarschuwingen beoordelen en vastleggen
Besluit voor elke waarschuwing of u haar oplost of bewust accepteert, en leg het besluit vast. Controleer bij elke nieuwe release of een geaccepteerde waarschuwing wordt opgewaardeerd tot fout.
Typische foutoorzaken per regelgroep
De regelgroep laat vaak al zien op welke plek in uw software de correctie moet plaatsvinden.
Schemafouten zonder regel-ID
De oorzaak ligt bij de volgorde van elementen, de namespace of een verkeerd gegevenstype in de export. De correctie vindt plaats in de exportfunctie, eenmalig voor alle klanten.
BR met getal
De oorzaak ligt bij een verplicht veld dat niet is gemapt of in de stamgegevens leeg is. De correctie vindt plaats in de mapping of bij het verplichte veld in de interface.
BR-CO en BR-DEC
De oorzaak ligt bij totalen, afronding, kortingen en toeslagen op documentniveau. De correctie vindt plaats in de rekenlogica van de factuuraanmaak.
BR-CL
De oorzaak ligt bij een verouderde of eigen code, bijvoorbeeld voor maateenheden of landen. De correctie vindt plaats bij de codelijsten in uw software.
BR-S, BR-AE, BR-IC en andere categorieën
Btw-categorie, btw-tarief en vrijstellingsgrond passen niet bij elkaar. De correctie vindt plaats in de btw-logica en bij de artikelstamgegevens.
UBL-CR
De export bevat UBL-elementen buiten het datamodel van de EN 16931. De correctie vindt plaats in de exportfunctie.
BR-DE
Contactgegevens van de verkoper, betalingsgegevens of de referentie van de koper ontbreken. De correctie vindt meestal plaats bij de stamgegevens van uw klanten.
PEPPOL-EN16931 en PEPPOL-COMMON
Het elektronische adres ontbreekt of een identificatie heeft het verkeerde formaat. De correctie vindt plaats bij de stamgegevens en het beheer van de Peppol-ID’s.
Ontbrekende referentie van de koper bij XRechnung (BR-DE-15)
De regel BR-DE-15 meldt een ontbrekende referentie van de koper in BT-10. Bij facturen aan de overheid staat daar de Leitweg-ID van de instantie. Voor B2B-facturen volstaat volgens het Duitse federale ministerie van Financiën voor de btw een plaatshouder als “-”, als de ontvanger van de factuur geen eigen kenmerk opgeeft. Uw software kan het veld voor B2B-facturen daarom vooraf invullen met een plaatshouder die uw klanten kunnen overschrijven.
Afrondingsverschillen bij de btw (BR-S-09)
De regel BR-S-09 vergelijkt het btw-bedrag van de categorie normaal tarief met het product van maatstaf van heffing en btw-tarief. Als uw software de btw per regel afrondt en de bedragen optelt, kan de som daarvan afwijken. Bij veel regels kan de afwijking groter worden dan de tolerantie die de regel toestaat. Bereken het btw-bedrag daarom per categorie uit maatstaf van heffing en btw-tarief, zoals de regel voorschrijft.
Validatie in uw software inbouwen
De validatie hoort op vijf plaatsen in uw software en uw ontwikkelproces.
Vóór verzending
Uw software zou elke e-factuur direct na het aanmaken moeten valideren en de verzending bij fouten moeten tegenhouden. Uw klanten kunnen weinig met een regel-ID of een XPath-expressie. Vertaal daarom de regels die uw klanten zelf kunnen oplossen naar een aanwijzing bij het betreffende formulierveld. De aanwijzing bij BR-DE-6, het telefoonnummer van de contactpersoon van de verkoper in BT-42, kan bijvoorbeeld luiden: “Vul een telefoonnummer in voor vragen”.
Fouten die op uw mapping of uw rekenlogica teruggaan, kan uw klant niet oplossen. Zulke fouten zouden als interne melding naar uw team moeten gaan.
Bij ontvangst
Uw software zou ook inkomende e-facturen moeten valideren en het resultaat bij het document moeten tonen. Sla het originele bestand ongewijzigd op en het controlerapport als apart document ernaast. Het Duitse federale ministerie van Financiën eist dat ten minste het gestructureerde deel van een e-factuur onaangetast in zijn oorspronkelijke vorm wordt bewaard.
Als een inkomende factuur fouten bevat, kan uw klant bij de afzender een gecorrigeerde factuur opvragen. Uw software kan deze stap ondersteunen, bijvoorbeeld met een voorbereid verzoek aan de afzender dat het controlerapport bevat.
In geautomatiseerde tests
Leg een verzameling testfacturen aan die uw factuursoorten met hun codes dekt, bijvoorbeeld 380 voor een factuur en 384 voor een gecorrigeerde factuur. Dek bovendien elke btw-categorie af die uw klanten gebruiken. Daarbij komen kortingen en toeslagen en elke syntaxis die uw software aanmaakt. Neem ook bewust foutieve bestanden op en controleer of de validator ze afwijst.
De KoSIT-validator is een opensourceprogramma voor de opdrachtregel en kan in een build-pipeline worden opgenomen. De KoSIT stelt bovendien een testsuite met voorbeeldfacturen beschikbaar, die geschikt is als uitgangspunt voor uw eigen verzameling.
Na elke update van de regelsets
De regelsets veranderen ook zonder nieuw versienummer. De KoSIT publiceert voor XRechnung 3.0.2 regelmatig bundels met foutcorrecties, het laatst in de versie van 31 augustus 2026. XRechnung 3.0 blijft ten minste tot 31 juli 2027 van kracht.
De voorversie van de specificatie XRechnung 4.0 is op 15 september 2026 verschenen. Ze is uitdrukkelijk niet bedoeld voor productief gebruik, maar geeft u een vroeg overzicht van de nieuwe en gewijzigde functionaliteiten. De definitieve versie verschijnt naar verwachting in het voorjaar van 2027, samen met de technische componenten.
OpenPeppol publiceert voor Peppol BIS Billing 3.0 regelmatig nieuwe releases, de afgelopen jaren telkens in mei en in november. Versie 3.0.21 is op 20 mei 2026 gepubliceerd en is sinds 17 augustus 2026 verplicht.
Plan voor elke release een vast moment waarop u uw testverzameling valideert aan de hand van de nieuwe regels. Leg in elk controlerapport vast met welke versie van validator en regelset het tot stand is gekomen. Zo kunt u een resultaat ook dan nog herleiden als de regels inmiddels zijn gewijzigd. Voor de overstap naar XRechnung 4.0 zou uw testomgeving beide versies parallel moeten kunnen controleren.
Controlerapporten over alle klanten heen analyseren
Als uw software e-facturen voor veel klanten aanmaakt, loont een analyse van de controlerapporten over alle klanten heen. Duikt dezelfde regel-ID plotseling bij veel klanten op, dan ligt de oorzaak waarschijnlijk in de mapping of in een nieuwe regelset. Treedt ze maar bij één klant op, dan ligt de oorzaak eerder in diens stamgegevens.
Validatie met InvoiceRails
De stappen uit dit artikel kunt u volledig zelf uitvoeren. De eenmalige inspanning daarvoor is overzichtelijk, de blijvende niet: regelsets, codelijsten en controleconfiguraties veranderen meerdere keren per jaar, en elke wijziging moet in uw tests, uw verzending en uw releaseplanning worden verwerkt.
Validatie, verzending en het beheer van de regelsets kunt u daarom ook uitbesteden aan een gecertificeerd Peppol Access Point zoals InvoiceRails.
E-factuurvalidator voor afzonderlijke controles
De gratis e-factuurvalidator van InvoiceRails controleert XML-bestanden in UBL en CII en hybride pdf-facturen, zonder aanmelding. Hij herkent syntaxis, versie en profiel automatisch, waaronder XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X en andere profielen van de EN 16931. Vervolgens valideert hij het bestand aan de hand van het XML-schema en de Schematron- en bedrijfsregels van het herkende profiel. Het controlerapport kunt u als pdf downloaden of via een link delen, bijvoorbeeld als uw support een afgewezen factuur met een klant bespreekt.
InvoiceRails-API in uw software
InvoiceRails is het door OpenPeppol gecertificeerde Peppol Access Point van fino data services. Uw software koppelt InvoiceRails via een REST-API en verzendt en ontvangt daarmee e-facturen voor een onbeperkt aantal klanten, desgewenst als white label.
De API biedt de validatie als eigen endpoint, eveneens met automatische profielherkenning. Uw software kan e-facturen daarmee direct na het aanmaken controleren. Elke melding in het antwoord bevat regel-ID, ernstniveau, meldingstekst en vindplaats als XPath. Uw software kan de validatie-ID bij de factuur opslaan en het resultaat ten minste 90 dagen lang opnieuw opvragen.
InvoiceRails valideert elk bestand dat uw software via Peppol verzendt, ook zonder deze aanroep. Uw software moet vooraf nagaan welke formaten een ontvanger ondersteunt.
InvoiceRails controleert ook inkomende e-facturen en geeft het originele bestand samen met de uitgelezen factuurgegevens door aan uw software. Een webhook meldt uw software elke wijziging van de afleverstatus.
Uw software blijft verantwoordelijk voor de koppeling van de velden uit uw datamodel, de begrijpelijke aanwijzingen in uw interface en de plausibiliteitscontroles voor verplichte gegevens die door geen enkele regel worden gedekt.
