700 inkoopfacturen per maand, en de agent keurt er nul goed

Elf aparte administraties. Eén leisuregroep. Gemiddeld 713 inkoopfactuurboekingen per maand, verspreid over entiteiten met elk hun eigen kostenplaatsen, hun eigen btw-eigenaardigheden en hun eigen opvattingen over hoe een leverancier gecodeerd moet worden.

Dus bouwden we daar een agent voor. Hij leest de factuur, matcht de leverancier, stelt de grootboekrekening voor, vult de kostenplaats in, zet de btw-code en schrijft alles weg in Exact Online. Elke werkdag, zonder dat iemand het vraagt.

En hij keurt er precies nul van goed.

Dat is geen beperking waar we nog aan werken. Het is het ontwerp. Want de interessante vraag bij het automatiseren van factuurverwerking is niet hoeveel het systeem kan. Het is waar het moet stoppen, en of iemand dat bewust heeft besloten.

De mythe van de zelfverzekerde agent

De meeste automation wordt verkocht op zelfvertrouwen. Het leest het document, het kent het antwoord, het boekt de regel. Demo's zijn er dol op. Je laadt een PDF in, de velden vullen zichzelf, iedereen in de kamer knikt.

Maar die demo verbergt het enige cijfer dat ertoe doet in finance: wat er gebeurt met de gevallen die fout gingen.

Een model voor factuurverwerking dat 95 procent van de tijd goed zit, klinkt als een sterk resultaat. In een classificatiebenchmark is dat ook zo. In een grootboek is het een langzaam lek. Want die 5 procent kondigt zich niet aan. Het ziet er precies hetzelfde uit als de 95 procent: een ingevuld veld, een plausibele rekening, een boeking die moeiteloos door de controle komt omdat niets eraan vreemd oogt.

Een agent die 95 procent van de tijd goed gokt, zet nog steeds zo'n 35 foute regels per maand in jouw grootboek, bij 713 facturen. Wij bouwen liever een agent die zegt: deze zeven, dat weet ik niet.

Vijfendertig foute regels per maand is 420 per jaar. Verspreid over elf administraties, waarvan geen enkele op zichzelf groot genoeg is om een alarm af te laten gaan. Je vindt ze bij de jaarafsluiting, of je accountant vindt ze, of je vindt ze nooit en je kostenplaatsrapportage klopt al drie kwartalen stilletjes niet.

Zeven open velden met een reden erbij is een klusje van tien minuten op een dinsdagochtend.

Ontwerpkeuze één: het stelt op, het tekent nooit

De agent maakt concepten. Hij keurt nooit goed en betaalt nooit. Dat staat in het contract dat we met de klant hebben getekend, niet in een instellingenscherm waar een toekomstige beheerder het voor het gemak kan omzetten.

Dit weegt zwaarder dan het klinkt. Op het moment dat een automation zijn eigen werk kan goedkeuren, heb je de laatste plek weggehaald waar een mens een getal leest voordat er geld beweegt. En de druk om die knop om te zetten komt altijd later, altijd vanuit een goede bedoeling: de concepten stapelen zich op, de kwaliteit is duidelijk prima, iemand is op vakantie.

Daarom hebben we het structureel onmogelijk gemaakt. De agent heeft schrijftoegang tot conceptboekingen. Hij heeft geen bevoegdheid om goed te keuren. Niet omdat we het model wantrouwen, maar omdat degene die akkoord geeft op uitgaven, ook degene moet zijn die daarvoor verantwoordelijk is. Automation moet het werk vóór die handtekening comprimeren, niet de handtekening wegnemen.

Bovendien is dit wat het geheel adopteerbaar maakt. Een controller laat een agent 713 boekingen voorbereiden. Geen enkele controller laat een agent 713 facturen betalen, en terecht.

Ontwerpkeuze twee: onbekend is niet nul

Dit is de ruggengraat van de build.

Als de agent niet zeker is van de kostenplaats, laat hij de kostenplaats leeg. Kan hij de btw-behandeling niet met zekerheid bepalen, dan laat hij de btw-code leeg. In beide gevallen voegt hij een korte reden toe: nieuwe leverancier zonder boekingshistorie, factuurregel beslaat twee entiteiten, btw-vermelding op het document wijkt af van de gebruikelijke behandeling van de leverancier.

Hij vult niet de meest waarschijnlijke waarde in.

De meeste systemen doen het tegenovergestelde, omdat een volledig ingevuld record afgerond aanvoelt en een leeg veld als een mislukking voelt. Maar een leeg veld wordt opgemerkt door een mens. Een plausibele foute waarde niet. Die asymmetrie is het hele spel. Jouw controleproces is afgestemd op het opsporen van gaten, niet op het opnieuw controleren van zelfverzekerde antwoorden.

Dus de output van de agent is niet "713 boekingen, klaar". Het is "706 complete concepten, 7 met open velden en hier is waarom". Het menselijke werk verschuift van alles controleren naar uitzonderingen oplossen, en dat is de enige versie hiervan die daadwerkelijk tijd bespaart in plaats van verplaatst.

Elke boeking draagt zijn eigen onderbouwing

Elk concept legt vast waarom het zo geboekt is: welke leveranciersregel van toepassing was, met welke historische boekingen het is vergeleken, aan welke entiteit het is toegewezen en op welke basis. Geen confidence-score. Een auditregel die een controller kan lezen.

Want "het systeem heeft het gedaan" is geen antwoord dat je aan je accountant kunt geven, en het is geen antwoord waarmee iemand de regels kan verbeteren. Als je een boeking niet kunt herleiden tot de regel die hem heeft gegenereerd, kun je de regel niet repareren. Je kunt alleen eindeloos, factuur voor factuur, discussiëren over de output. Dit is hetzelfde faalpatroon als een zwakke architectuur achter een sterk model: de intelligentie is prima, de structuur eromheen maakt het onbruikbaar.

Ontwerpkeuze drie: het leert, maar pas voorbij een quorum

Zelflerend vermogen is de feature die iedereen vraagt en bijna niemand scherp afbakent. De pitch is voor de hand liggend: corrigeer het één keer, en het maakt die fout nooit meer. Efficiënt. Maar ook gevaarlijk, in een administratie met elf entiteiten.

Want één correctie is geen kennis. Het kan een eenmalig geval zijn. Het kan zijn dat iemand haastig iets op de verkeerde kostenplaats boekte. Het kan een tijdelijke afspraak zijn die voor één project geldt en verder nergens. Promoveer dat tot regel en je hebt de agent niets geleerd. Je hebt de uitzondering van één persoon beleid laten worden over elf administraties heen.

Dus stelden we een quorum in. Een correctie wordt pas een regel als twee verschillende mensen dezelfde correctie maken, of als één persoon dezelfde correctie drie keer maakt. Alles onder die drempel wordt vastgelegd als signaal, niet als regel. Het wacht.

Bovendien verlopen regels. Een geleerde regel heeft een levensduur van 60 dagen. Bevestigt niemand hem binnen die periode opnieuw, dan valt hij weg en gaat de agent weer vragen stellen. Leveranciers veranderen, contracten veranderen, projecten eindigen. Een regel die in maart is geleerd, mag niet in november stilletjes jouw boekingen blijven sturen omdat niemand eraan dacht om te controleren.

En er is één schakelaar die het leren volledig uitzet zonder de agent uit te schakelen. Maandafsluiting, een audit, een migratie, een periode waarin je het gedrag wilt bevriezen: omzetten. De agent blijft concepten opstellen op basis van de regels die hij heeft en stopt met het overnemen van nieuwe. Die schakelaar bestaat omdat "we moeten het leren stopzetten" nooit zou moeten betekenen dat je de automation offline haalt.

Zelflerend vermogen zonder quorum is geen agent die slimmer wordt. Het is een agent die zijn eigen fouten verankert, steeds sneller, met elke correctie die hij verkeerd leest als een les.

Zeven vragen voor jouw eigen factuurautomation

Als je al inkoopfacturen automatiseert, of een leverancier staat op het punt het je te verkopen, loop dit door. De antwoorden vertellen meer dan welk accuraatheidspercentage dan ook op een slide.

• Jouw automation stopt bij een concept dat een mens moet aftekenen, en kan niet zelfstandig goedkeuren of betalen
• Als het niet zeker is van een veld, laat het dat veld leeg met een reden in plaats van de beste gok in te vullen
• Elke boeking is te herleiden tot de specifieke regel of historie die hem heeft geproduceerd, zonder dat je het systeem op zijn woord hoeft te geloven
• Een correctie verandert gedrag pas voorbij een vastgestelde drempel, en je weet hoeveel mensen en hoeveel herhalingen daarvoor nodig zijn
• Geleerde regels verlopen vanzelf als niemand ze opnieuw bevestigt, in plaats van te blijven bestaan tot iemand merkt dat ze fout zijn
• Er is één schakelaar die het leren van de agent stopt zonder de automation uit te schakelen
• Je kent de dagelijkse API-limiet van je boekhoudplatform en hoe dicht jouw automation daar op piekmomenten tegenaan zit

Twee of meer niet aangevinkt is een ontwerpgat, geen afstemmingskwestie. Zijn de eerste twee niet aangevinkt, dan heb je geen factuurautomation. Dan heb je een onbewaakte boekhouder zonder verantwoordelijkheid en een heel goed geheugen voor zijn eigen fouten.

Dit gaat niet over Exact Online

We hebben dit gebouwd op Exact Online, en de API-limieten bepaalden de batching, de retry-logica en het tempo waarin de agent zich door elf administraties beweegt. Dat deel is echt engineeringwerk en het doet ertoe bij 713 facturen per maand.

Maar niets van bovenstaande logica is gebonden aan Exact. Alleen-concept-rechten, leeg-boven-gok, herleidbare boekingen, quorum-gebaseerd leren, verlopende regels: elk boekhoudpakket met een fatsoenlijke API kan dat dragen. De integratie is de makkelijke helft.

De moeilijke helft is het vastleggen van de eigen boekingsregels van de klant. Welke leverancier naar welke rekening in welke entiteit gaat. Hoe intercompany-regels worden gesplitst. Welke kostenplaatsen projectgebonden zijn en welke permanent. Wanneer een btw-behandeling afwijkt en waarom. Die kennis zit in de hoofden van twee mensen en een spreadsheet die niemand sinds 2022 heeft bijgewerkt, en die eruit halen is het grootste deel van het project.

Dat is ook waarom "er gewoon een AI tegenaan gooien" hier nooit werkt. Er is geen model dat jouw boekingsregels kent. Er is alleen het werk om ze voor het eerst goed op papier te zetten.

The ODB Way

We beginnen niet met de vraag wat de agent kan automatiseren. We beginnen met de vraag waar het moet stoppen, wie tekent, en wat er gebeurt met de gevallen die fout gaan. Daarna bouwen we naar binnen toe.

In de praktijk betekent dat: het echte proces in kaart brengen voordat we een API aanraken, de werkelijke boekingsregels van de klant vastleggen in plaats van generieke best practices, en iets opleveren dat elke dag in productie draait in plaats van een pilot die één keer indruk maakt. De weigeringen horen bij de specificatie, het is geen beperking die in versie twee verdwijnt.

Wil je het bredere argument lezen voor waarom automation acties en beslissingen moet opleveren in plaats van antwoorden, lees dan waarom jouw AI actie moet aanjagen. En vraag je je af waarom zoveel finance- en back-office-pilots er geweldig uitzien in een demo en vervolgens vastlopen, dan behandelt de vier plekken waar AI-pilots stilletjes sterven de meeste redenen die wij tegenkomen.