../blog
4 oktober 2026/5 min lezen

Documenten uitlezen met AI: wanneer is het goed genoeg?

Een AI die facturen, orders of contracten uitleest is zo goed als de testset waarop je hem meet. Zo meet je dat per veld in plaats van per document.

#document-automatisering#automatisering#data-extractie#AI

De vraag komt bijna altijd in dezelfde vorm binnen: "we typen hier elke dag stapels PDF's over — kan AI dat niet uitlezen?" Het antwoord is vrijwel altijd ja. En precies daarom is het de verkeerde vraag.

Uitlezen kan een model. De vraag die ertoe doet, is: hoe vaak zit het ernaast, bij welk veld, en wie merkt het op voordat het in je administratie staat. Dat is geen modelvraag maar een procesvraag — en hij is te meten voordat je iets koopt of bouwt.

Begin bij de stroom, niet bij het model

Een documentstroom automatiseren begint met het kiezen van één stroom: één soort document, één richting, één systeem waarin het eindigt. Niet "onze administratie", maar "orderbevestigingen van deze twaalf afnemers, naar ons ordersysteem".

Bij Boogaard Textiles kwamen orders binnen met klantgegevens en drukwerk in PDF. De winst zat niet in het uitlezen op zich — die zat erin dat de hele keten ergens eindigde: snijdlijnen gegenereerd, papiersparend in het printprogramma geplaatst, en een dashboard met barcodescanning dat bijhield waar elke order stond. Dagwerk werd twintig minuten werk. Had ik alleen de PDF uitgelezen en het resultaat in een mailtje gezet, dan was er niets opgelost: dan typte iemand het alsnog over, met een extra stap ertussen.

Begin dus met tellen. Hoeveel documenten per week, hoeveel verschillende opmaken, hoeveel afzenders, en wat gebeurt er nú met het resultaat. Dat telwerk kost een middag en bepaalt of de rest de moeite waard is.

Meet per veld, niet per document

"95% nauwkeurig" is een getal zonder betekenis. Nauwkeurig op wát? Een IBAN die één keer per tweehonderd documenten fout is, is onbruikbaar. Een vrij tekstveld met een referentie die één keer per twintig fout is, is misschien prima — dat ziet iemand meteen.

Maak daarom je eigen testset voordat je iets inricht:

  1. Trek vijftig tot honderd échte documenten uit je eigen archief. Niet de nette voorbeelden — juist de scheve scans, de exemplaren met een stempel over het bedrag, de afzender die alles anders doet.
  2. Typ één keer met de hand uit wat er per veld had moeten staan. Dat is je ijkpunt en dat blijft het, ook als je later van leverancier of model wisselt.
  3. Scoor per veld in drie categorieën: goed, fout, en niet gevonden.

Die derde categorie is de reden om niet per document te scoren. "Niet gevonden" is goedkoop: het systeem geeft toe dat het het niet weet en legt het bij een mens. "Fout, maar met overtuiging" is duur, want dat gaat ongezien je administratie in.

De duurste fout is de stille fout

Een extractie die netjes zegt dat ze het niet weet, kost een halve minuut aandacht. Een extractie die met hetzelfde gemak een verkeerd bedrag wegschrijft, kost een creditnota, een telefoontje en vertrouwen. Daarop richt je het proces in:

  • Een drempel per veld. Onder die drempel gaat het document naar een controlescherm in plaats van het doelsysteem.
  • Het origineel ernaast. Wie controleert, moet de PDF naast het ingevulde veld zien. Controleren hoort seconden te kosten, niet minuten.
  • Rekenwerk valideren in plaats van lezen. Als een totaal uit regels moet volgen, tel de regels op en vergelijk. Een som die niet klopt, is een signaal dat geen enkel model je geeft.
  • Elke correctie loggen. Welk veld, welke afzender, wat was het en wat werd het. Na een paar weken wijst dat log precies aan waar je iets moet aanpassen.

Dat laatste is een les uit een heel ander project: een validatie-engine die in een ERP-omgeving ruim 30.000 fouten vond en categoriseerde (in dienstverband bij Agron). De waarde zat niet in het aantal — die zat in de categorisering, want daarmee werd "onze data is rommelig" een werklijst waar je bovenaan kon beginnen. Bij documentextractie werkt het hetzelfde: zonder correctielog weet je alleen dát het soms misgaat.

Wat er in de praktijk stukloopt

Dit zijn de dingen die in een demo nooit voorkomen en in productie binnen een maand:

  • Scheve scans, telefoonfoto's, een stempel of paraaf over een bedrag.
  • Handschrift. Reken daar niet op, hoe goed de demo ook was.
  • Een vaste afzender die zijn opmaak wijzigt zonder iets te zeggen. Daar wil je een melding op: "dit ziet anders uit dan de vorige keer".
  • Eén PDF met twee facturen erin, of één factuur over vijf pagina's.
  • Hetzelfde document dat twee keer binnenkomt. Dubbelingen vang je met een sleutel (afzender + nummer + bedrag), niet met AI.

Niet alles hoeft AI

De goedkoopste documentautomatisering is de documentstroom die je omzeilt. Kan de afzender een bestand sturen in plaats van een PDF, of kun je bij zijn systeem — dan is een koppeling exacter, sneller en goedkoper dan elke extractie. Hoe zo'n koppeling eruitziet, staat in het artikel over WMS- en EDI-koppelingen; de bredere afweging over wat je als eerste aanpakt in procesautomatisering voor het MKB.

Gebruik AI waar de bron echt ongestructureerd is en de afzender niets gaat veranderen. Dat is vaak genoeg het geval — maar het is een keuze en geen uitgangspunt.

Zo pak ik het aan

Eén stroom, een testset uit je eigen archief, scores per veld, een controlescherm voor alles onder de drempel, en een log van elke correctie. Wat ik bouw is maatwerk rond je bestaande systemen — zie AI & automatisering en softwareontwikkeling — en de verwerking draait op infrastructuur in eigen beheer. Zitten er persoonsgegevens in de documenten, dan hoort daar een verwerkersovereenkomst bij; meer daarover in data in eigen beheer.

En als je een voorstel van iemand anders op tafel krijgt, stel dan deze drie vragen: op welke documenten is dit gemeten, per welk veld, en wat gebeurt er met wat onder de drempel valt. Een leverancier die daar geen antwoord op heeft, heeft het niet gemeten.