Wat AI écht kan in de accountancy — als de basis staat

Jaarrekening-analyse met een lokaal taalmodel

Een van de toepassingen waar ik dagelijks mee werk: ik gooi een jaarrekening en een auditfile in een lokaal taalmodel, en vraag het om een klantmail te genereren. Niet "hier heb je je jaarrekening, veel plezier", maar een mail met echte inzichten:

Dit zijn de dingen die een goede accountant altijd al oppikte, maar waarvoor je nu tijd en aandacht voor moest vrijmaken. Het taalmodel doet het in seconden, consistent, voor elke klant.

Een eigen MCP-server voor Minox

Ik heb zelf een MCP-server gebouwd die verbinding maakt met Minox. Wat dat betekent: ik kan vanuit mijn lokale taalmodel rechtstreeks vragen stellen aan de administratiedata van een klant. Niet via een export, niet via een tussenbestand, maar live, direct.

Dit soort analyse kostte voorheen een half uur aan handmatig uitzoeken. Nu is het een zoekopdracht.

Grenzen van wat ik AI laat doen

Even belangrijk als wat AI wél doet, is wat ik het bewust niet laat doen. Het taalmodel stelt geen jaarrekening definitief vast, het verstuurt geen mail zonder dat ik hem heb gelezen, en het past geen boeking toe zonder mijn akkoord. De rol is altijd: signaleren, voorbereiden, suggereren. De beslissing en de verantwoordelijkheid blijven bij mij.

Dat onderscheid lijkt misschien een formaliteit, maar het is precies waarom dit wél werkt en een ongecontroleerde AI-tool niet. Een taalmodel kan met veel overtuiging iets fout zeggen. Het "klinkt" net zo zeker over een onjuiste conclusie als over een juiste. Door het altijd als hulpmiddel te positioneren en nooit als eindbeslisser, benut ik de snelheid zonder het risico van blinde overname.

RAG: een collega die al jaren met je klanten werkt

Naast de directe administratiekoppeling draait op al mijn klantdata een RAG-systeem. Simpel gezegd: een AI die ook toegang heeft tot alle informatie die ik over mijn klanten heb, zoals gescande documenten, de mappenstructuur per klant, eerdere jaarrekeningen en aangiftes, en mailcorrespondentie.

Het werkt als een collega die al tien jaar met dezelfde klanten werkt. Hij weet dat klant X elk jaar laat is met zijn bankafschriften. Hij kan een concept-klantmail schrijven die aansluit bij de toon en context van de relatie. Dat levert tijdwinst én betere kwaliteit. Niet minder, allebei tegelijk.

Technisch gezien werkt RAG (Retrieval-Augmented Generation) door relevante stukken informatie op te zoeken vóórdat het taalmodel een antwoord formuleert, in plaats van te vertrouwen op wat het model "uit zijn hoofd" denkt te weten. Stel ik een vraag over klant X, dan haalt het systeem eerst de relevante documenten, mails en eerdere jaarrekeningen van die specifieke klant op, en gebruikt het taalmodel die als basis voor het antwoord. Dat voorkomt het risico dat een taalmodel iets verzint dat plausibel klinkt maar feitelijk onjuist is, een bekend risico bij AI dat in de accountancy simpelweg niet acceptabel is.

Alles lokaal, geen cloudrisico

Alles wat ik hier beschrijf draait lokaal. Op mijn eigen server, in mijn eigen netwerk. Geen data naar OpenAI, geen data naar Microsoft, geen data naar wie dan ook. Voor financiële data is dat geen luxe. Het is een vereiste. De investering voor mijn volledige setup: plusminus €4.000. Eenmalig. Geen maandelijkse abonnementskosten.

Die keuze voor lokaal draaien is precies waarom de MCP-koppeling met Minox zo is opgezet als hij is: het taalmodel krijgt alleen leestoegang tot vooraf gedefinieerde tools, en elke boeking die het voorbereidt, leg ik eerst zelf langs voordat die definitief wordt. Hoe die koppeling technisch in elkaar zit, en waarom ik bewust voor die afbakening heb gekozen, beschrijf ik in detail in dit artikel.

De voorwaarden voordat dit werkt

Niets van het bovenstaande werkt als de onderliggende administratie niet klopt. Een taalmodel dat een saldibalans analyseert, kan alleen iets zinnigs zeggen als die saldibalans consistent is opgebouwd: dezelfde grootboekrekeningen voor dezelfde soort kosten, jaar na jaar, klant na klant. Zonder die consistentie levert "AI-analyse" willekeurige output op die toevallig soms klopt.

Dat is de rode draad door deze hele reeks: eerst de documentstroom op orde (zie documentstroom automatiseren), dan correcte factuurherkenning (zie factuurherkenning op debiteur vs. klant), dan een gestandaardiseerde datastructuur, en pas daarna AI. Sla je een van die stappen over, dan bouw je, zoals ik beschrijf in het eerste artikel van deze reeks, een AI-sticker op een fundering die hem niet kan dragen.

Wat dit niet is

Dit is geen kant-en-klare oplossing die je morgen koopt en overmorgen draait. Het vereist een goede basis (zie de andere artikelen in deze reeks), technische kennis of een goede partner, en de bereidheid om te investeren in iets dat je over twee jaar een groot voordeel geeft. Maar als die basis staat? Dan is dit niet de toekomst van de accountancy. Dan is dit al de praktijk.

Het is ook geen vervanging van de accountant of boekhouder. Elke boeking die het systeem voorstelt, beoordeel ik zelf voordat die wordt vastgelegd. Elke conceptmail met signalen lees ik voordat hij naar een klant gaat. AI versnelt het denkwerk en signaleert wat ik anders misschien later, of nooit, had opgemerkt. De verantwoordelijkheid en de uiteindelijke beoordeling blijven bij mij.

Hoe ik begon

Ik ben niet begonnen met een groot, vooraf uitgedacht plan. De eerste versie was simpel: een lokaal taalmodel waarmee ik losse vragen kon stellen over een jaarrekening die ik er handmatig in plakte. Pas toen ik merkte hoeveel tijd dat al bespaarde, ben ik de koppeling met Minox gaan bouwen, om niet steeds handmatig te moeten exporteren en plakken. Daarna volgde de RAG-laag, om ook documenten en correspondentie te laten meewegen.

Die volgorde is precies waarom ik kantoren aanraad om klein te beginnen. Niet alles in één keer bouwen, maar het stap voor stap uitbreiden zodra de vorige stap zijn waarde heeft bewezen. Dat voorkomt dat je investeert in iets waarvan je achteraf niet zeker weet of het wel het juiste was.

Het heeft ook een praktisch voordeel: elke stap die je apart bouwt en test, is apart te beoordelen op betrouwbaarheid voordat je hem inzet op echte klantdata. Een groot, in één keer gebouwd systeem is veel moeilijker te vertrouwen, simpelweg omdat je niet meer precies weet welk onderdeel verantwoordelijk is als er iets misgaat.

Dit klein-beginnen geldt ook voor de keuze van het taalmodel zelf. Ik gebruik niet voor elke taak hetzelfde model. Een eenvoudige herkenningstaak vraagt iets anders dan een genuanceerde analyse van een jaarrekening. Door klein te beginnen, leer je ook welke taak welk niveau van taalmodel daadwerkelijk nodig heeft, in plaats van overal blind de zwaarste en duurste optie op los te laten.