Hetzelfde gegeven, twee werelden
In een UBL-factuur staat het btw-bedrag in een element dat zo heet. Er valt niets te interpreteren: een systeem leest het veld en weet wat het is.
In een pdf staat er ergens rechtsonder een getal, met daarnaast misschien het woord “BTW”, misschien “21%”, misschien niets omdat de kolomkop drie regels hoger staat. Wat het getal betekent, volgt uit de opmaak — en opmaak verschilt per leverancier, per pakket en soms per maand.
Veldherkenning is het overbruggen van dat verschil. Niet door te gokken welk getal waarschijnlijk het btw-bedrag is, maar door het document te lezen zoals een mens het leest: de kop hoort bij de kolom, het totaal hoort onder de regels, het bedrag naast “te betalen” is het bedrag dat je betaalt.
Wat je daarna in handen hebt, is dezelfde veldenset als bij een e-factuur. Wat je níet in handen hebt, is de zekerheid die een e-factuur gratis geeft — en het verschil daartussen is precies waar deze pagina over gaat.
Hoe de herkenning werkt
Er wordt geen sjabloon per leverancier ingesteld. Dat is de belangrijkste eigenschap en het verschil met de generatie gereedschap ervoor.
1 · Tekst en positie
Uit een digitale pdf komt de tekst met coördinaten. Uit een scan komt hij via OCR, met een lagere zekerheid.
2 · Lezen op betekenis
Welk getal is een totaal, welk een regelbedrag, welke datum is de vervaldatum — bepaald uit context, niet uit een vaste plek.
3 · Velden invullen
Leverancier, nummer, datums, bedragen, btw per tarief, IBAN, regels. Wat er niet staat, blijft leeg.
4 · Rekenen
Regels optellen, btw tegen percentage leggen, totaal vergelijken. Afwijkingen worden getoond, niet weggewerkt.
5 · Zekerheid meegeven
Per veld een indicatie van hoe zeker het is, zodat nakijken gericht kan in plaats van volledig.
6 · Exporteren
Excel, CSV, JSON of XML, met per rij het bronbestand en de pagina.
Stap 4 is er niet voor de sier. Een leesfout in één regelbedrag is onzichtbaar in de rij zelf en zichtbaar in de optelling, en dat is de enige controle die zonder jouw kennis van de leverancier al iets kan vinden.
De veldenset
Dit is wat er terugkomt. Het is bewust dezelfde set als waar een e-factuur om draait, omdat dat de set is die je boekhoudpakket wil hebben.
| Veld | Waar het meestal staat | Wat het lastig maakt |
|---|---|---|
| Leverancier | Kop of briefhoofd | Handelsnaam versus statutaire naam |
| Btw-nummer | Voettekst | Verwarring met KvK-nummer |
| Factuurnummer | Rechtsboven | Staat naast klantnummer en ordernummer |
| Factuurdatum | Rechtsboven | Naast lever- en vervaldatum |
| Vervaldatum | Bij de betaalinstructie | Soms alleen 'binnen 30 dagen' |
| Bedrag excl. btw | Onder de regels | Meerdere subtotalen bij kortingen |
| Btw per tarief | Onder de regels | Twee of drie tarieven, verlegging |
| Totaal | Onderaan, dikgedrukt | Naast 'reeds betaald' of 'openstaand' |
| IBAN | Voettekst | Meerdere rekeningen op één factuur |
| Regels | Middenblok | Vaak zonder lijnen of vaste kolommen |
De rechterkolom is de eerlijke kolom. Elk van die complicaties is een reden waarom eenvoudige regels — “het grootste getal is het totaal” — op echte facturen mislukken, en waarom herkenning op betekenis moet werken en niet op positie.
Btw is het lastigste veld
Niet omdat het getal moeilijk te vinden is, maar omdat het er op zoveel verschillende manieren kan staan — en omdat een fout hier direct doorwerkt in je aangifte.
Meerdere tarieven op één factuur. Een cateraar factureert 9% op eten en 21% op dienstverlening. Dan zijn er twee grondslagen en twee btw-bedragen, en één samengevoegd bedrag is niet goed genoeg om mee te boeken.
Verlegde btw.Het btw-bedrag is nul, er staat een vermelding op de factuur, en het percentage dat je zou verwachten ontbreekt. Dit wordt overgenomen zoals het er staat. Een systeem dat hier “behulpzaam” 21% invult, maakt van een correcte factuur een onjuiste boeking.
Geen btw omdat de leverancier vrijgesteld is. Ook nul, maar om een andere reden en met een andere behandeling. Het verschil staat in de tekst op de factuur, niet in de bedragen.
Buitenlandse btw. Een Duitse leverancier met 19%, een Belgische met 21% die er anders uitziet. Het percentage wordt gelezen zoals het er staat en niet naar een Nederlands tarief gedwongen.
De rekenkundige controle vangt hier het meeste af: grondslag maal percentage moet het btw-bedrag geven, en grondslag plus btw moet het totaal geven. Klopt dat niet, dan zie je het.
Datums en getallen, de stille fouten
Dit is de categorie die bij overtikken het vaakst misgaat en bij automatische verwerking het minst wordt besproken.
| Op de factuur | Risico | Hoe het opgelost wordt |
|---|---|---|
| 03/04/2026 | Maart of april | Uit de rest van het document |
| 1.234,56 | Duizendtal of decimaal | Uit het patroon in alle bedragen |
| 1,234.56 | Andersom | Idem, per document consistent |
| (120,00) | Negatief bedrag | Herkend als creditregel |
| 10 apr '26 | Jaar onvolledig | Aangevuld uit de context |
| EUR / € / EU | Valuta onduidelijk | Overgenomen, niet omgerekend |
De onderste rij is een keuze en geen tekortkoming. Een bedrag in vreemde valuta wordt overgenomen met zijn valuta erbij, want een omrekening hangt af van een koers en een datum die jij kiest — niet een leverancier van gereedschap.
Alle andere rijen worden per document opgelost en niet per instelling. Een leverancier die de ene maand punten en de andere maand komma’s gebruikt, levert geen verkeerde bedragen op.
Regels herkennen in een document zonder tabel
De meeste facturen zien eruit alsof ze een tabel bevatten. In het pdf-bestand zit die tabel er niet: er staan losse stukjes tekst op coördinaten, en het feit dat ze een rij vormen is iets wat jouw oog erbij verzint.
Dat is de reden dat kopiëren-en-plakken uit een pdf zo vaak een onbruikbare brij oplevert, en waarom de kolommen door elkaar lopen zodra een omschrijving twee regels beslaat.
Bij herkenning worden regels daarom opgebouwd uit betekenis: een omschrijving hoort bij het aantal dat ernaast staat, dat aantal hoort bij een stukprijs, en aantal maal stukprijs moet het regelbedrag geven. Die laatste vermenigvuldiging is meteen de controle.
Wat er daarna terugkomt is per regel: omschrijving, aantal, eenheidsprijs, regeltotaal en waar aanwezig het btw-tarief. Dat is genoeg om kosten per project of per kostenplaats te verdelen in plaats van alleen het factuurtotaal ergens te boeken.
Wat onzekerheid betekent — en waarom je die wilt zien
Elk veld krijgt een indicatie van hoe zeker de herkenning is. Dat klinkt als een technisch detail en is in de praktijk het verschil tussen alles nakijken en gericht nakijken.
Zonder die indicatie moet je uitgaan van twee mogelijkheden: alles klopt, of niets klopt. In het eerste geval kijk je niets na en glipt er af en toe iets doorheen. In het tweede geval kijk je alles na en heb je het overtikken vervangen door overlezen.
Met de indicatie kijk je de tien procent na die ertoe doet. Een vlekkerige scan, een handgeschreven bijschrift, een bedrag dat half over een stempel valt — dat zijn de plekken waar een mens sneller is dan een machine, en de rest hoeft niemand meer te lezen.
Belangrijk: een systeem dat nooit twijfelt, is niet nauwkeuriger. Het meldt zijn twijfel alleen niet, en dan komt de fout er ongemerkt door.
De controles die standaard meelopen
De som van de regelbedragen tegen het bedrag exclusief btw — vangt een leesfout in één regel die verder nergens opvalt.
Grondslag maal percentage tegen het btw-bedrag, per tarief — vangt een verkeerd gelezen percentage of een gemiste tweede tariefregel.
Bedrag exclusief plus btw tegen het totaal — vangt kortingen en toeslagen die je nog niet had gezien.
Aantal maal eenheidsprijs tegen het regeltotaal — vangt de klassieke verschuiving van een cijfer in een kolom.
Factuurdatum vóór vervaldatum — vangt een datum die in het verkeerde veld beland is.
Btw-nummer op formaat — vangt een leesfout in een teken, al zegt het niets over of het nummer bestaat.
Let op wat de laatste regel wel en niet zegt. Of een btw-nummer de juiste vorm heeft, is te controleren op het document zelf. Of het nummer bestaat en bij deze leverancier hoort, is een vraag aan een register — een andere controle, op een ander moment.
Scans, foto’s en de rommelige werkelijkheid
Een deel van de inkomende post is nooit digitaal geweest: papieren facturen die iemand door de scanner haalt, bonnen die met een telefoon zijn gefotografeerd, doorgestuurde faxen bij oudere leveranciers.
Die gaan eerst door OCR — tekstherkenning op een afbeelding — en daarna door dezelfde veldherkenning. Het verschil zit in de zekerheid: waar een digitale pdf exacte tekens geeft, geeft OCR een beste gok per teken, en die gok kan een 8 voor een 3 aanzien.
Daarom doen de rekenkundige controles bij scans het meeste werk. Een verkeerd gelezen cijfer in een bedrag valt niet op als je alleen naar het bedrag kijkt, maar wel meteen als de regels niet meer optellen tot het totaal.
Wat helpt aan jouw kant: recht scannen, op 300 dpi, in kleur of grijstinten. Wat niet helpt: een foto onder een hoek met schaduw over de helft van de bladzijde. Dat laatste werkt vaak nog steeds, alleen met meer velden die nagekeken willen worden.
Wat er principieel niet uit te halen is
Deze lijst is korter dan de vorige en belangrijker, want dit is waar beloftes van leveranciers meestal te ver gaan.
Een gegeven dat niet op de factuur staat
Geen inkoopordernummer op het document betekent geen inkoopordernummer in de uitkomst. Elke techniek die er tóch een geeft, heeft gegokt.
Op welke kostenplaats het hoort
Dat is jouw indeling, niet die van de leverancier. Er is niets op het document dat het kan vertellen tenzij jij erom hebt gevraagd.
Of het bedrag klopt met de afspraak
Een prijs die twintig procent te hoog is, wordt net zo netjes gelezen als een juiste. Dat is een vergelijking met je bestelling, geen leesvraag.
Of de factuur echt is
Herkenning zegt wat er staat, niet of het klopt dat het er staat. Betaalgegevens die afwijken van eerdere facturen van dezelfde leverancier blijven een menselijke controle waard.
Of het al betaald is
Dat weet je bankrekening, niet het document.
Zes documenten die lastiger zijn dan ze eruitzien
Een nette factuur van één pagina is voor niemand een probleem. Dit zijn de gevallen waar herkenning zich bewijst of onderuitgaat.
De factuur van tien pagina’s.Regels lopen door over bladzijden, elke pagina heeft een eigen subtotaal, en het echte totaal staat pas op de laatste. Wie op “het grootste getal” afgaat, pakt hier bijna altijd het verkeerde.
Twee facturen in één bestand. Iemand heeft twee documenten achter elkaar gescand. Dat moeten twee rijen worden en geen één, en de scheiding zit niet in het bestand maar in de inhoud.
De factuur met een creditregel. Een negatief bedrag tussen positieve regels. Wordt het minteken gemist, dan klopt de optelling niet meer — en dat is precies waarom de optelling wordt gecontroleerd.
De herinnering die op een factuur lijkt. Zelfde leverancier, zelfde bedrag, ander nummer of helemaal geen nummer. Als dit als tweede factuur wordt geboekt, staat er een dubbele in je administratie.
De factuur in twee talen. Veel voorkomend bij Belgische en Duitse leveranciers. Kolomkoppen in de ene taal, de betaalinstructie in de andere.
Het bonnetje. Geen kop, geen leveranciersgegevens, soms alleen een bedrag en een datum. Wat eruit komt is minder dan bij een factuur, en dat is geen tekortkoming maar een eigenschap van het document.
Bij alle zes geldt hetzelfde principe: waar het document iets niet zegt, wordt er niets ingevuld. Een leeg veld dat je zelf aanvult is bruikbaar; een verzonnen veld waar je niets van weet, is dat niet.
Zelf corrigeren, en waarom dat erbij hoort
Geen enkele herkenning is honderd procent, en een product dat dat belooft, verbergt gewoon zijn fouten. Wat telt is hoe snel je een fout ziet en hoe weinig moeite het kost om hem te herstellen.
De uitkomst is daarom bewerkbaar voordat je exporteert. Je past een veld aan, de rekencontroles lopen opnieuw, en pas als de optelling klopt gaat de rij mee naar de export.
Wat dat in de praktijk betekent voor je routine: bij honderd facturen vragen doorgaans een handvol velden aandacht. Die staan bovenaan, met de reden erbij, en je hoeft de andere negenennegentig documenten niet te openen.
Het alternatief — alles nakijken — is de valkuil waar veel administraties in stappen na een slechte ervaring. Dat is begrijpelijk en het maakt de winst nul: overtikken is dan vervangen door overlezen, en dat kost ongeveer evenveel tijd.
De verstandige tussenweg is de eerste maand steekproefsgewijs meer nakijken dan nodig lijkt, vertrouwen opbouwen op je eigen soort documenten, en daarna terugvallen op alleen wat gemarkeerd is.
Wat je terugkrijgt
Eén rij per factuur voor de kop, of één rij per factuurregel wanneer je de detaillering nodig hebt. Beide met het bronbestand en de pagina erbij, zodat een controle een kwestie van openen is.
Formaten: Excel voor werk met de hand, CSV voor import in een boekhoudpakket, JSON voor een eigen verwerking, XML voor systemen die dat verlangen. Dat XML is nadrukkelijk een eigen schema en geen UBL — zie de volgende paragraaf.
Bij honderd facturen tegelijk komt alles in één tabel in plaats van in honderd bestanden. Hoe dat werkt staat op pdf-factuur naar data.
De grens met echte UBL
Deze pagina heet “UBL-veldherkenning” omdat het om dezelfde velden gaat. Het gaat niet om hetzelfde bestand, en dat onderscheid moet scherp blijven.
| Echte UBL-factuur | Herkend uit een pdf | |
|---|---|---|
| Velden | Gegarandeerd aanwezig | Als ze op het document staan |
| Zekerheid | Exact | Hoog, met markering waar niet |
| Verzendbaar via Peppol | Ja | Nee |
| Juridisch een e-factuur | Ja | Nee — het origineel blijft de pdf |
| Werkt op scans | Niet van toepassing | Ja |
| Werkt bij een nieuwe leverancier | Alleen als die aangesloten is | Altijd |
De onderste twee rijen zijn de reden dat dit naast e-facturatie bestaat en niet ertegenover. Waar een leverancier is aangesloten, is UBL beter op elk punt. Waar dat niet zo is — en dat is de meerderheid van de leveranciers, ook al is het niet de meerderheid van het bedrag — is dit wat er overblijft.
Meer over die verdeling staat op e-facturatie en UBL verwerken, en over het netwerk erachter op Peppol uitgelegd.