AI die in het grootboek boekt, heeft een vast protocol nodig

De functie was kort en goed bedoeld. In een groep met elf entiteiten boekte een automatisering de journaalposten die uit bankafschriften en intercompany doorbelastingen voortkomen: bankkosten, koersverschillen op ontvangsten in vreemde valuta, de maandelijkse doorbelasting van gedeelde IT- en financediensten aan elke dochter. De functie draaide telkens als het systeem merkte dat een van zijn eigen boekingen niet klopte, bijvoorbeeld bankkosten in de verkeerde entiteit. Ze verwijderde de boeking en boekte een gecorrigeerde versie. Het ERP stond dat toe voor niet-afgestemde journaalposten in een open periode, dus niets hield haar tegen.

Halverwege een maand spraken de groepsmaatschappijen een nieuwe verdeelsleutel voor de doorbelastingen af, een gewone aanpassing nadat personeel tussen twee dochters was verschoven. De functie zag elke doorbelasting die die maand al was geboekt als fout. Ze verwijderde ze een voor een en boekte ze opnieuw met de nieuwe verdeling, in negen entiteiten. De grootboeken klopten daarna. Hoe ze zover waren gekomen, was niet meer na te gaan, en het kostte group finance weken geduldig uitzoekwerk om vast te stellen welke boekingen waren herschreven. De functie werd uitgezet voordat iemand kon vragen wat ze nog meer mocht verwijderen.

Bij automatisering in finance gaat de meeste aandacht naar het matchen van bankregels. Maar bij het schrijven in het grootboek zitten de beheersmaatregelen, en daarvoor is een protocol nodig, niet alleen een koppeling. Hoe beter het matchen wordt, hoe zwaarder dit weegt. Als de meeste afschriftregels zonder medewerker worden gematcht, komen de meeste boekingen die eruit voortkomen in het grootboek zonder dat iemand ze eerst heeft bekeken, en dan zijn de regels voor het schrijven de beheersmaatregel.

Fouten van de automatisering volgen het gewone correctieproces

Eén regel gaat voor alles. Maakt de automatisering een fout in het grootboek, dan wordt die gecorrigeerd door dezelfde mensen en via hetzelfde proces als een menselijke fout: een storno of correctieboeking, aangemaakt door het financeteam, met een reden en een fiatteur. Nooit door het systeem zelf, en nooit door iets te verwijderen.

Pat Helland zei in 2007 hetzelfde tegen databaseontwikkelaars, in een essay met de titel "Accountants Don't Use Erasers". Een grootboek groeit alleen. Een boeking wordt gecorrigeerd door er een toe te voegen die de eerste verklaart. Die functie deed het omgekeerde: ze verving de boeking en liet geen spoor van de eerste achter. Ontwikkelaars van eventlogs hebben het idee van een register dat alleen groeit van de boekhouding geleend. Automatisering die in een echt grootboek schrijft, moet het teruggeven.

Dat is geen voorzichtigheid om de voorzichtigheid. Het correctieproces is het deel van finance dat de accountant al toetst en waar de controller al op vertrouwt. Een automatisering die haar eigen boekingen herstelt, heeft een tweede correctieproces gecreëerd, zonder documentatie en zonder functiescheiding. Haar rechten in het ERP sluiten daarom uit dat ze journaalposten die ze zelf heeft geboekt verwijdert, parkeert of wijzigt. Zo blijft de regel overeind, ook als er een fout in de code zit.

De regel heeft een prijs, en het financeteam merkt die als eerste. Betekent een nieuwe verdeelsleutel dat elke doorbelasting van de maand in negen entiteiten moet veranderen, dan is terugdraaien met de hand een saai klusje, en iemand vraagt altijd waarom het systeem zijn eigen werk niet kan terugdraaien. Ons antwoord: het systeem bereidt de storno's en de nieuwe boekingen voor, met de reden en de betrokken boekingen erbij, en een medewerker boekt ze als één gefiatteerde batch per entiteit. Het werk krimpt tot een beoordeling. De beheersmaatregel blijft waar de accountant hem verwacht.

Elke boeking doorloopt vijf stappen

Een zakelijke sleutel, geen request-ID. Elke boeking krijgt een sleutel die is afgeleid van wat er zakelijk wordt geboekt. Voor bankkosten zijn dat de entiteit, de bankrekening, het afschriftnummer en de plaats van de regel op het afschrift. Voor een doorbelasting zijn dat de belastende entiteit, de ontvangende entiteit, de dienstenovereenkomst en de periode. De sleutel wordt alleen opgebouwd uit velden die het ERP al bijhoudt, zoals afgesproken met finance en IT, zodat het ERP er zelf naar gevraagd kan worden: in SAP staat hij in de referentie in de documentkop, in Dynamics 365 Business Central in het externe documentnummer. Dezelfde afschriftregel levert altijd dezelfde sleutel op, hoe vaak de workflow ook opnieuw start of een poging herhaalt. Het engineeringteam van Stripe beschreef in 2017 hoe idempotency keys werken bij betaal-API's. Binnen een ERP draait het vooral om de vraag waar de sleutel vandaan komt. Een sleutel die per request wordt aangemaakt, beschermt tegen een dubbel request. Alleen een zakelijke sleutel beschermt ertegen dat de workflow twee keer hetzelfde besluit neemt.

De keuze van de velden is een afweging, en finance hoort die bewust te maken. Zit het afschriftnummer in de sleutel, dan levert een bank die een gecorrigeerd afschrift onder een nieuw nummer stuurt nieuwe sleutels op voor dezelfde kosten, en zou de zakelijke sleutel alleen beide reeksen doorlaten. Zit het er niet in, dan houden twee echte kostenposten met hetzelfde bedrag op dezelfde dag elkaar tegen, en dat komt op een drukke rekening voortdurend voor. Wij nemen het afschriftnummer op en vertrouwen erop dat de dubbelcontrole verderop het gecorrigeerde afschrift vangt. De sleutel voorkomt dat de workflow zichzelf herhaalt. De tweede controle voorkomt dat de buitenwereld zichzelf herhaalt.

Eerst controleren, dan schrijven. De workflow vraagt het ERP of er al een journaalpost met deze sleutel bestaat, en gaat uit van het antwoord van het ERP, niet van zijn eigen geheugen. Deze stap maakt time-outs onschadelijk. Loopt een boekingsaanroep in een time-out, dan weet de workflow niet of de journaalpost is aangemaakt. Hij gokt niet en probeert het niet gewoon opnieuw. De volgende poging begint met de controle, vindt de journaalpost wel of niet, en gaat vanaf daar verder.

Controleer de periode. Is de doelperiode gesloten, of valt de boeking binnen een cut-offperiode die de controller heeft vastgesteld, dan wordt er niets geboekt en gaat het geval met een voorgestelde datum naar een medewerker. De keuze van de boekingsperiode is een oordeel over de jaarrekening, en dat oordeel is niet aan de automatisering.

Schrijf via de vaste ingang. Boekingen lopen via de standaardinterfaces van het ERP, zodat de validaties, nummering, btw-logica en autorisaties van het ERP van toepassing zijn. Nooit rechtstreeks in de tabellen.

Lees terug en leg vast. Na het boeken leest de workflow de journaalpost terug en legt hij het documentnummer uit het ERP bij het geval vast. Pas dan is de stap afgerond.

Elk boekingstype valt onder een bestaande beheersmaatregel

Elke financeafdeling die een accountantscontrole krijgt, heeft een stelsel van interne beheersing: key controls, elk met een eigenaar en een toets die de accountant jaarlijks uitvoert. De snelste manier om geautomatiseerde boekingen acceptabel te maken, is niet om er nieuwe maatregelen voor te bedenken. Het is om elk boekingstype onder te brengen bij een maatregel die al wordt getoetst.

Voor de livegang maken we die koppeling samen met de groepscontroller en de eigenaar van de interne beheersing. Boekingen van bankkosten vallen onder de bestaande maatregel voor de bankafstemming. Koersverschillen vallen onder de beoordeling van de valutaherwaardering bij de maandafsluiting. Intercompany doorbelastingen vallen onder de goedkeuring van de dienstenovereenkomsten en de intercompany afstemming die al voor de consolidatie draait. De nettingbetalingen die de doorbelastingen verrekenen, vallen onder de betaalvrijgave, met dezelfde functiescheiding als voorheen. Per boekingstype leggen we vast wat de automatisering binnen de maatregel doet en welk bewijs ze achterlaat voor de toets.

Past er geen bestaande maatregel, dan is dat op zich al een bevinding. De automatisering doet dan iets wat finance nooit met de hand heeft gedaan, en daar hoort een besluit van de eigenaar van de maatregel bij, geen slimme omweg. De workflow boekt in elke entiteit onder een eigen, herkenbaar serviceaccount, zodat de accountant zijn boekingen kan steekproeven met dezelfde werkwijze die hij al gebruikt voor boekingen van medewerkers.

Tegen dubbele betalingen staat een tweede, onafhankelijke controle

Dubbele bankkosten zijn vervelend. Een dubbele doorbelasting is iets anders: die stroomt mee in de maandelijkse netting en wordt geld dat tussen twee entiteiten beweegt, vaak over een grens heen. Terugdraaien betekent dan een tweede betaling en een gesprek over belastingen.

Kenmerken van doorbelastingen zijn slechte identificatoren. Dezelfde post komt terug als correctie, als afrekening aan het eind van het kwartaal, of met de periode op drie verschillende manieren geschreven. Voor de nettingrun zoekt een aparte controle daarom naar mogelijke dubbelingen: hetzelfde paar entiteiten, dezelfde dienst, dezelfde of een aangrenzende periode, een vergelijkbaar bedrag. Aan de bankkant zoekt ze over alle afschriften heen naar dezelfde rekening, hetzelfde bedrag, dezelfde valutadatum en dezelfde transactiecode. Treffers gaan naar een medewerker, ook als de zakelijke sleutel zegt dat de boeking nieuw is. De controles van het ERP zelf zijn voor ons nooit de enige verdediging. Ze helpen, en ze zijn gebouwd voor een andere vraag. Een afschriftimport weigert meestal een afschriftnummer dat hij al kent, en precies daarom komt een gecorrigeerd afschrift onder een nieuw nummer erdoor. Waar het ERP een controle de boeking laat blokkeren in plaats van waarschuwen, zetten we hem op blokkeren, want een waarschuwing aan een serviceaccount leest niemand.

Voor betaalbestanden geldt een eigen regel. Elke gefiatteerde nettingbatch levert precies één bestand op, met een kenmerk dat wordt vastgelegd voordat het bestand de deur uitgaat. Mislukt de verzending of is de status onduidelijk, dan verstuurt het systeem het bestand nooit opnieuw. Een medewerker controleert de status bij de bank en beslist. Opnieuw versturen is de enige herhaalpoging die echt geld kan kosten, en de controle kost een paar minuten.

Het systeem stemt elke dag zijn eigen acties af

Eén keer per dag vergelijkt een apart proces wat de workflow denkt te hebben geschreven met wat er in het ERP en bij de bank staat. Elke ontvangen afschriftregel hoort een geval te hebben. Elk afgerond geval hoort precies één journaalpost te hebben. Elke journaalpost met de referentie van de workflow hoort bij een geval. Elke doorbelasting in de belastende entiteit hoort haar tegenhanger te hebben in de ontvangende. Elke betaling in een nettingbestand hoort precies één keer in de bevestiging van de bank voor te komen. Verschillen worden uitzonderingen voor het financeteam, met het bewijs erbij.

Het engineeringteam van Stripe beschreef de structurele versie van deze controle in zijn post over Ledger (februari 2024): als een geldstroom is afgerond, moeten de tussenrekeningen waar hij doorheen liep weer op nul staan, dus één zoekvraag naar tussenrekeningen met een saldo vindt elke gebroken stroom, wat er ook misging. De grootboeken van een groep hebben die rekeningen al. De banktussenrekeningen horen leeg te lopen naarmate afschriftregels worden geboekt, en de intercompany tussenrekeningen naarmate de netting verrekent. De dagelijkse job toont daarom ook de openstaande posten op die rekeningen die ouder zijn dan het afgesproken venster, gegroepeerd per paar entiteiten. Een achtergebleven post daar is vaak het eerste teken van een boeking die twee keer of helemaal niet is gebeurd.

Deze job meldt vrijwel nooit iets, en zo hoort het ook. Meldt hij wel iets, dan vindt hij het probleem voordat de maandafsluiting het vindt. Tegelijk beantwoordt hij de vraag van de accountant over geautomatiseerde boekingen: dit is elke actie die het systeem heeft uitgevoerd, en dit is het bewijs dat elke actie precies één keer heeft plaatsgevonden.

Geef het systeem geen manier om de geschiedenis te herschrijven

Een financeteam beoordeelt automatisering niet op hoe goed ze een bankafschrift leest, maar op de vraag of elke boeking in het grootboek te verklaren is. Een automatisering die alleen kan toevoegen, en waarvan de fouten worden gecorrigeerd zoals menselijke fouten altijd al werden gecorrigeerd, is altijd te verklaren.