AI gestructureerd invoeren in finance betekent hetzelfde als elke andere systeemimplementatie: eerst inrichten, dan automatiseren. In de praktijk bouw je zes lagen van onder naar boven op. Eerst leg je de kennis over je bedrijf vast (context), dan regel je toegang tot de systemen (koppelingen), dan automatiseer je het vaste regelwerk (automatisering, tegenwoordig zelf te bouwen met vibe coding), dan leg je terugkerende taken vast (skills), dan zet je die in volgorde (workflows), en pas daarna laat je AI oordeelswerk doen (agents). Versiebeheer en controle lopen door alle lagen heen.
Grote kans dat iemand in je team al eens een toelichting op de maandcijfers door ChatGPT of Copilot heeft laten schrijven. Soms bruikbaar, vaak net niet. De verkeerde grootboekrekening genoemd, een afwijking verklaard die er niet is, de volgende maand een heel andere opbouw. De conclusie is dan snel: AI is nog niet zover voor finance.
Dat is meestal de verkeerde conclusie. Het is dezelfde les als bij elke ERP-implementatie: wie automatiseert wat niet is vastgelegd, automatiseert de rommel. Een nieuw ERP begin je ook niet met de rapportages. Je begint met het rekeningschema, de stamgegevens, de procedures en de autorisaties. Met AI is het niet anders.
Waarom finance hier strenger is dan andere afdelingen
Een AI-model weet veel over finance in het algemeen en niets over jouw bedrijf. Het kent jouw rekeningschema niet, jouw materialiteitsgrens niet, en niet de afspraak dat projectomzet pas wordt verantwoord na oplevering. Het kan niet vanzelf bij je administratie. En een taak die je niet precies hebt vastgelegd, doet het elke keer net iets anders.
Voor marketing of HR is dat vaak acceptabel. Voor finance niet. Cijfers moeten kloppen, aansluiten en herleidbaar zijn tot de bron, elke maand op dezelfde manier. De accountant wil kunnen zien hoe een getal tot stand kwam. Dat vraagt om een functie die zo is ingericht dat AI erin kan werken, niet om een tool die je naast de bestaande werkwijze zet.
De zes lagen
Oordeelswerk en bewaking per domein.
Taken in volgorde, gekoppeld aan de finance-kalender.
Vastgelegde werkinstructies, één taak per skill.
Vastlegging, verwerking en verbindingen, gebouwd met vibe coding.
Toegang tot administratie, bank en bronsystemen.
De kennis over je bedrijf, vastgelegd.
| Laag | Wat het is | Welke vraag het beantwoordt |
|---|---|---|
| 1. Context | De kennis over je bedrijf, vastgelegd | Hoe werkt dit bedrijf? |
| 2. Koppelingen | Toegang tot administratie, bank en bronsystemen | Waar staan de gegevens? |
| 3. Automatisering | Vastlegging, verwerking en verbindingen, gebouwd met vibe coding | Hoe komen gegevens vanzelf op de juiste plek? |
| 4. Skills | Vastgelegde werkinstructies, één taak per skill | Hoe doen we deze taak, elke keer? |
| 5. Workflows | Taken in volgorde, gekoppeld aan de finance-kalender | Wat gebeurt er wanneer? |
| 6. Agents | Oordeelswerk en bewaking per domein | Wat betekent dit en wat moet er gebeuren? |
| Doorlopend: versiebeheer | Alle context, skills en scripts in GitHub | Wie wijzigde wat, wanneer en waarom? |
| Doorlopend: controle | Goedkeuring, onderbouwing, logging | Waar beslist de mens? |
De lagen bouwen op elkaar. Een skill leest de context. Een workflow zet skills in volgorde. Een agent werkt met wat de lagen eronder aanleveren. Ontbreekt er een laag, dan gaat de laag erboven haperen.
Laag 1: context
Alles wat een ervaren collega weet en een nieuwe collega nog niet: het rekeningschema en waarom het zo is ingericht, de KPI-definities, het verdienmodel, de waarderingsgrondslagen, de afspraken met grote klanten, de materialiteitsgrenzen en wat er bij vorige afsluitingen misging. Die kennis zit nu meestal in hoofden, mailtjes en losse Excel-tabbladen.
Die kennis leg je vast in korte, losse documenten, één onderwerp per document, elk met een eigenaar en een datum van laatste wijziging. Zo laadt elke taak alleen wat hij nodig heeft, en weet je wie het moet bijwerken als er iets verandert. Meer hierover in Context engineering voor finance-AI.
Waar sla je het op? Een praktijkvoorbeeld. De werkwijze die in de praktijk het best werkt: één afgeschermde (private) GitHub-repository voor de finance-functie, met platte tekstbestanden in Markdown. Geen Word-documenten diep in SharePoint en geen tabbladen in de maandafsluitings-Excel. Markdown is voor mensen en AI-modellen even goed leesbaar, elke wijziging is per regel zichtbaar, en tools als Claude Code lezen de map direct in.
Een indeling die goed werkt:
finance-functie/
├── README.md ← wat staat waar, wie is eigenaar
├── context/
│ ├── bedrijf-en-structuur.md ← entiteiten, activiteiten, organisatie
│ ├── rekeningschema.md ← per rekening: wat hoort erop, wat niet
│ ├── grondslagen.md ← omzetverantwoording, waardering, afschrijving
│ ├── materialiteit-en-drempels.md
│ ├── intercompany-en-verdeelsleutels.md
│ ├── kpi-definities.md
│ ├── klanten-en-contracten.md ← afspraken die de boekingen raken
│ └── close-historie.md ← wat ging er eerder mis, en waarom
├── skills/ ← laag 4, één map per skill
├── scripts/ ← laag 3, de zelfgebouwde automatisering
└── workflows/ ← laag 5, bijvoorbeeld maandafsluiting.md
En zo ziet één contextbestand eruit:
---
eigenaar: Controller
laatst_bijgewerkt: 2026-09-30
geldt_voor: alle entiteiten
gelezen_door: controle-afwijkingen, toelichting-maandcijfers
---
# Materialiteit en drempels
## Toelichten in de maandrapportage
- Afwijking ten opzichte van budget of vorige maand groter dan € 2.500 én groter dan 10%: altijd toelichten.
- Afwijking op omzet: altijd toelichten, ongeacht de omvang.
## Bekende patronen (niet als afwijking melden)
- Marketingkosten (rekening 4400): in Q2 structureel hoger door beurzen.
- Vakantiegeld: reservering maandelijks, uitbetaling in mei.
## Escaleren naar de CFO
- Elke correctie op een afgesloten periode.
- Elk intercompany-verschil, ongeacht de omvang.
Drie spelregels horen erbij. Er staan geen wachtwoorden, API-sleutels of persoonsgegevens in de context. Er is één bron: wie dezelfde informatie ook nog in een Word-document bijhoudt, heeft binnen drie maanden twee versies van de waarheid. En het bijwerken staat als vaste stap op de checklist van de maandafsluiting, anders gebeurt het niet.
Is GitHub voor je team nog een brug te ver, begin dan met dezelfde mappenstructuur en Markdown-bestanden in een gedeelde SharePoint- of OneDrive-map. Dan heb je de structuur al, en verhuizen naar GitHub is later een kwestie van de map overzetten.
Laag 2: koppelingen
De toegang tot de plekken waar de gegevens staan: het boekhoudpakket (Exact Online, Twinfield, AFAS), de bank, het facturatiesysteem, het CRM en de map met contracten. Steeds vaker loopt die toegang via MCP, de standaard waarmee AI-modellen met systemen praten (zie Wat is MCP).
De belangrijkste ontwerpkeuze: lezen of schrijven. Begin altijd met alleen-lezen. Schrijfrechten komen pas als een workflow bewezen heeft dat hij ze nodig heeft, en dan achter een goedkeuringsstap. Agentic AI en toegang tot je administratie gaat daar dieper op in.
Laag 3: automatisering van vastlegging en verwerking
Niet elk systeem heeft een kant-en-klare koppeling, en veel finance-werk bestaat nog uit handwerk tussen systemen: exporteren, overtypen, in Excel naast elkaar leggen. Die automatisering hoeft geen IT-project meer te zijn. Met vibe coding bouw je hem zelf. Bij vibe coding beschrijf je in gewone taal wat je wilt en schrijft een AI-model de software. Wat vroeger een IT-project was, bouwt een controller nu in een middag.
Deze laag doet drie dingen:
- Verbindingen tussen systemen. Facturatie die automatisch aansluit op het grootboek, uren die gekoppeld worden aan projecten, de CRM-klant die gematcht wordt met de debiteur.
- Vastlegging. Inkoopfacturen die uit de mailbox worden gelezen en als conceptboeking klaarstaan. Bankmutaties die dagelijks binnenkomen en worden voorgematcht.
- Verwerking. Afstemmingen, verdeelsleutels en herberekeningen die elke maand op precies dezelfde manier lopen.
Wat je hier bouwt is gewone software, geen AI die per keer redeneert. Het doet elke keer exact hetzelfde, kost per run vrijwel niets en interpreteert niets anders dan vorige maand. Dat is de bedoeling. Alles wat vaste regels volgt, hoort in deze laag. Hoe meer daar geregeld is, hoe schoner de gegevens zijn waar de agents verderop mee werken.
De vuistregel om te bepalen wat hier hoort: als twee ervaren medewerkers deze taak los van elkaar uitvoeren, komen ze dan op hetzelfde uit? Dan is het regelwerk en hoort het in deze laag. Vraagt het een afweging, dan hoort het bij een agent.
Laag 4: skills
Een skill is een vastgelegde werkinstructie die AI elke keer op dezelfde manier uitvoert: de toelichting op afwijkingen, de wekelijkse liquiditeitsupdate, de controle op overlopende posten. Je legt de taak één keer goed uit in plaats van elke keer opnieuw.
Drie ontwerpregels maken een skill betrouwbaar:
- Eén taak per skill. Doet een skill twee dingen, dan weet je bij een fout niet welke misging.
- Geen vaste getallen in de skill zelf. Drempels en uitzonderingen staan in de context (laag 1). Verandert de drempel, dan pas je één document aan, niet tien skills.
- Laat het rekenwerk zien. Elke uitkomst komt met de bron, de formule en de tussenstappen. Ontbreekt er iets, dan stopt de skill en vraagt hij het na.
Laag 5: workflows
Een workflow zet skills en automatisering in volgorde en hangt ze aan de kalender van de finance-functie: wat gebeurt er op werkdag 1, 2 en 3 van de afsluiting, wat elke maandag, wat aan het eind van het kwartaal. Tussen de blokken zitten de momenten waarop een mens het vorige blok goedkeurt voordat het volgende start. Zie ook AI-workflow rond de maandafsluiting.
Laag 6: agents
Bovenin zitten de agents. Zij doen wat niet in vaste regels te vangen is: een afwijking duiden, beoordelen of iets eenmalig of structureel is, een correctie voorstellen, bepalen wat een mens moet zien. Je organiseert ze per domein: controle, debiteuren en crediteuren, analyse, forecasting, rapportage. Een MKB-bedrijf begint met één.
Doorlopend: versiebeheer
Zodra een team AI echt gaat gebruiken, gaat iedereen bouwen. De een maakt een script voor de bankaansluiting, de ander een skill voor de debiteurenmail. Dat is goed, tot je merkt dat het allemaal op persoonlijke laptops staat. Dan vertrekt die ene controller, en de automatisering vertrekt mee. Of er komt een vraag van de accountant over een cijfer van drie maanden geleden, en niemand weet welke versie van welke skill dat cijfer heeft gemaakt.
De oplossing klinkt voor een finance-team misschien vreemd, maar is de standaard in softwareontwikkeling: zet alles in GitHub. De context, de skills, de scripts en de workflowbeschrijvingen staan in één repository, met de volledige geschiedenis van elke wijziging.
Voor finance levert dat drie dingen op die je al kent uit de AO/IC:
- Een audittrail op je eigen werkwijze. Je ziet per regel wie de materialiteitsgrens wijzigde, wanneer en waarom. En je kunt terugzien welke versie van een skill in een bepaalde maand draaide.
- Het vier-ogenprincipe op wijzigingen. Een wijziging gaat via een zogeheten pull request: de controller stelt een aanpassing voor, de CFO keurt hem goed voordat hij actief wordt. Precies zoals een wijziging in de stamgegevens.
- Kennis die blijft. Wat er gebouwd is, staat op een vaste plek, is voor het team zichtbaar en herbruikbaar, en blijft als de bouwer vertrekt.
Eén regel voor iedereen die iets bouwt: wat niet in de repository staat, bestaat niet. En wordt een contextbestand gewijzigd, dan test je de skills die het lezen opnieuw voordat ze weer in de afsluiting draaien.
Doorlopend: de controlelaag
Dwars door alle lagen loopt de vraag: wat als het fout gaat? Het antwoord zit in de inrichting, niet in de hoop dat het goed gaat. Elke bevinding heeft een onderbouwing die terug te volgen is tot de boeking. Elke actie wordt gelogd. Bij twijfel stopt het systeem en vraagt het na. En er zijn vaste momenten waarop een mens goedkeurt voordat er iets verdergaat. Waar je die momenten legt, staat in Human-in-the-loop in finance-workflows.
Voorbeeld: de controller-workflow door de lagen heen
Een goed startpunt voor bijna elk finance-team is de controle van de maandafsluiting. Een fout die daar doorglipt, komt terug in de rapportage, in de forecast en uiteindelijk in een beslissing. Neem een MKB-bedrijf met twee entiteiten, Exact Online, een facturatiesysteem en een controller die nu twee dagen per maand bezig is met nalopen. Zo werken de lagen samen.
Laag 1, context. De controller legt vast wat zij nu in haar hoofd heeft: het rekeningschema met per rekening wat erop hoort, de materialiteitsgrens (bijvoorbeeld afwijkingen boven € 2.500 of 10% toelichten), de grondslag voor omzetverantwoording, de verdeelsleutel voor gedeelde kosten tussen de twee entiteiten, en een lijst met wat er de afgelopen afsluitingen misging. Dat laatste document is goud waard: het vertelt de rest van het systeem waar het moet kijken. Alles komt in de context/-map van de repository van de finance-functie.
Laag 2, koppelingen. Alleen-lezen-toegang tot beide administraties in Exact, de bankrekeningen, het facturatiesysteem en de map met contracten. Er wordt niets geschreven.
Laag 3, automatisering. De controller bouwt met vibe coding een paar kleine programma's die het regelwerk doen. Een aansluiting van de omzet in het facturatiesysteem op de omzet in het grootboek. Een aansluiting van de bank op de balans. Een check of de intercompany-vordering van de ene entiteit gelijk is aan de schuld bij de andere. Een vergelijking van de proefbalans met vorige maand per rekening. Deze programma's draaien elke maand identiek en leveren een lijst met verschillen op. Geen interpretatie, alleen feiten.
Laag 4, skills. Voor het oordeelswerk komen er skills, elk met één taak. Een skill die de verschillenlijst beoordeelt tegen de materialiteitsgrens. Een die kijkt of omzet en kosten in de juiste periode zijn geboekt. Een die nagaat of de vaste overlopende posten (vakantiegeld, nog te ontvangen facturen, vooruitbetaalde licenties) er zijn. Een die de bevindingen samenvat in het vaste format van de controller. Drempels en grondslagen komen uit laag 1.
Laag 5, workflow. Op werkdag 1 na de periode-afsluiting draaien de programma's uit laag 3. Daarna lopen de skills in vaste volgorde: eerst volledigheid en aansluitingen, dan periode-toerekening, dan overlopende posten. Na elk blok is er een goedkeuringsmoment. Pas als de aansluitingen akkoord zijn, start de inhoudelijke beoordeling.
Laag 6, agent. De controle-agent neemt de uitkomsten van de lagen eronder en doet wat regels niet kunnen. Hij legt verbanden: het verschil tussen facturatie en grootboek valt samen met een creditnota die in de verkeerde maand is geboekt. Hij stelt een correctieboeking voor. En hij geeft per onderdeel aan hoe zeker hij is, zodat de controller weet waar ze zelf moet kijken.
Versiebeheer. Na de derde afsluiting blijkt de materialiteitsgrens voor kleine kostenrekeningen te laag: de lijst met bevindingen is te lang. De controller stelt een nieuwe grens voor via een pull request, de CFO keurt hem goed, en de skills die het bestand lezen worden eerst opnieuw getest op de vorige maand. Bij de jaarafsluiting kan ze de accountant precies laten zien welke grens in welke maand gold.
Controlelaag. De controller krijgt één overzicht: bevindingen, onderbouwing per punt met verwijzing naar de boeking, voorgestelde correcties en de mate van zekerheid. Zij keurt goed, past aan of wijst af. De agent boekt niets zelf. Alles wat er gebeurde staat in de log.
Het resultaat: de controller zoekt niet meer, ze beoordeelt. De twee dagen nalopen worden een paar uur gericht kijken naar wat er echt toe doet. En omdat elke laag zijn eigen werk doet, weet je bij een fout ook waar je moet zoeken. Klopt een definitie niet, dan pas je de context aan. Zijn de cijfers verouderd, dan zit het in de koppeling. Is de opbouw verkeerd, dan zit het in de skill.
Wat er gebeurt als een laag ontbreekt
De structuur is ook een diagnose-instrument. Wie AI inzet en teleurgesteld is, kan meestal aanwijzen welke laag mist:
- Geen context: de antwoorden zijn algemeen en net niet van toepassing op jouw bedrijf.
- Geen koppelingen: iemand is elke maand bezig met exporteren en uploaden, en de cijfers zijn altijd een stap achter.
- Geen automatiseringslaag: de agent doet regelwerk dat gewone software beter doet. Duurder, trager, en elke maand net iets anders.
- Geen skills: de kwaliteit hangt af van wie de vraag stelt en hoe die hem die dag formuleert.
- Geen workflow: losse hulpmiddelen die niemand op het juiste moment aanzet.
- Geen versiebeheer: automatiseringen op persoonlijke laptops, en niemand kan zeggen welke versie van een skill het cijfer van vorige maand maakte.
- Geen controlelaag: het gaat weken goed, het team stopt met controleren, en dan gaat het een keer mis zonder dat iemand het ziet.
Waar begin je?
Niet met de agent, en ook niet per se met programmeren. Begin met één workflow die nu tijd kost en waarvan je de uitkomst kunt controleren. De controle van de afsluiting is vaak de beste kandidaat. Zet eerst de repository op, zodat alles vanaf dag één een vaste plek en een geschiedenis heeft. Bouw de lagen dan van onder naar boven: eerst de context opschrijven, dan de koppelingen, dan het regelwerk automatiseren, dan de skills, dan de workflow met de goedkeuringsmomenten. De agent komt als laatste.
Test de hele keten eerst op een afgesloten maand waarvan je de juiste uitkomst al kent. Pas als hij daar klopt, mag hij aan de lopende maand.
De volgorde van de lagen is de architectuur, niet een verplichte bouwvolgorde. Veel teams halen hun eerste resultaat met context en skills op exports uit het boekhoudpakket. Dat is prima. Voeg de automatisering toe zodra je merkt dat skills of agents regelwerk aan het doen zijn, of dat iemand elke maand hetzelfde bestand staat te exporteren.
De echte opbrengst zit vaak niet in de agent zelf. Die zit in het feit dat je gedwongen wordt op te schrijven hoe je finance-functie eigenlijk werkt. Wil je weten hoe ver jouw team daarvan af staat, dan is een AI-readiness-scan een goed begin.