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

De functie was kort en goed bedoeld. Ze zat in een factuurautomatisering die een klant van een andere leverancier had overgenomen, en draaide telkens als het systeem merkte dat een van zijn eigen boekingen niet klopte, bijvoorbeeld door een verkeerde kostenplaats. Ze verwijderde de boeking en boekte een gecorrigeerde versie. Het ERP stond dat toe voor onbetaalde documenten in een open periode, dus niets hield haar tegen.

Het grootboek dat overbleef, klopte. Maar hoe het zover was gekomen, was niet meer na te gaan. Boekingen waren verschenen en weer verdwenen zonder enig spoor van de reden, en het financeteam was weken bezig om te achterhalen welke boekingen waren herschreven. De functie werd uitgezet voordat iemand kon vragen wat ze nog meer kon verwijderen.

Bij automatisering in finance gaat de meeste aandacht naar het lezen van documenten. Maar het vertrouwen wordt gewonnen of verloren bij het schrijven in het grootboek, en daarvoor is een protocol nodig, niet alleen een koppeling.

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.

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 documenten die ze zelf heeft geboekt verwijdert, parkeert of wijzigt. Zo blijft de regel overeind, ook als er een fout in de code zit.

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: bedrijfscode, leverancier, factuurnummer van de leverancier en bedrag. Die sleutel staat in een referentieveld dat het ERP al heeft, zoals afgesproken met finance en IT. Dezelfde factuur 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.

Eerst controleren, dan schrijven. De workflow vraagt het ERP of er al een document met deze sleutel bestaat, en gaat uit van het antwoord van het ERP, niet van zijn eigen geheugen.

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 het document 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 controller en de eigenaar van de interne beheersing. Boekingen van inkoopfacturen vallen onder de bestaande maatregelen voor three-way match en fiattering. Voorstellen voor transitorische posten vallen onder de beoordeling van transitoria bij de maandafsluiting. Betaalvoorstellen 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 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

Een dubbele boeking is vervelend. Een dubbele betaling is geld dat het bedrijf verlaat.

Factuurnummers van leveranciers zijn slechte kenmerken. Dezelfde factuur komt binnen als INV-0042, 42 en 0042, of duikt maanden later weer op als herinnering met een nieuwe scan. Voordat een betaling wordt vrijgegeven, zoekt een aparte controle daarom naar mogelijke dubbelingen: dezelfde leverancier, een vergelijkbaar bedrag, een vergelijkbare datum en factuurnummers die gelijk zijn zodra voorvoegsels, voorloopnullen en leestekens zijn weggehaald. Treffers gaan naar een medewerker, ook als de zakelijke sleutel zegt dat de factuur nieuw is. De dubbelcontroles van de bank of de waarschuwing in het ERP zijn voor ons nooit de enige verdediging. Beide helpen, en bij beide hebben we in de praktijk gaten gezien.

Voor betaalbestanden geldt een eigen regel. Elke gefiatteerde batch 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. Elk afgerond geval hoort precies één document te hebben. Elk document met de referentie van de workflow hoort bij een geval. Elke betaling in een bestand hoort precies één keer in de bevestiging van de bank voor te komen. Verschillen worden uitzonderingen voor het financeteam, met het bewijs erbij.

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 pdf 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.