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

De functie was kort en goed bedoeld. Ze hoorde bij een automatisering die voor een groep van elf bedrijven boekingen in de administratie (het grootboek) vastlegde: bankkosten, koersverschillen op betalingen in vreemde valuta en de maandelijkse doorbelasting van gedeelde IT- en financediensten aan elke dochter. Vond het systeem een van zijn eigen boekingen fout, bijvoorbeeld kosten bij het verkeerde bedrijf, dan verwijderde de functie die en boekte een gecorrigeerde versie. Het ERP, het centrale bedrijfssysteem van de groep, stond dat toe zolang de maand open was. Niets hield haar tegen.

Halverwege een maand sprak de groep een nieuwe formule af voor het verdelen van de doorbelastingen, 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 bedrijven. De cijfers klopten daarna. Hoe ze zover kwamen, was weg; group finance had weken nodig om uit te zoeken 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 matchen: welke bankregel hoort bij welke openstaande factuur. Maar zodra de meeste regels zonder medewerker worden gematcht, komen de boekingen die eruit voortkomen in de administratie zonder dat iemand ernaar heeft gekeken. De regels voor het schrijven, een protocol, worden dan zelf de controle.

Fouten van de automatisering volgen het menselijke correctieproces

De regel onder al het andere: maakt de automatisering een fout in de administratie, dan corrigeren dezelfde mensen en hetzelfde proces die menselijke fouten corrigeren die. Een correctieboeking, aangemaakt door het financeteam, met een reden en een goedkeurder. Het systeem herstelt zijn eigen boekingen niet en verwijdert nooit.

Pat Helland legde dit in 2007 uit aan databaseontwikkelaars, in een essay met de titel "Accountants Don't Use Erasers": een grootboek groeit alleen. Het correctieproces is het deel van finance dat de accountant al toetst. Een automatisering die zichzelf corrigeert, heeft stilletjes een tweede gebouwd, zonder documentatie en zonder goedkeuring. Daarom mist ze in het ERP de rechten om iets te verwijderen of te wijzigen dat ze zelf heeft geboekt, en blijft de regel overeind, ook op de dag dat de code fout is.

Een maand doorbelastingen in negen bedrijven met de hand terugdraaien is saai. Dus bereidt het systeem de storno's en nieuwe boekingen voor, met de reden erbij, en een medewerker keurt ze goed als één batch per bedrijf. Typwerk wordt een beoordeling, en de controle blijft waar de accountant hem verwacht.

Elke boeking doorloopt vijf stappen

Eerst de sleutel. Elke boeking krijgt een sleutel uit de zakelijke gegevens van wat er wordt geboekt. Voor bankkosten: het bedrijf, de bankrekening, het afschriftnummer en de plaats van de regel daarop. Voor een doorbelasting: verzendend bedrijf, ontvangend bedrijf, dienstenovereenkomst en maand. We gebruiken alleen velden die het ERP al bijhoudt. Hoe vaak de workflow het ook opnieuw probeert, dezelfde bankregel geeft dezelfde sleutel, dus wordt hij nooit dubbel geboekt.

De keuze van de velden is een afweging voor finance. Met het afschriftnummer erin levert een gecorrigeerd afschrift van de bank onder een nieuw nummer nieuwe sleutels op voor dezelfde kosten; zonder houden twee echte kostenposten van hetzelfde bedrag op één dag elkaar tegen. Wij lieten het erin, en de controle op dubbelingen hieronder vangt gecorrigeerde afschriften.

Ten tweede: kijken voor het schrijven. De workflow vraagt het ERP of er al een boeking met deze sleutel bestaat, en gelooft het ERP boven zijn eigen geheugen. Bij een time-out gokt hij niet; de volgende poging begint met de controle.

Ten derde: de maand. Is die afgesloten, of valt hij binnen een afsluitvenster dat de controller heeft gezet, dan wordt er niets geboekt; het geval gaat met een voorgestelde datum naar een medewerker. In welke maand een boeking valt, is een oordeel over de jaarrekening, en dat is niet aan de automatisering.

Ten vierde: de voordeur, de standaardinterfaces van het ERP, zodat de eigen controles, nummering, btw-logica en rechten van het ERP gelden. Nooit rechtstreeks in de database.

Ten vijfde: teruglezen en het documentnummer van het ERP bij het geval opslaan. Pas dan is de stap klaar.

Elk boekingstype valt onder een controle die al bestaat

Elke financeafdeling met een accountantscontrole heeft een reeks kerncontroles, elk met een eigenaar en een jaarlijkse toets. De snelste weg naar acceptatie door de accountant was geen nieuwe controles bedenken en elk boekingstype onder een al geteste te plaatsen.

Voor de livegang maken we die koppeling daarom met de groepscontroller en de eigenaar van de controles. Hier vielen bankkosten onder de bestaande controle of bank en boeken overeenkomen, koersverschillen onder de beoordeling bij het maandeinde, en doorbelastingen onder de goedkeuring van dienstenovereenkomsten en de controle of de bedrijven in de groep het eens zijn over wat ze elkaar verschuldigd zijn. Per type leggen we vast wat de automatisering doet en welk bewijs ze achterlaat voor de toets.

Past er niets, dan beslist de eigenaar van de controle. De workflow boekt bovendien onder een eigen, herkenbaar account, zodat de accountant zijn boekingen kan steekproeven zoals die van mensen.

Tegen dubbele betalingen staat een tweede, onafhankelijke controle

Een dubbel geboekte doorbelasting wordt geld dat tussen twee bedrijven beweegt, vaak over een grens, en terughalen betekent een tweede betaling en een gesprek met de belastingafdeling. Voor elke betaalrun zoekt een aparte controle daarom naar bijna-dubbelingen: dezelfde twee bedrijven, dezelfde dienst, dezelfde of volgende maand, een vergelijkbaar bedrag. Aan de bankkant vergelijkt ze rekening, bedrag, datum en transactiecode over afschriften heen. Wat ze vindt, gaat naar een medewerker, ook als de sleutel zegt dat de boeking nieuw is.

De eigen controles van het ERP helpen, maar een afschriftimport weigert alleen een afschriftnummer dat hij al kent, dus komt een gecorrigeerd afschrift onder een nieuw nummer erdoor. Waar het ERP kan blokkeren in plaats van waarschuwen, zetten we het op blokkeren. Een waarschuwing aan een geautomatiseerd account leest niemand.

Elke goedgekeurde betaalbatch levert precies één bestand op, vastgelegd voordat het de deur uitgaat. Mislukt de verzending of is de status onduidelijk, dan verstuurt het systeem niet opnieuw; een medewerker zoekt het uit met de bank.

Het systeem controleert dagelijks zijn eigen werk

Eén keer per dag vergelijkt een apart proces wat de workflow denkt te hebben geschreven met wat het ERP en de bank echt bevatten: bankregels zonder geval, gevallen zonder boeking of met twee, doorbelastingen die de verzender wel heeft geboekt en de ontvanger niet, betalingen die niet precies één keer in de bevestiging van de bank staan. Wat niet klopt, gaat met het bewijs naar finance.

De ontwikkelaars van Stripe beschreven in februari 2024 een structurele versie in een post over hun Ledger-systeem: geld dat door een tussenrekening loopt, hoort die op nul achter te laten, dus elke tussenrekening met een restsaldo wijst op een gebroken stroom. De dagelijkse job toont posten die langer dan afgesproken op de tussenrekeningen van de groep staan, vaak het eerste teken dat iets dubbel of helemaal niet is geboekt.

Meestal meldt hij niets. Anders vindt hij het probleem meestal een of twee weken voor de maandafsluiting.

Geef het systeem geen manier om de geschiedenis te herschrijven

Financeteams beoordelen een automatisering op de vraag of ze elke boeking in de administratie kunnen verklaren. Een automatisering die alleen kan toevoegen, en waarvan de fouten worden gecorrigeerd zoals die van mensen altijd al, blijft verklaarbaar.