Het probleem
Stel: klant X, een aannemer, stuurt een factuur aan particulier Y voor een verbouwing. Het pakket scant de factuur, herkent de afzender (klant X, want die staat al in het systeem), en koppelt de boeking aan... klant X.
Maar de factuur van klant X is geen inkoopfactuur. Het is een verkoopfactuur die thuishoort bij particulier Y als debiteur. Resultaat: de factuur staat op de verkeerde partij, de debiteurpositie klopt niet, en iemand moet het handmatig corrigeren. Elke keer weer.
Waarom pakketten dit fout doen
De meeste factuurherkenning werkt op basis van het herkennen van bekende partijen. Het pakket zoekt de naam of het KVK-nummer op en plakt daar de factuur aan vast. Logisch, maar onvoldoende. Wat ontbreekt is contextuele herkenning van de richting van de factuur.
Dit is geen incidentele bug van één leverancier. Het is een structureel ontwerpprobleem dat in bijna elk boekhoudpakket terugkomt, omdat herkenning meestal is gebouwd vanuit het perspectief van inkoopfacturen. Daar werkt "wie staat er bovenaan is de afzender, en die is bijna altijd de leverancier" goed genoeg. Maar zodra een klant zelf ook facturen verstuurt, wat bij praktisch elke ondernemer voorkomt, loopt die aanname spaak.
Waarom dit vaker misgaat bij groei
Bij een eenmanszaak met tien facturen per maand corrigeert iemand de fout gewoon handmatig en is het probleem "opgelost", al kost dat wel telkens een paar minuten. Maar zodra een onderneming groeit naar honderden facturen per maand, met meerdere debiteuren die qua naam op elkaar lijken, wordt diezelfde fout exponentieel duurder. Een verkeerd geboekte factuur van €4.000 op de verkeerde debiteur betekent niet alleen extra werk. Het betekent dat je tussentijdse rapportages, je btw-aangifte en je debiteurenbeheer allemaal even niet klopten, totdat iemand het ontdekte.
En dat ontdekken gebeurt vaak laat. Niemand checkt structureel of elke boeking op de juiste partij staat, totdat de jaarrekening wordt opgesteld, of totdat een debiteur een betalingsherinnering krijgt voor een bedrag dat hij helemaal niet verschuldigd is.
Wat dit kost als je het niet oplost
Reken het concreet door. Stel dat 5% van de facturen van een onderneming met honderd verkoopfacturen per maand verkeerd wordt herkend, een conservatieve schatting voor pakketten zonder richtingsherkenning. Dat zijn vijf correcties per maand, zestig per jaar. Elke correctie kost gemiddeld tien tot vijftien minuten: opzoeken, herkennen wat er misging, handmatig herboeken, en controleren of de btw-aangifte van dat kwartaal nog klopt. Dat is tien tot vijftien uur per jaar, uitsluitend aan herstelwerk dat niet nodig zou zijn geweest met een correct werkend systeem.
En dat is alleen de directe tijd. De indirecte schade is vaak groter: een debiteurenoverzicht dat tijdelijk niet klopt, een rapportage aan de bank die net voor een belangrijk gesprek gecorrigeerd moet worden, of een klant die een aanmaning krijgt voor een bedrag dat hij niet verschuldigd is, met alle imagoschade die daarbij hoort.
Hoe ik het anders doe
NAW-gegevens altijd meenemen
Het systeem haalt niet alleen de naam op, maar ook het adres en het KVK-nummer. Dat voorkomt dat twee partijen met een vergelijkbare naam door elkaar worden gehaald.
Richting bepalen op basis van documentstructuur
Op een verkoopfactuur staat de klant als afzender, de ontvanger als debiteur. Het systeem herkent dit patroon en boekt de factuur consequent op de juiste partij.
Verificatiestap bij twijfel
Als het systeem niet zeker is over de richting of de partij, stopt het en vraagt het om bevestiging. Liever één keer een check dan een fout die drie maanden later opduikt in de jaarrekening.
Een tweede valkuil: gelijkende namen
Naast de richting van een factuur speelt er nog een probleem dat met groei alleen maar erger wordt: partijen met (bijna) dezelfde naam. "Jansen Bouw B.V." en "Jansen Bouwbedrijf B.V." zijn voor een mens duidelijk twee verschillende ondernemingen, maar voor een systeem dat puur op tekstuele gelijkenis matcht, kunnen ze door elkaar gehaald worden. Hetzelfde geldt voor familiebedrijven waar vader en zoon, of twee broers, allebei een eigen eenmanszaak hebben met een vergelijkbare handelsnaam.
De oplossing is dezelfde als bij het richtingsprobleem: nooit alleen op naam matchen, altijd het KVK-nummer als unieke sleutel gebruiken zodra dat beschikbaar is. Een naam kan voor verwarring zorgen, een KVK-nummer niet. Pakketten die deze controle niet standaard uitvoeren, zijn extra gevoelig voor precies dit soort fouten naarmate je klantenbestand groeit.
Wat dit in de praktijk oplevert
Kan dit met bestaande pakketten?
Soms, met de juiste instellingen en regels. Maar veel kantoren weten niet dat dit speelt, laat staan dat ze het geconfigureerd hebben. Mijn advies: test je eigen herkenning met tien facturen waarbij de klant zelf de afzender is. Bekijk of de boeking op de juiste debiteur terechtkomt. Als dat niet het geval is, weet je waar je moet beginnen.
Snelle zelftest: laat je pakket tien verkoopfacturen van je klant verwerken. Komt de boeking niet op de juiste debiteur, dan is er een structureel probleem, geen incident.
Concreet stappenplan voor die test: verzamel tien recente facturen die door je klant zelf zijn verstuurd (verkoopfacturen, geen inkoop). Laat je pakket ze verwerken zoals het dat altijd doet. Controleer per factuur: staat het bedrag op de juiste debiteur, niet op je eigen klant als crediteur? Klopt de btw-richting (verkoop = af te dragen, niet aftrekbaar)? Is het NAW van de daadwerkelijke debiteur gebruikt, niet dat van je klant? Bij meer dan twee fouten op tien facturen heb je een structureel probleem dat verder gaat dan incidentele uitzonderingen.
De relatie met je documentstroom
Factuurherkenning staat niet op zichzelf. Het is de tweede laag, ná een goed ingerichte documentstroom. Als facturen al binnenkomen via een rommelige scanmap zonder vaste naamgeving, wordt automatische herkenning alleen maar onbetrouwbaarder: het systeem moet dan zowel het document interpreteren als de juiste partij bepalen, zonder enige context uit de bestandsnaam of -locatie om op terug te vallen. Ik beschrijf die eerste laag, inclusief een concreet naamgevingsformaat, in dit artikel.
Pas wanneer documentstroom én factuurherkenning kloppen, is de derde laag, een correcte, gestandaardiseerde datastructuur op basis van RGS, het volgende logische station. En pas daarna wordt AI iets meer dan een sticker. Hoe dat er in de praktijk uitziet, met een eigen koppeling tussen een lokaal taalmodel en boekhouddata, lees je in dit artikel.
Wat een goede oplossing wél en niet vervangt
Ook met de beste richtingsherkenning blijft een steekproefcontrole verstandig. Geen systeem is foutloos, en de impact van een gemiste fout in de financiële administratie is groter dan in veel andere toepassingen van automatisering. Ik controleer daarom periodiek een willekeurige selectie van geboekte facturen, niet omdat ik het systeem niet vertrouw, maar omdat vertrouwen en controle elkaar niet uitsluiten. Een verificatiestap bij twijfel, zoals ik eerder beschreef, vangt de duidelijke gevallen op. Een steekproef vangt de gevallen op die het systeem ten onrechte niet als twijfelgeval herkende.
Deze combinatie van geautomatiseerde herkenning, een verificatiestap bij twijfel, en een periodieke steekproef als vangnet, is precies wat het verschil maakt tussen "we hebben dit geautomatiseerd" en "we hebben dit betrouwbaar geautomatiseerd". Het eerste is op elk kantoor binnen een paar weken te realiseren. Het tweede vraagt om die extra laag discipline die de meeste kantoren overslaan.
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.