Elk middelgroot productiebedrijf in SK/EU verwerkt dagelijks tientallen tot honderden papieren of gescande documenten — facturen van leveranciers, orders van afnemers, pakbonnen, douane-aangiften, technische tekeningen met maatlijnen. En bij de meeste ervan zit ergens een medewerker die de waarden handmatig overneemt in het ERP, SAP of Excel. Dit is geen probleem dat bedrijven negeren — het is een probleem dat tot nu toe niet rendabel genoeg was om anders aan te pakken.
In 2026 is dat veranderd. Moderne document intelligence-systemen — een combinatie van OCR (optische tekenherkenning), vision-language modellen en validatielogica — kunnen gestructureerde en semi-gestructureerde documenten verwerken met een nauwkeurigheid die handmatige invoer niet haalt. Dit artikel legt uit waar deze technologie rendeert, hoe een reëel productie-traject eruitziet en waar de grenzen liggen die marketingmateriaal u nooit vertelt.
Waarom klassieke OCR niet volstaat
Wanneer de meeste mensen "OCR" horen, denken ze aan Tesseract of Adobe Acrobat — tools die van een gescande tekst bewerkbare tekst maken. Voor eenvoudige gevallen is dat voldoende. Voor industriële documenten niet.
De problemen doen zich op meerdere niveaus voor:
- Wazige of scheve scan van een 30 jaar oude faxfactuur brengt klassieke OCR veel meer in de war dan een modern VLM-model.
- Tabellen, maatlijnen en schema's zijn een blind spot voor tekst-gebaseerde OCR — de tekens kloppen, maar de structuur waaraan de betekenis ontleend wordt, gaat verloren.
- Variabiliteit in formaten: elke leverancier heeft een ander factuursjabloon. Klassieke OCR-oplossingen lossen dit op met regelgebaseerde extractie per sjabloon — wat bij tientallen leveranciers tientallen sjablonen en permanente onderhoud betekent.
- Contextuele betekenis: het getal "1500" in de rechterbenedenhoek van een pagina kan een paginanummer, een ordernummer of een bedrag in euro's zijn — zonder context kan klassieke OCR dit niet onderscheiden.
Moderne VLM-modellen (vision-language model, zoals Qwen2.5-VL) pakken dit anders aan: ze lezen niet alleen tekens, ze begrijpen de opmaak van het document en de context. Dit is een kwalitatieve sprong, geen evolutie.
Hoe een document intelligence pipeline eruitziet
Een reële industriële pipeline voor documentverwerking bestaat uit meerdere lagen. Elke laag kan een faalpunt zijn als ze wordt onderschat.
1. Ingest en normalisatie
Een document komt binnen als gescande PDF, foto van een telefoon, e-mailbijlage of EDI-uitvoer van een ouder systeem. De eerste stap is conversie naar een uniform intern formaat — inclusief metadata (bron, ontvangstdatum, documenttype).
Hier schuilt een verborgen probleem: bij veldopnames is de invoerkwaliteit extreem variabel. Onscherp, donker, gevouwen — dit gaat VLM-modellen beter af dan klassieke OCR, maar niet oneindig beter. De invoerkwaliteit blijft de uitvoerkwaliteit begrenzen.
2. Documentclassificatie
Voordat extractie start, moet het systeem weten wat het verwerkt. Een factuur, order, pakbon en technische tekening vereisen elk een ander extractieschema. Een classificator (een eenvoudig model of regelgebaseerde logica over de documentstructuur) plaatst het document in de juiste categorie.
3. Gestructureerde extractie
De kern van de pipeline: uit het document worden waarden geëxtraheerd volgens een voorgedefinieerd schema. Voor een factuur zijn dat doorgaans:
- Factuurnummer, factuur- en vervaldatum
- KvK- en btw-nummer van leverancier en afnemer
- Regelitems (omschrijving, hoeveelheid, eenheid, prijs excl. btw, btw, prijs incl. btw)
- Totaalbedrag, IBAN, betalingskenmerk
VLM-modellen verwerken dit rechtstreeks — ze ontvangen een afbeelding of PDF en retourneren JSON volgens het opgegeven schema. De uitvoer sluit aan op het concept structured outputs en JSON mode — het model produceert uitsluitend geldige JSON met gedefinieerde velden.
Voor technische tekeningen is de situatie complexer: maatlijnen, toleranties en materiaalspecificaties zijn verspreid over de geometrische context van het schema. VLM-72B-modellen hebben hier grote stappen gezet, maar voor nauwkeurige technische documenten wordt een mens-in-de-lus aanbevolen voor definitieve verificatie van kritieke waarden.
4. Validatie en cross-check
De geëxtraheerde waarden worden aan meerdere validatielagen onderworpen:
- Wiskundige consistentie: de som van de regelitems moet overeenkomen met het totaalbedrag; het btw-bedrag moet corresponderen met het opgegeven tarief.
- Referentievalidatie: het ordernummer op de factuur moet bestaan in het ERP; het leveranciers-KvK-nummer moet in de database van goedgekeurde leveranciers staan.
- Bereikvalidatie: het factuurbedrag binnen het gebruikelijke bereik voor die leverancier (afwijkingen voor handmatige controle).
Deze validatielaag is cruciaal. In de praktijk hebben we gevallen gezien waarbij het model de getallen correct uit het document extraheerde, maar het factuurbedrag niet overeenkwam met de optelling van de posten — de fout zat in het originele document, niet in de extractie. Zonder validatie zou het ERP inconsistente data bevatten.
5. Integratie in ERP en workflow
Gevalideerde records worden via een API aan het ERP overgedragen. Documenten met een lage confidence (het model is onzeker over een waarde) of met een mislukte validatie gaan naar een wachtrij voor handmatige controle — met markering van het exacte veld waar het probleem zit.
Dit is de juiste aanpak: geen volledige automatisering, maar geassisteerde automatisering met een duidelijke mens-in-de-lus daar waar onzekerheid bestaat.
Waar automatisering rendeert en waar niet
Niet elk documenttype is even geschikt voor automatisering. Op basis van praktijkimplementaties kunnen we het volgende zeggen:
Zeer geschikt: - Facturen van terugkerende leveranciers (het systeem "leert" het formaat) - Gestandaardiseerde orderformulieren (zowel eigen als van handelspartners) - Pakbonnen met barcodes of QR-codes (hybride aanpak OCR + barcode) - Materiaalcertificaten met een vaste structuur
Geschikt met voorbehoud: - Facturen van nieuwe leveranciers (eerste verwerking vraagt meer controle) - Orders binnengekomen via e-mail in plain text of HTML — hier kan een LLM over de e-mailtekst beter presteren dan OCR over een afbeelding - Technische bladen met parametertabellen
Minder geschikt zonder speciale oplossing: - Handgeschreven documenten, oude faxen met lage kwaliteit - Technische tekeningen met complexe geometrische schema's en toleranties — extractie werkt, maar vereist verificatie - Contracten en juridische documenten met ingewikkelde structuur (hier levert LLM over industriële documentatie meer waarde dan een puur OCR-pipeline)
Technische keuzes — cloud vs. on-prem
De meeste bedrijven waarmee we werken, staan voor de vraag: cloud-API of eigen installatie?
Cloud-API (Azure AI Document Intelligence, Google Document AI, AWS Textract): - Snelle start, geen infrastructuur - Pay-per-page model — bij grote volumes (tienduizenden documenten per maand) kunnen de kosten aanzienlijk oplopen - Facturen en orders bevatten commercieel gevoelige data — bij gereguleerde sectoren of intern GDPR-beleid is cloud problematisch
On-prem VLM (bijv. Qwen2.5-VL-72B gekwantiseerd):
- Volledige controle over data — geen data-egress
- Hogere VRAM-eisen: een 72B-model vereist een multi-GPU-setup (ruwweg 40+ GB VRAM voor inferentie)
- Eenmalige hardware-investering, daarna marginale kosten vrijwel nul bij schaalvergroting
Voor de meeste industriële bedrijven in de EU is het on-prem-argument sterk als u een voldoende volume heeft (ruwweg duizenden documenten per maand). Voor lagere volumes of een snelle start kan een cloud-API een verstandig vertrekpunt zijn met een migratieplan op de langere termijn.
Integratie met gestructureerde uitvoer en ERP
Een kritiek detail in deze pipeline is de betrouwbaarheid van het uitvoerformaat van het LLM. Een model dat de ene keer zuivere JSON retourneert en de andere keer JSON verpakt in een markdown-blok, is voor geautomatiseerde integratie onbruikbaar.
Moderne modellen ondersteunen constrained decoding — het model genereert tokens conform een gedefinieerd JSON-schema, zodat het fysiek niet in staat is ongeldige JSON te retourneren. Dit is een vereiste, geen optie, voor productie-inzet. Meer hierover in het artikel Structured outputs en JSON mode.
Voor ERP-integratie geldt de regel: schrijf nooit rechtstreeks vanuit een AI-model naar het ERP. Het standaard patroon is:
- 1.AI extraheert en valideert → resultaat naar een staging-tabel
- 2.Validatieregels (script of workflow-engine) controleren de consistentie
- 3.Bij succes → automatische import in het ERP; bij onzekerheid → wachtrij voor menselijke controle
- 4.De menselijke reviewer ziet het document, de geëxtraheerde waarden en het specifieke probleemveld
Dit patroon behoudt de auditabiliteit en voorkomt stille datacorruptie in het ERP.
Tekeningen en technische documentatie
Een aparte categorie zijn technische tekeningen — DXF, PDF met geometrie, aansluitschema's. Traditionele OCR is hier vrijwel onbruikbaar, omdat de meeste informatie in de relaties tussen grafische elementen zit, niet in de tekst zelf.
Moderne VLM-modellen kunnen uit een technische tekening het volgende extraheren: - Maatlijnen en toleranties (met nauwkeurigheid afhankelijk van de invoerkwaliteit) - Beschrijving van materialen en oppervlaktebehandelingen - Onderdeel- en revisielijsten
Waar u nog steeds menselijke controle nodig heeft: kritieke veiligheidstoleranties, elektrische schema's voor ATEX-omgevingen, documenten voor certificeringsprocessen. AI helpt hier als assistent, niet als autonome beslisser — vergelijkbaar met de AI-copilot voor operators, waarbij het model het werk reduceert maar de verantwoordelijkheid niet overneemt.
Veelgemaakte fouten bij implementatie
Tot slot van het technische deel — problemen die we keer op keer zien:
"We zetten het in en vergeten het" — een document intelligence pipeline heeft monitoring nodig. Een nieuwe leverancier met een ongebruikelijk factuursjabloon verlaagt de confidence score en belandt in de handmatige wachtrij; dat is in orde, maar de wachtrij moet bewaakt worden.
Onderschatting van variabiliteit — in de pilot test u 50 facturen van 5 leveranciers. In productie heeft u 500 leveranciers, waarvan sommige hun sjabloon wijzigen zonder voorafgaande kennisgeving. Test op een diverse steekproef, niet op "schone" gevallen.
Confidence scores zonder kalibratie — het model geeft een extractiezekerheid op, maar deze scores zijn gekalibreerd op trainingsdata, niet op uw documenten. Houd in de eerste weken van productie bij waar het model "zeker" meldt maar toch fout zit — stel op basis daarvan de drempels voor handmatige controle in.
Negeren van edge cases — wat gebeurt er als er een factuur in het Duits binnenkomt? Of een document met twee facturen in één PDF? Deze gevallen moeten expliciet gedefinieerd en geïmplementeerd worden; hoop er niet op dat het model er zelf mee omgaat.
Veelgestelde vragen
Hoe nauwkeurig zijn moderne systemen voor factuurextractie?
Voor gestructureerde facturen van terugkerende leveranciers halen moderne VLM-pipelines in de praktijk een nauwkeurigheid van 95–99 % voor sleutelvelden (factuurnummer, bedrag, datum). Voor nieuwe of niet-standaard formaten is de nauwkeurigheid lager — vandaar het belang van de validatielaag en de wachtrij voor handmatige controle. Cijfers uit marketingmateriaal (99,9 %) zijn doorgaans afkomstig uit gecontroleerde tests, niet uit reële productie-omgevingen met volledige invoervariabiliteit.
Is er GPU nodig voor document intelligence?
Voor cloud-API's niet — u betaalt per API-aanroep. Voor on-prem-inzet met VLM-modellen (70B+) wel — u heeft ruwweg 40+ GB VRAM nodig voor redelijke inferentielatencies. Kleinere modellen (7–14B) werken ook op een RTX 4090 (24 GB VRAM met kwantisatie), maar met lagere nauwkeurigheid op complexe technische documenten. Voor facturen en orders volstaat ook een 7B-model met goede prestaties.
Kunnen we dit koppelen aan ons bestaande SAP / Exact / ander ERP?
Ja — een document intelligence pipeline produceert gestructureerde JSON die geïmporteerd kan worden via de ERP-API of via standaard integratie-interfaces (REST, IDOC voor SAP, CSV-import voor eenvoudigere systemen). De integratie zelf is niet het probleem; het meeste werk zit in het definiëren van de staging-logica en de validatieregels die specifiek zijn voor uw bedrijfsprocessen.
Hoe zit het met documenten in andere talen (Duits, Pools)?
Moderne VLM-modellen zijn meertalig en verwerken de meeste Europese talen zonder speciale configuratie. Validatieregels (bijv. KvK-formaat, IBAN) moeten per land ingesteld worden. Als u grote volumes verwerkt uit een specifiek land, is het de moeite waard de nauwkeurigheid op reële steekproeven te verifiëren — de prestaties zijn niet altijd gelijkwaardig over alle talen.
Hoe lang duurt de implementatie?
Een eenvoudige pilot op één documenttype (bijv. facturen van de top-20 leveranciers) kan in 4–6 weken worden opgezet. Een volledige productie-inzet met ERP-integratie, monitoring en dekking van alle documenttypen neemt 3–6 maanden in beslag, afhankelijk van de complexiteit van de omgeving en het aantal integratiepunten.
*MP Industrial Solutions helpt bedrijven over te stappen van handmatige documentinvoer naar een verifieerbare, geautomatiseerde datastroom — van een pilot op één factuurtype tot productie-inzet met ERP-integratie. Als u document intelligence aanpakt of overweegt waar te beginnen, beoordelen we graag uw concrete situatie.*