{"id":3445482,"date":"2026-11-02T12:42:55","date_gmt":"2026-11-02T10:42:55","guid":{"rendered":"https:\/\/datanorth.ai\/?p=3445482"},"modified":"2026-11-02T13:57:59","modified_gmt":"2026-11-02T11:57:59","slug":"ocr-vs-extractie-vs-classificatie","status":"publish","type":"post","link":"https:\/\/datanorth.ai\/nl\/blog\/ocr-vs-extractie-vs-classificatie","title":{"rendered":"OCR, extractie of classificatie: welk document-AI-probleem heb je echt?"},"content":{"rendered":"\n

Document-AI is niet \u00e9\u00e9n probleem maar vijf: de pagina digitaliseren, het document classificeren, de velden extraheren, matchen wat je gevonden hebt met je eigen stamdata, en interpreteren waar het antwoord helemaal geen tekst is. Welke van die vijf je hebt, bepaalt de tooling, de nauwkeurigheid die je redelijkerwijs mag verwachten en waar een mens in het proces hoort.<\/p>\n\n\n\n

Dat verkeerd inschatten is op een specifieke manier duur. Teams kopen een tool die stap \u00e9\u00e9n oplost, ontdekken dat de moeilijkheid in stap vier zat, en concluderen dat document-AI niet werkt. In ons eigen bouwwerk is documentverwerking veruit de grootste categorie, en de projecten die vastlopen struikelen vrijwel nooit over het lezen van de pagina.<\/p>\n\n\n\n

Dit artikel zet de vijf problemen uiteen, laat zien hoe je ze uit elkaar houdt, wat per stap realistisch is qua nauwkeurigheid, en waarom matchen veel meer aandacht in de afbakening verdient dan het meestal krijgt.<\/p>\n\n\n\n

Waarom telt het benoemen van het probleem?<\/h2>\n\n\n\n

Omdat elk van de vijf een andere faalvorm heeft, een ander kostenprofiel, en een ander antwoord op de vraag of een gespecialiseerde tool of een algemeen model beter past. Ze als \u00e9\u00e9n ding behandelen betekent inkopen op de verkeerde beperking.<\/p>\n\n\n\n

Het verandert ook wat je meet. Nauwkeurigheid bij digitaliseren is een vraag op tekenniveau. Bij classificeren is het een verwarringsmatrix. Bij extraheren meet je per veld en niet per document, want een document met negen goede velden en \u00e9\u00e9n foute is niet negentig procent goed op een manier waar de ontvanger iets aan heeft. Bij matchen meet je tegen je eigen referentiedata, en dan hangt het resultaat net zozeer af van de kwaliteit van die data als van het model.<\/p>\n\n\n\n

Het onderzoek van RAND naar de oorzaken waarom AI-projecten mislukken<\/a>, gebaseerd op gesprekken met vijfenzestig ervaren vakmensen, noemt gebrekkige data en een verkeerd begrepen probleemstelling onder de belangrijkste oorzaken. Documentwerk is waar allebei het meest letterlijk zichtbaar worden. De data zijn de documenten, en de probleemstelling is welke van deze vijf stappen je eigenlijk oplost.<\/p>\n\n\n\n

Welke vijf document-AI-problemen zijn er?<\/h2>\n\n\n\n
\"vijf<\/figure>\n\n\n\n

Digitaliseren<\/strong> betekent tekst van de pagina halen. Dit is de stap waar mensen aan denken als ze OCR zeggen, en bij schone digitale documenten is het grotendeels opgelost. Het wordt weer echt lastig bij scans van matige kwaliteit, handschrift, foto’s die schuin genomen zijn, en formulieren waarin de indeling zelf betekenis draagt. Is jouw invoer een telefoonfoto van een werkbon in plaats van een systeemgegenereerde PDF, dan is deze stap niet gratis.<\/p>\n\n\n\n

Classificeren<\/strong> betekent bepalen wat voor document je in handen hebt. Binnenkomende post waarin facturen, klachten en contracten door elkaar lopen, moet eerst gesorteerd worden voordat er iets anders kan gebeuren, en archiveringswerk is grotendeels classificeren plus metadata toevoegen. Deze stap is doorgaans betrouwbaar zolang de categorie\u00ebn beperkt en duidelijk verschillend zijn, en wordt lastig wanneer categorie\u00ebn overlappen of wanneer het onderscheid diep in het document verstopt zit.<\/p>\n\n\n\n

Extraheren<\/strong> betekent specifieke waarden eruit halen: factuurnummer, datum, regels, tarieven, betaalcondities. Dit is wat de meeste mensen bedoelen met document-AI. Op gestructureerde, repeterende documenten werkt het goed. De moeilijkheid schaalt met variatie, dus de facturen van \u00e9\u00e9n leverancier zijn overzichtelijk en de facturen van tweehonderd leveranciers zijn een ander project.<\/p>\n\n\n\n

Matchen<\/strong> betekent wat je gevonden hebt afbeelden op je eigen stamdata. De leveranciersnaam op het document moet een crediteurenrecord in je systeem worden. De omschreven dienst moet een artikel in je assortiment worden. De regel moet op een grootboekrekening landen. Dit is de stap die projecten stilletjes opeet, en de volgende sectie gaat over waarom.<\/p>\n\n\n\n

Interpreteren<\/strong> dekt de gevallen waarin het antwoord nergens op de pagina staat. Bochten en T-stukken tellen in een technische tekening om isolatie te calculeren, of een plattegrond lezen, betekent redeneren over geometrie in plaats van tekst lezen. Dit is de moeilijkste van de vijf en de enige waarbij haalbaarheid echt getest moet worden in plaats van aangenomen, zeker wanneer elke opdrachtgever anders tekent en er geen gedeelde conventie is om te leren.<\/p>\n\n\n\n

Waarom gaat matchen vaker mis dan lezen?<\/h2>\n\n\n\n

Omdat lezen een juist antwoord heeft en matchen vaak niet.<\/p>\n\n\n\n

Een extractiestap kun je toetsen aan het document zelf: het tarief op de pagina is honderdtwintig euro of niet. Een matchingstap moet twee woordenschatten overbruggen, en de doelwoordenschat is die van jouw organisatie. In een traject rond contractverwerking dat we onlangs afbakenden, was het lastige niet het lezen van leverancierscontracten, die als PDF in meerdere talen binnenkomen en redelijk goed converteren. Het lastige was dat de servicenaam meestal helemaal niet in het contract staat, en dat de leverancier zichzelf anders noemt dan het ontvangende ERP het doet. Niets op de pagina vertelt je bij welk assortimentsitem het hoort.<\/p>\n\n\n\n

Hetzelfde patroon zie je in de financi\u00eble hoek. Bij een traject rond factuurverwerking is de juiste grootboekrekening bepalen geen extractieprobleem, want het rekeningnummer staat niet op de factuur gedrukt. Het wordt afgeleid uit boekhistorie, uit de leverancier, uit wat er eerder met vergelijkbare regels is gebeurd. Toen we een heel jaar aan facturen als benchmark draaiden, ongeveer zevenduizend stuks, verwerkte het systeem achtentachtig procent volledig automatisch, en landden de regels zonder annotatie in drie\u00ebnnegentig en een half procent van de gevallen op de juiste rekening tegen die historie. Dat zijn matchingcijfers en geen leescijfers, en ze kostten het grootste deel van de inspanning.<\/p>\n\n\n\n

Daar volgen twee praktische gevolgen uit. Ten eerste zet de kwaliteit van je stamdata een plafond op de matchingnauwkeurigheid, dus een assortiment met dubbele records en inconsistente naamgeving begrenst het systeem ongeacht het model. Ten tweede is matchen de plek waar een feedbackloop zichzelf terugverdient, want elke correctie die iemand maakt is een gelabeld voorbeeld van precies de dubbelzinnigheid die het systeem niet kon oplossen.<\/p>\n\n\n\n

Hoe bepaal je welk probleem je hebt?<\/h2>\n\n\n\n

Vier vragen, beantwoord over de werkelijke documenten en niet over het ideale geval.<\/p>\n\n\n\n

    \n
  1. Is de invoer al machineleesbaar? Komt hij binnen als systeemgegenereerde PDF, dan is digitaliseren jouw probleem niet. Komt hij binnen als scan of foto, dan wel, en dat verandert zowel de tooling als de kosten.<\/li>\n\n\n\n
  2. Bevat de binnenkomende stroom meer dan \u00e9\u00e9n soort document? E\u00e9n stabiel documenttype schrapt de classificatiestap volledig. Gemengde binnenkomende post maakt classificeren het eerste wat je bouwt.<\/li>\n\n\n\n
  3. Staan de waarden die je nodig hebt letterlijk op de pagina? Zo ja, dan heb je een extractieprobleem, en dat is de meest hanteerbare van de vijf. Moet het antwoord afgeleid, ge\u00efnterpreteerd of ergens anders opgezocht worden, dan heb je een matchingprobleem en hoor je dat als hoofdmoot van het werk te begroten.<\/li>\n\n\n\n
  4. Staat het antwoord \u00fcberhaupt in tekst? Tekeningen, plattegronden en schema’s plaatsen je in de interpretatiecategorie, waar de eerlijke eerste stap een haalbaarheidstoets op je eigen echte documenten is en geen offerte.<\/li>\n<\/ol>\n\n\n\n

    De meeste echte projecten bevatten er meerdere. Dat is prima en de moeite waard om expliciet te benoemen, want een project dat “factuurextractie” heet maar eigenlijk extractie plus matching is, wordt op ongeveer de helft van zijn werkelijke omvang gepland.<\/p>\n\n\n\n

    Welke nauwkeurigheid mag je verwachten?<\/h2>\n\n\n\n

    Andere getallen per stap, en \u00e9\u00e9n percentage noemen voor een hele pijplijn is precies hoe verwachtingen verkeerd worden gezet.<\/p>\n\n\n\n

    Digitaliseren van schone digitale documenten is feitelijk opgelost. Classificeren in een klein aantal duidelijk verschillende categorie\u00ebn is betrouwbaar genoeg om zelden de beperking te zijn. Veldextractie op gestructureerde documenten haalt hoge negentig procent per veld, mits dat veld daadwerkelijk aanwezig en ondubbelzinnig is. Matchen zakt merkbaar, en een volledig geautomatiseerd percentage in de hoge tachtig op een echte gemengde stroom is een goede uitkomst en geen tegenvaller. Voor het interpreteren van tekeningen bestaat geen bruikbare benchmark, en dat is zelf het antwoord: test het voordat je het belooft.<\/p>\n\n\n\n

    Twee dingen doen er meer toe dan het kopcijfer. Meet per veld in plaats van per document, want de velden verschillen enorm in moeilijkheid en een gemiddelde verbergt welk veld je pijn doet. En scheid de zekerheidsvraag van de correctheidsvraag, want een systeem dat weet wanneer het twijfelt is operationeel veel waardevoller dan een systeem dat iets nauwkeuriger is maar overal even stellig.<\/p>\n\n\n\n

    Waar hoort de mens?<\/h2>\n\n\n\n

    Op de uitzonderingen en niet op alles. Alle uitkomsten controleren ongeacht zekerheid haalt het grootste deel van de winst weg en verandert automatisering in een tweede paar ogen op werk dat toch al gedaan werd.<\/p>\n\n\n\n

    Het ontwerp dat werkt is routeren op zekerheid. Items boven de drempel gaan door, items eronder gaan naar een persoon, en waarden zonder match gaan per definitie naar een persoon omdat er niets is om ze naartoe te sturen. Waar het ontvangende systeem financieel of anderszins onvergevingsgezind is, is een controlestap v\u00f3\u00f3r het wegschrijven verstandig ongeacht zekerheid bij de eerste batches, en kun je die aanscherpen zodra de cijfers standhouden.<\/p>\n\n\n\n

    Wat het meest telt is wat er met de correctie gebeurt. Een correctie die wordt toegepast en daarna vergeten, is een gemiste kans, want juist die correcties zijn het goedkoopste trainingssignaal dat er is en ze clusteren precies waar het systeem zwak is. Ontwerp het vastleggen van correcties meteen aan het begin, want het er achteraf in bouwen betekent maanden weggooien van de nuttigste data die je ooit krijgt.<\/p>\n\n\n\n

    Waarom de publieke sector hier vooropgaat<\/h2>\n\n\n\n

    In Nederland komt een groot deel van het documentwerk op dit moment uit overheidsorganisaties, en dat is geen toeval. De Wet open overheid en de nieuwe Archiefwet verplichtten gemeenten, provincies en waterschappen om een meerjarenplan digitale informatiehuishouding voor 2026 tot 2030<\/a> op te stellen, waarin staat hoe ze digitale informatie duurzaam toegankelijk maken. Decennia aan documenten moeten vindbaar worden, en er is geen bezetting om dat handmatig te doen.<\/p>\n\n\n\n

    Voor dat werk is de verdeling opvallend. Digitaliseren is er vaak een echte stap, omdat oude dossiers als scan bestaan. Classificeren is de kern, want een archief bruikbaar maken betekent categorie en metadata toekennen. Extraheren speelt beperkt mee en matchen bijna niet, omdat er geen ontvangend systeem met stamdata achter hangt. Dat maakt archiefprojecten wezenlijk anders van vorm dan factuur- of contractprojecten, en het is de reden dat een aanpak die bij de een werkt bij de ander tegenvalt.<\/p>\n\n\n\n

    Veelgestelde vragen over document-AI<\/h2>\n\n\n\n
    \n
    Wat is het verschil tussen OCR en data-extractie?<\/strong><\/summary>\n

    OCR zet een afbeelding van tekst om in tekens en beantwoordt wat er op de pagina staat. Extractie bepaalt welke van die tekens het factuurnummer, de datum of het tarief zijn, en beantwoordt wat de pagina betekent. Een perfect gedigitaliseerd document kan alsnog stranden op extractie.<\/p>\n<\/details>\n\n\n\n

    Welke nauwkeurigheid mag je van document-AI verwachten?<\/strong><\/summary>\n

    Dat verschilt volledig per stap. Digitaliseren van schone digitale documenten is nagenoeg opgelost, classificeren in een handvol categorie\u00ebn is betrouwbaar, en veldextractie op gestructureerde documenten haalt hoge negentig procent. Bij het matchen met je eigen stamdata zakt de nauwkeurigheid, vaak richting de tachtig.<\/p>\n<\/details>\n\n\n\n

    Waarom lopen documentprojecten vast?<\/strong><\/summary>\n

    Zelden omdat het model de pagina niet kan lezen. De problemen clusteren rond drie dingen: de gevonden waarde heeft geen schone tegenhanger in het ontvangende systeem, de uitzonderingen zijn nooit afgebakend, en niemand had vastgelegd hoe een juist antwoord eruitziet.<\/p>\n<\/details>\n\n\n\n

    Heb je een gespecialiseerde tool nodig of een algemeen model?<\/strong><\/summary>\n

    Bij grote volumes standaarddocumenten in een vast formaat is een gespecialiseerde tool doorgaans goedkoper en voorspelbaarder. Bij wisselende documenten, meerdere talen of documenten die beoordeling vragen, gaat een algemeen model met een validatielaag beter om met de variatie. Veel productiesystemen combineren beide.<\/p>\n<\/details>\n\n\n\n

    Waar hoort de mens in een documentproces?<\/strong><\/summary>\n

    Op de uitzonderingen en niet op alles. Stuur items met lage zekerheid en items zonder match naar een persoon en laat de rest doorlopen, en gebruik de correcties als signaal voor wat je verbetert. Alles controleren ongeacht zekerheid haalt het grootste deel van de winst weg.<\/p>\n<\/details>\n<\/div>\n