Het probleem met handmatige naamgeving
Als een document de verkeerde naam krijgt, of helemaal geen logische naam, dan verlies je het niet meteen. Je vindt het gewoon drie keer zo langzaam terug. Vermenigvuldig dat met honderd documenten per maand, en je begrijpt hoeveel tijd er weglekt aan zoeken, dubbelchecken en opnieuw openen.
Maar er is een groter probleem: als je later AI wilt inzetten op je documentstroom, heeft die AI iets te herkennen nodig. Een map vol "Scan001.pdf" is voor een taalmodel net zo nutteloos als voor een medewerker.
Hoe ik het oplos
Ik heb een pipeline gebouwd die dit volledig automatiseert:
1. Document wordt ingescand
Gewoon zoals altijd, scanner of telefoon, maakt niet uit.
2. Lokale OCR
Het document gaat automatisch door een OCR-laag die de tekst uitpakt. Geen cloud, alles lokaal op mijn eigen server.
3. Lokaal taalmodel
De uitgelezen tekst gaat door een lokaal LLM. Die herkent: wat voor document is dit, van wie, over welk onderwerp, en wat is de datum?
4. Automatische herbenoeming
Het bestand krijgt een naam in een vast formaat.
Naamgevingsformaat:
YYYY-MM-DD - Klantnaam - Onderwerp of documenttype2025-03-15 - Janssen BV - Inkoopfactuur elektriciteit Q1
2025-04-01 - De Vries - Jaarrekening 2024 concept
2025-04-22 - Pietersen - Bankafschrift april
Welke techniek hier eigenlijk achter zit
Voor de duidelijkheid: dit is geen ingewikkelde of exotische techniek. OCR (Optical Character Recognition) bestaat al decennia en is inmiddels op veel plekken gratis of goedkoop beschikbaar. Het verschil zit niet in welke OCR-engine je gebruikt, maar in wat je ermee doet ná het uitlezen. De meeste mensen stoppen bij "tekst uit een PDF halen". Ik voeg er een stap aan toe: de uitgelezen tekst gaat door een lokaal taalmodel dat er betekenis aan geeft. Wie is de afzender, wat voor documenttype is het, wat is de datum, en eventueel over welke periode of welk onderwerp gaat het.
Dat laatste stapje, van ruwe tekst naar betekenisvolle metadata, is waar de echte tijdsbesparing vandaan komt. Een OCR-laag alleen levert je een doorzoekbare PDF op. Een taalmodel daarachter levert je een bestand met een naam die je in één oogopslag begrijpt, zonder het document te moeten openen.
Hoe dit samenspeelt met je boekhoudpakket
Een vaak onderschat voordeel: zodra documenten consistent benoemd en gearchiveerd zijn, wordt de koppeling met je boekhoudpakket veel betrouwbaarder. Bonnetjes-apps en facturatiekoppelingen werken namelijk het best als de aangeleverde documenten al een herkenbare structuur hebben. Een factuur die binnenkomt met een duidelijke naam en een vaste opslaglocatie is voor elk systeem, of dat nu een boekhoudpakket, een taalmodel of een collega is, makkelijker te verwerken dan een willekeurig benoemd bestand uit een gedeelde scanmap.
Dit is ook precies de basis die nodig is voordat factuurherkenning op de juiste partij goed kan werken. Dat is een onderwerp dat ik apart behandel, omdat het een eigen, specifieke valkuil heeft.
Wat dit oplevert
Zoeken duurt seconden in plaats van minuten. Documenten zijn direct herkenbaar zonder openen. En als je straks AI wilt inzetten voor analyse of samenvatting, heeft die AI al betekenisvolle bestandsnamen om op te sturen. Dit werkt voor elk type document: facturen, bankafschriften, contracten, correspondentie, aangiftes.
Er is nog een effect dat onderschat wordt: voorspelbaarheid. Als elk document dezelfde naamgevingsstructuur heeft, kun je erop vertrouwen, ook zonder erin te kijken. Een collega die voor het eerst in een klantmap kijkt, snapt binnen tien seconden wat erin staat en in welke volgorde. Dat is winst die je niet in geld uitdrukt, maar die zich wel terugbetaalt op de dag dat iemand met vakantie is en een ander moet inspringen.
Wat te doen met je bestaande archief
De meeste kantoren waar ik kom, hebben niet alleen een nieuw-documenten-probleem, maar ook jaren aan oude bestanden die nooit goed zijn benoemd. Mijn advies: probeer niet alles met terugwerkende kracht te herstellen. Dat kost meer tijd dan het oplevert. Richt de nieuwe pipeline in voor alles vanaf vandaag, en laat de oude structuur met rust zolang die niet actief in de weg zit.
Is een specifiek dossier wél vaak nodig, bijvoorbeeld bij een langdurig fiscaal traject of een lopende discussie met de Belastingdienst, dan loont het om dát dossier handmatig op te schonen. Selectief werken levert meer op dan een grote opschoonactie die na een week stilvalt omdat de waan van de dag wint.
Veelgemaakte fouten bij naamgevingsconventies
Te veel vrijheid in het format
Als 'onderwerp' vrije tekst is, ontstaan er binnen een maand tien varianten voor dezelfde documentsoort. Werk met een vaste, beperkte lijst van documenttypes.
Geen datum vooraan
Zet de datum altijd eerst (YYYY-MM-DD), zodat bestanden chronologisch sorteren zonder extra moeite, ook in een gewone bestandsverkenner zonder slimme zoekfunctie.
Klantnaam inconsistent schrijven
'Jansen BV', 'Jansen B.V.' en 'Jansen' zijn voor een mens hetzelfde, maar voor een zoekfunctie of script drie verschillende dingen. Spreek één schrijfwijze af en gebruik die overal, ook in je boekhoudpakket.
Geen eigenaar van de regels
Een conventie die niemand bewaakt, verwatert binnen een paar weken. Wijs iemand aan die steekproeven doet en afwijkingen terugkoppelt.
Hoeveel tijd dit kost om in te richten
Een realistische verwachting: het opzetten van de pipeline zelf, de OCR-laag koppelen aan een lokaal taalmodel en de herbenoemingslogica inrichten, kost mij, met de technische kennis die ik inmiddels heb, een paar dagen werk. Voor wie dit voor het eerst doet zonder programmeerervaring, is dat eerder enkele weken, of de inzet van een technische partner. De grootste tijdsinvestering zit echter niet in de techniek, maar in het wennen aan de nieuwe werkwijze door iedereen die met documenten werkt.
Eerste stap zonder automatisering
Heb je nu geen technische oplossing? Begin dan met een simpele naamgevingsconventie die je handmatig doorvoert en train je team daarop. De structuur YYYY-MM-DD - Klant - Onderwerp werkt ook handmatig. Consistentie is het doel, automatisering is de versnelling.
Pas als deze laag staat, is de volgende stap zinvol: het automatiseren van de herkenning van facturen en de juiste boekingspartij. Dat klinkt eenvoudig, maar gaat in de praktijk vaak mis op één specifiek punt: wie is de afzender en wie de boekingspartij. Ik leg dat uit in dit artikel.
Privacy en gevoelige documenten
Een vraag die ik vaak krijg: is het veilig om documenten door een taalmodel te laten herkennen? Het antwoord hangt volledig af van waar dat taalmodel draait. Stuur je documenten naar een cloud-AI-dienst, dan geef je in feite klantgegevens, zoals adressen, bedragen en soms BSN-nummers op loonstroken, uit handen aan een derde partij. Voor een boekhoudkantoor is dat een risico dat niet te rechtvaardigen is, hoe handig de tool ook is.
Daarom draait mijn eigen pipeline volledig lokaal: het OCR-proces en het taalmodel draaien op mijn eigen server, niet bij een externe leverancier. Geen document, geen naam en geen bedrag verlaat mijn netwerk om herkend te worden. Dat is een bewuste, iets duurdere keuze dan een goedkope cloudoplossing, maar voor financiële en persoonsgegevens is dat geen overweging. Het is een randvoorwaarde.
Voor kantoren zonder eigen technische kennis is dit overigens geen reden om dan maar helemaal niets te automatiseren. Er bestaan ook lokaal-draaiende of contractueel goed afgedekte oplossingen van leveranciers die wél begrijpen wat AVG-conforme verwerking van financiële data vraagt. De vraag die je altijd moet stellen, is simpel: waar staat de data fysiek, en wie heeft daar toegang toe?
Gerelateerde artikelen
Bas van Mook
Boekhouder, bouwer en digitaliseringsspecialist. Van Mook Administratie & Advies. KvK 97207241.
Bas combineert een actieve boekhoudpraktijk met zelfgebouwde AI-tools: van MCP-servers tot geautomatiseerde documentstromen. Wat hij hier schrijft, heeft hij zelf gebouwd en getest.