OCR is geen vrijgave: factuur-AI heeft een bewijs- en eigenaarspoort nodig

Een factuur kan perfect uitgelezen zijn en toch de verkeerde factuur zijn om te boeken. Dat is de ongemakkelijke grens waar veel factuur-AI stopt: de software levert velden, maar niemand heeft nog bewezen dat die velden bij de juiste levering, verplichting of eigenaar horen.

Mijn stelling is eenvoudig: OCR maakt factuurdata leesbaar, maar pas een controleerbare bewijs- en eigenaarspoort maakt automatisch boeken verantwoord.

OCR is intake, geen financieel oordeel. Een herkenningsmodel kan leverancier, factuurnummer, bedrag en btw uit een document halen. Het kan daarmee nog niet bewijzen dat de prestatie is geleverd, dat de factuur niet dubbel is, dat de bankrekening klopt of dat iemand bevoegd is om te boeken. Die zekerheid ontstaat pas wanneer bron, betekenis, eigenaar en boekingsuitkomst naar elkaar verwijzen.

De verleiding is begrijpelijk. Handmatig overtypen voelt als verspilde tijd, zeker wanneer een systeem de tekst op een factuur overtuigend kan lezen. Maar de vraag na het lezen is niet of de tekens kloppen. De vraag is of de financiële beslissing klopt.

Bij e-facturen zie je dat onderscheid scherp: een UBL-bron bewaren, afwijkingen in een uitzonderingsqueue zetten en menselijke vrijgave apart registreren maakt van een ontvangen bestand nog geen boeking. Dat onderscheid bepaalt waarom iedere vorm van factuurautomatisering een bewijslaag nodig heeft, ook wanneer de intake uit OCR bestaat.

Een veld kan goed gelezen en toch onbruikbaar zijn

Een OCR-model geeft antwoord op een beperkte vraag: welke tekens staan hier waarschijnlijk op het document? Factuurverwerking vraagt een andere vraag: welke waarde mag ik in mijn administratie gebruiken, op basis van welk bewijs en met welk risico?

Dat verschil zit niet alleen in slechte scans. Een leverancier kan zijn bankrekening wijzigen. Een factuurnummer kan opnieuw worden gebruikt in een andere administratie. Een totaalbedrag kan exact zijn uitgelezen terwijl de bijbehorende dienst nooit is geleverd. Een btw-code kan er vertrouwd uitzien omdat vergelijkbare facturen eerder zo zijn geboekt. Geen van die problemen is opgelost doordat de letters goed zijn herkend.

Daarom behandel ik een confidence score als een routeersignaal, niet als een waarheidsstempel. Een lage score kan betekenen dat een veld onleesbaar is. Een hoge score kan nog steeds betekenen dat het systeem de verkeerde zakelijke context kiest. NIST koppelt betrouwbare AI aan meten tegen grondwaarheid, het documenteren van onzekerheid en menselijke review van onverwachte invoer, met duidelijke verantwoordelijkheden voor de beoordelaars. Die combinatie van grondwaarheid, menselijke controle en vastgelegde verantwoordelijkheden staat ook in het meetkader van NIST.

Het bewijs moet daarom met het veld meereizen. Niet als een mooi rapport achteraf, maar als onderdeel van het record dat iemand moet vrijgeven. Bij een bedrag wil ik kunnen zien uit welk bestand en welke locatie het kwam, welke extractiemethode het leverde, of iemand het wijzigde en welke order, ontvangst of afspraak het bedrag ondersteunt. Zonder die herkomst is een uitgelezen bedrag alleen een voorstel met een nette vorm.

Dat is ook de reden dat een gestructureerde e-factuur geen vrijbrief is. In de actuele Peppol BIS Billing 3.0-specificatie staan onder meer factuurnummer, leverancier, valuta, totalen, regels en een buyer reference of purchase order reference. De specificatie ondersteunt ook verwijzingen naar aanvullende bewijsstukken. Die structuur maakt de factuur beter verwerkbaar, maar zegt nog niet dat de levering compleet is of dat de uitgave mag worden vrijgegeven. Een XML-bestand is sterker dan een foto van een factuur. Het blijft een verklaring van de leverancier, geen onafhankelijke bevestiging van jouw ontvangst of mandaat.

Bij een afwijzing is dezelfde statuslaag belangrijk: een technische of zakelijke Peppol-afwijzing vraagt een andere bronhouder en herstelroute.

Matching voegt betekenis toe

De echte sprong in factuurautomatisering vindt niet plaats wanneer tekst verandert in velden. Die vindt plaats wanneer de velden betekenis krijgen in jouw bedrijfsproces. Matching is de plek waar je toetst of deze factuur bij deze order, deze ontvangst, dit contract of deze periode hoort.

Dat klinkt technisch, maar het is vooral een eigenaarschapsvraag.

De order bezit wat is afgesproken. Het magazijn of de projectverantwoordelijke bezit wat is ontvangen. Een budgethouder bezit de zakelijke acceptatie. Finance bezit de boekingsbeslissing.

De factuur levert een claim die je tegen die bronnen afzet. Geen enkel systeem hoeft al die waarheden te bezitten om de keten betrouwbaar te maken. Het moet wel duidelijk zijn welke bron welk feit bezit.

Een match op factuurnummer en leverancier is daarom een begin, geen oordeel. Een unieke kandidaat kan nog steeds een dubbele factuur zijn. Een orderreferentie kan correct zijn terwijl een deelontvangst nog openstaat. Een factuur zonder order kan legitiem zijn voor huur of een abonnement, maar vraagt dan bewijs van de periode en een bevoegde eigenaar. Het probleem is niet dat de software geen match vindt. Het probleem is dat een match te snel als vrijgave wordt gelezen.

Ik wil minstens drie statussen uit elkaar houden: ontvangen, gematcht en vrijgegeven. Ontvangen betekent dat er een document is. Gematcht betekent dat er een onderbouwde relatie met een zakelijke bron is gevonden. Vrijgegeven betekent dat een bevoegde persoon heeft besloten dat de boeking mag doorgaan. Die drie momenten kunnen technisch in één scherm staan, maar ze mogen inhoudelijk nooit dezelfde betekenis krijgen.

Een uitzonderingsqueue is in dat model geen parkeerplaats voor alles wat de AI niet begrijpt. Het is een werkvoorraad met een reden die iemand kan handelen. source_mismatch vraagt een andere eigenaar dan missing_receipt. duplicate_candidate vraagt een andere controle dan een afwijkende btw-behandeling. De reden bepaalt welk bewijs ontbreekt en wie het kan aanvullen.

Dat patroon zie ik ook in andere financiële koppelingen. Een POS-dagstaat bewijst de afgesloten verkoopdag, terwijl de betaalprovider de geldactie en de boekhouding de verwerking bezit. Een totaal dat netjes is doorgestuurd, vervangt die bronnen niet. Bij facturen werkt het precies zo: herkenning, zakelijke match en financiële verwerking zijn verschillende beweringen met verschillende bewijsdragers.

Boeken is een schrijfactie, read-back is bewijs

De meeste aandacht gaat naar het binnenhalen van data. Mijn zorg begint bij het moment waarop die data een journaalpost wordt. Boeken is geen neutrale export. Het is een schrijfactie met gevolgen voor btw, resultaat, betaaltermijn en soms direct voor de bank.

Daarom hoort na de menselijke vrijgave een read-back. Niet omdat iedere API onbetrouwbaar is, maar omdat een succesvolle schrijfactie alleen bewijst dat een systeem antwoord gaf. De controle zit in de vergelijking tussen wat is vrijgegeven en wat daadwerkelijk is opgeslagen: leverancier, factuurnummer, bedrag, btw, grootboek, periode, boekings-ID en status. Als één van die waarden anders terugkomt, is de keten niet klaar.

Die terugleesstap maakt ook herstel mogelijk. Een correctie hoeft dan niet te beginnen met zoeken in een inbox. Je kunt teruggaan van de boeking naar het vrijgavebesluit, van daar naar de match, van daar naar de bron en uiteindelijk naar de oorspronkelijke pagina of het UBL-veld. Een fout blijft vervelend, maar hij wordt tenminste lokaliseerbaar.

Dat is geen overdreven auditwens. De Nederlandse Algemene Rekenkamer omschrijft informatie als controleerbaar wanneer iemand anders dan de oorspronkelijke opsteller het beheer of de informatie doelmatig kan reconstrueren. Controleerbaarheid vraagt volgens de Rekenkamer dus eisen aan registratie en vastlegging in financiële administratieve systemen. De Belastingdienst verlangt bovendien dat ontvangen facturen in de ontvangen vorm worden bewaard, noemt zeven jaar als bewaartermijn en stelt dat een digitale administratie binnen redelijke termijn controleerbaar moet zijn. Dat maakt het originele bestand onderdeel van het bewijs, niet slechts een bijlage voor noodgevallen.

Ook de Europese AI Act beschrijft de juiste ontwerpintuïtie, al gelden de aangehaalde artikelen specifiek voor hoog-risico-AI.

Daar moeten menselijke toezichthouders de mogelijkheden en beperkingen begrijpen, de uitvoer kunnen interpreteren, negeren of overschrijven en het systeem veilig kunnen onderbreken. Die eisen staan in artikel 14 van de AI Act. Artikel 12 legt voor die systemen ook automatische logging van relevante gebeurtenissen over de levensduur vast. Dat staat in het officiële artikel over record-keeping. Voor gewone factuur-OCR is dat niet automatisch een wettelijke kwalificatie. Het is wel een bruikbaar ontwerpcriterium: een mens moet niet alleen op een knop kunnen drukken, maar de beslissing kunnen begrijpen en later kunnen reconstrueren.

Om eerlijk te zijn: handmatig controleren kan niet de oplossing zijn

Het sterkste tegenargument is terecht. Niemand wil iedere factuur regel voor regel controleren. OCR haalt juist het saaie overtypen weg, en bij een overzichtelijke administratie kan een standaardpakket met automatische herkenning en boeking een enorme praktische winst geven. Als een factuur van een bekende leverancier elke maand hetzelfde patroon volgt, voelt een extra vrijgave als nodeloze vertraging.

Daar ben ik het mee eens. Menselijke vrijgave betekent niet dat een medewerker opnieuw alle velden moet overtypen. Het betekent dat het systeem het oordeel begrenst tot de gevallen waarin bewijs, betekenis of bevoegdheid niet sterk genoeg samenkomen. Een volledige match kan snel door. Een onduidelijke bron, afwijkende bankrekening, ontbrekende ontvangst of dubbele kandidaat moet juist niet door snelheid worden beloond.

De draai zit in de vraag waarop je automatiseert. Automatiseer niet op basis van de modelscore alleen. Automatiseer wanneer bronbewijs, zakelijke match en mandaat samen een aanvaardbaar risico vormen. Laat de mens niet fungeren als menselijke OCR, maar als eigenaar van de beslissing die de machine niet kan nemen.

Dat maakt een goede workflow ook beter bestuurbaar. Je kunt meten hoeveel facturen rechtstreeks doorlopen, welk soort afwijkingen terugkomt, welke eigenaar te lang wacht en hoeveel vrijgegeven boekingen bij read-back verschillen. Zo wordt de uitzonderingsqueue geen bewijs dat automatisering faalt. Het wordt de plek waar je leert welke regels, bronnen en verantwoordelijkheden nog ontbreken.

Een groene status is niet hetzelfde als waarheid

De gevaarlijkste factuurstatus is niet failed. Die vraagt om aandacht. Het risico zit in completed wanneer niemand meer kan uitleggen waarom het bedrag klopt, welke prestatie het ondersteunt, wie de afwijking accepteerde en wat er uiteindelijk in de administratie is opgeslagen.

Een factuur is pas klaar wanneer de keten het verhaal kan dragen: de bron is bewaard, de velden zijn herleidbaar, de zakelijke betekenis is gematcht, een eigenaar heeft de uitzondering of vrijgave gedragen en de boeking is teruggelezen. OCR heeft dan nog steeds waarde. Het doet alleen niet langer alsof lezen hetzelfde is als weten.

Dat is voor mij de volwassen vorm van financiële automatisering. Niet zoveel mogelijk documenten groen maken, maar alleen die beslissingen versnellen die je ook later nog kunt uitleggen. Betrouwbare software neemt werk over. Zij neemt de verantwoordelijkheid niet weg.