Elk boekhoudpakket dat iets van automatisatie belooft, heeft ergens een scherm met regels. Als de leverancier Proximus is, boek op 613400. Als de omschrijving "brandstof" bevat, boek op 612100. In een dossier dat een paar jaar meedraait staan daar al snel enkele honderden lijnen. Niemand weet nog precies waarom die ene regel uit 2021 er staat. Niemand durft ze weg te doen.

En tóch zit er elke maand handwerk in datzelfde dossier.

Dat is niet omdat de regels slecht opgesteld zijn. Het is omdat een regelmotor per definitie vastloopt op het punt waar boekhouden interessant wordt.

Waarom rule-based automatisatie plafonneert

Regels zijn uitstekend in het frequente en waardeloos in het uitzonderlijke. Het gros van een dossier automatiseer je op een namiddag: de vaste leveranciers, de terugkerende kosten, het abonnement dat elke maand hetzelfde bedrag op dezelfde rekening zet.

De rest is het probleem. Die bestaat niet uit één patroon dat je nog niet gevat hebt. Het zijn duizend eenmalige gevallen die elk hun eigen regel zouden vragen. De leverancier die één keer per jaar factureert. De factuur waar drie soorten kosten door elkaar staan. Het contract dat over twee boekjaren loopt. Om die te vangen zou je een regel moeten schrijven die je daarna nooit meer gebruikt.

Er is een tweede, stillere kost. Regels zijn broos. Een leverancier verandert zijn factuurlay-out of zijn omschrijvingen, en de regel vuurt gewoon niet meer. Hij geeft geen fout, hij doet niets. Je merkt het pas als iemand de balans nakijkt.

De diepere reden is dat een regel niet weet wat een factuur bedoelt. Hij weet alleen wat er letterlijk staat. Hij kan matchen, niet begrijpen. En elke uitzondering die je erbij schrijft, maakt het geheel iets moeilijker te onderhouden, tot het punt waarop het onderhoud van de regels evenveel tijd kost als het werk dat ze uitsparen.

Wat er wél veranderd is

Een model dat een factuur leest, doet iets anders dan matchen. Het krijgt de factuur zelf te zien: het document, niet enkel de uitgelezen velden. Daarnaast krijgt het de context die een ervaren boekhouder ook zou hebben. Het volledige rekeningschema van dit dossier, wat er in dit dossier historisch met deze leverancier en met dit soort lijnen gebeurd is, het btw-regime, en de rekeningstandaard van het land waarin geboekt wordt, of dat nu het Belgische MAR is, het Nederlandse RGS of een UK chart of accounts.

En het werkt per lijn, niet per factuur. Een factuur met software, hardware en transportkosten op drie lijnen wordt ook op drie rekeningen geboekt, zonder dat iemand daar een regel voor bedacht heeft.

Het tweede verschil valt minder op maar weegt zwaarder: het gaat niet enkel over de grootboekrekening. In de praktijk kon een regelmotor één ding fatsoenlijk: een rekening koppelen aan een leverancier. Een boeking bestaat uit veel meer. De btw-code, het dagboek, de betalingsvoorwaarde, de betaalwijze, de analytische verdeling over mogelijk meerdere plannen, de boekingsperiode, de overlopende rekeningen bij contracten die over de jaargrens lopen, en de boekingsomschrijving. Dat zijn de velden waar in de praktijk de tijd in kruipt, en precies de velden waarvoor bijna niemand ooit regels heeft geschreven, omdat het niet te doen was.

De laatste 10%: van mechaniek naar beleid

Betekent dit dat regels weg zijn? Nee. Er blijft een rest die geen enkel model uit een factuur kan afleiden, om de eenvoudige reden dat het er niet in staat: jullie afspraken.

Dat alle cloudsoftware bij jullie op één rekening gaat, ook wanneer de leverancier er hardware bij factureert. Dat je bij deze ene leverancier Recupel apart wil zien. Dat een bepaalde kostensoort altijd naar een specifiek analytisch plan moet. Dat is geen boekhoudkundige waarheid, dat is huisstijl.

Die rest is verrassend precies te meten. In de tien actiefste dossiers op ons platform ging 89% van de inkomende facturen zonder tussenkomst door de boeking. Wat overblijft is dus geen twintig of dertig procent handwerk. Het is ongeveer één factuur op tien.

Maar de vorm van die regels is fundamenteel veranderd, en dat is het punt van dit hele verhaal.

Vroeger was een regel mechaniek: een conditie en een gevolg, die je in de taal van het systeem moest gieten. Als veld X bevat waarde Y, zet dan veld Z.

Nu is een regel beleid, geschreven in gewone taal. Eén zin, op het niveau van de organisatie of van één specifieke leverancier. Die zin gaat mee als context wanneer de factuur geboekt wordt.

Het verschil is niet cosmetisch. Een regel die niet exact matcht, doet niets. Een instructie die niet exact past, wordt geïnterpreteerd. Schrijf je "software boeken we op 613500", dan geldt dat ook voor de licentie die de leverancier "subscription fee" noemt. Bij een regelmotor had je die tweede omschrijving zelf moeten voorzien.

Het gevolg is dat het aantal regels instort. Niet honderden condities, maar een handvol zinnen die samen jullie boekhoudbeleid beschrijven, en die een nieuwe collega gewoon kan lezen.

Wat er niet aan AI overgelaten wordt

Bij een boekhoudpubliek is dit de vraag die telt, dus laat ons ze rechtstreeks beantwoorden: het model mag interpreteren, maar het mag niet zomaar iets doen.

Het kan alleen rekeningen kiezen die in dat dossier bestaan. Een verzonnen rekeningnummer haalt de boeking niet. Rekeningen die je uitsluit, zijn hard uitgesloten en worden ook genegeerd wanneer ze in de historiek opduiken. Btw-code en grootboekrekening worden tegen elkaar afgetoetst; bij een tegenstrijdigheid gaat het voorstel opnieuw door de molen in plaats van door te lopen.

En elk voorgesteld veld draagt zijn motivering: waarom déze rekening, waarom déze btw-code, waarom dit analytisch plan. Dat is misschien wel de grootste breuk met de regelmotor. Die kon je nooit uitleggen waarom iets geboekt werd zoals het geboekt werd. Hij kon alleen tonen welke regel gevuurd had, en dat is iets anders dan een reden.

Wat overblijft is een boeking die klaarstaat, met een verantwoording erbij, klaar om goedgekeurd te worden.

Wat dat doet met het werk

De rol verschuift van invoer naar toezicht. Je bekijkt niet langer elke factuur, je bekijkt de uitzonderingen. De vraag aan de boekhouder verandert van "waar boek ik dit?" naar "klopt wat hier voorligt?", en die tweede vraag is de vraag waarvoor iemand een boekhouder inhuurt.

Daarnaast verdwijnt er een hele categorie werk die niemand ooit factureerde: het onderhouden van het regelbestand. Geen regel meer bijschrijven voor elke nieuwe leverancier. Geen archeologie meer bij die ene mapping uit 2021.

Er zit nog een voordeel in dat verschil, en het valt pas op wanneer iemand vertrekt. Bij een regelmotor zit de kennis in het hoofd van wie de regels geschreven heeft, en het bestand zelf is voor de rest onleesbaar. Bij beleid in gewone taal staat er letterlijk wat de afspraak is, en de rest zit in de historiek van het dossier zelf. Die kennis gaat niet mee de deur uit als iemand het bedrijf verlaat, en ze valt niet stil wanneer iemand twee weken op verlof is.

De kost die niemand factureert

Er is nog een kost die zelden in de vergelijking zit. Een regelmotor is niet gratis omdat er geen licentie tegenover staat. Hij kost onderhoud. Iemand schrijft de regels, iemand test ze, iemand zoekt uit waarom die ene van 2021 er staat. Dat werk verschijnt op geen enkele factuur, maar het staat wel in de payroll.

Zet er de cijfers naast. Onderzoeksbureau Ardent Partners meet elk jaar wat een aankoopfactuur werkelijk kost, loon en systemen inbegrepen. Bij grotendeels manuele verwerking is dat €11,85 per factuur, bij de best geautomatiseerde teams €2,56. In België weegt dat verschil nog zwaarder: met een gemiddelde loonkost van €48,2 per uur zijn de uren die naar overtikken en corrigeren gaan hier bij de duurste van Europa.

En dan het cijfer dat de verhouding scherp stelt. Gemiddeld wordt 32,6% van de facturen touchless verwerkt, bij de koplopers net geen helft. Bij ons is dat 89%.

Laat ons eerlijk blijven over de grens: dit is geen "de AI doet alles". Achter dat gemiddelde van 89% zit spreiding. Er zijn dossiers die op 100% staan, tientallen facturen na elkaar volledig automatisch, en er zijn er die lager liggen. Zulke verschillen gaan zelden over de software en bijna altijd over hoe uitgesproken de huisregels van een dossier zijn, en of ze ergens staan opgeschreven.

Want dat is de andere kant van de medaille: een afspraak die nergens vastligt, kan geen enkel systeem raden. Die zet je zelf om in één zin. En een dossier dat pas begint heeft nog geen historiek om op terug te vallen, dus dat moet even opwarmen.

Tot slot

De verschuiving laat zich samenvatten in één zin. Vroeger moest je aan je software uitleggen hoe ze moest denken. Nu vertel je haar wat bij jullie de afspraak is, en doet ze de rest.

De regels zijn niet verdwenen. Ze zijn eindelijk van job veranderd.

De volledige berekening, per factuurvolume, staat in onze gids "De verborgen kost van manuele factuurverwerking".

— We hebben jarenlang geprobeerd om boekhouden automatisch te maken door elk geval op voorhand te beschrijven. Wat er veranderd is, is niet dat de regels weg zijn, maar dat het enige wat nog de moeite is om op te schrijven datgene is wat echt eigen is aan jullie huis. De rest leidt het model zelf af uit het dossier. - CTO, Jonathan Callewaert.