Knowledge base voor je finance-assistent

Een knowledge base voor een finance-assistent is de gestructureerde verzameling documenten — KPI-definities, rekeningschema, finance-policies, vaste templates en relevante fiscale interpretaties — die de assistent als grond gebruikt naast de prompt. Voor finance-teams: negen van de tien keer ligt slechte AI-output op finance-vragen aan slordige knowledge, niet aan de prompt — formaat, structuur en versiebeheer maken het verschil.

Een AI-assistent in finance is zo goed als zijn instructies en zijn knowledge. De instructies krijgen meestal alle aandacht; de knowledge wordt er op het laatste moment bij geplakt. Dat is zichtbaar in de output: finance-assistenten die generiek blijven over jullie KPI-definities, verwijzen naar dingen die er niet staan, of net de relevante clausule in een fiscaal handboek missen — negen van de tien keer ligt het aan de kennisbank, niet aan de prompt.

Een knowledge base voor finance inrichten is geen technische klus. Het is een redactionele klus: welke documenten horen erin, in welk formaat, met welke structuur, zodat het model er snel en correct uit kan putten — en zodat de output bestand is tegen een externe controle.

Wat hoort in de knowledge base, en wat niet

Een nuttige scheidslijn: instructies gaan in de system prompt, referentiemateriaal gaat in de knowledge base. Anders gezegd — de prompt zegt hoe het model moet werken, de knowledge base zegt waarmee.

Hoort er in voor finance:

• Voorbeelden van goede output (eerdere variance-toelichtingen, board-pack-secties, debiteuren-mails in de juiste toon).
• Stijlgidsen voor finance-communicatie (board-toon, investor-update-toon, klantbrief-toon).
• Vaste referentiedata: rekeningschema met toelichting, KPI-definities, kostenplaats-structuur, dimensies, fiscale instellingen.
• Beleid en procedures: close-handboek, BTW-handboek, autorisatiematrix, accounting-manual.
• Templates die het model moet vullen (board-pack-template, MT-rapportage-template).
• Historisch materiaal voor vergelijking: afgelopen kwartaal-rapportages, eerdere jaarrekening-toelichtingen.

Hoort er niet in:

• Lange instructies over hoe de assistent moet denken — die horen in de prompt.
• Dynamische data die dagelijks wijzigt — die hoort via een connector of MCP-tool, niet als bestand in de knowledge.
• Bestanden met persoonsgevoelige data die de gebruikersgroep niet mag zien (knowledge is zichtbaar voor iedereen met toegang tot de assistent).
• Ruwe dumps van het hele close-archief "voor de zekerheid". Zie verderop.

Aantal documenten — minder is bijna altijd beter

De verleiding is om alles wat vagelijk relevant lijkt erin te gooien. Dat werkt slecht om twee redenen.

Ten eerste: elk platform heeft grenzen. Custom GPTs staan 20 bestanden toe, Claude Projects laden tot 200K tokens (1M enterprise), Gemini Gems tot tien bestanden. Bij full-context-platforms betaal je per run voor alles wat je erin stopt; bij RAG-platforms wordt bij grotere omvang het retrieval-mechanisme actief en speelt ranking een rol.

Ten tweede: meer is niet beter voor de modelprestatie. Als vijf voorbeelden goed zijn, maken vijftig middelmatige voorbeelden het slechter — het model leert gemiddeld in plaats van uitstekend. Een goede vuistregel: drie tot tien zorgvuldig gekozen referenties slaan twintig verzamelde documenten.

Voor de meeste finance-assistenten werkt: één rekeningschema-toelichting, één KPI-definitie-document, drie tot vijf voorbeeldoutputs (een board-pack-sectie, een variance-toelichting, een debiteuren-mail), één close-handboek, één fiscale referentie. Dat is het.

Formaat — leesbaar voor mens én model

Modellen zijn het best in platte tekst en markdown. Ze redden zich prima met PDF's en Word, maar verliezen informatie zodra opmaak complex wordt: meerkoloms-layouts, tekstvakken, voetnoten, ingesloten afbeeldingen met tekst erin.

Praktische richtlijnen voor finance:

• Markdown (.md) of platte tekst (.txt) is optimaal. Headers, lijsten en tabellen blijven behouden, geen opmaak-ruis.
• Word: prima als tekst vooraan staat en de structuur lineair is. Een close-handboek met tekstvakken en kolommen: platslaan naar markdown.
• PDF's: werken, maar gescande PDF's zonder OCR zijn voor het model plaatjes — inhoud onleesbaar. Zet OCR aan vóór upload.
• Excel: werkt, maar modellen lezen tabellen beter als ze klein en plat zijn. Voor je rekeningschema-Excel: exporteer een kernoverzicht naar markdown of CSV.
• Afbeeldingen en screenshots: alleen als het model multimodaal is en je de beeldcontent nodig hebt.

Een veelgemaakte fout in finance: een rekeningschema-toelichting als PDF met sierlijke layout en meerdere kolommen uploaden. Het model leest er een kwart uit. Zelfde inhoud in markdown — een uur werk — en de assistent gebruikt hem consequent.

Structuur — schrijf voor snel scannen

Binnen een document geldt dezelfde logica als voor een goede interne wiki. Koppen, korte alinea's, lijsten, en een duidelijke hiërarchie helpen het model — zowel bij full-context lezen als bij RAG-retrieval.

Een werkbare structuur voor een finance-knowledge-document:

# Titel (waar gaat dit document over)

## Korte samenvatting (2-3 zinnen, voor snelle oriëntatie)

## Hoofdsectie 1 (bv. categorieën in het rekeningschema)
…

## Hoofdsectie 2 (bv. specifieke afspraken per categorie)
…

## Uitzonderingen en edge cases
…

## Verwante documenten

De samenvatting bovenaan is geen opsmuk. Bij RAG-retrieval wordt vaak het begin van een document zwaarder gewogen; een goede samenvatting verhoogt de kans dat dit document wordt opgehaald voor de juiste vragen. Bij full-context lezen helpt het het model om prioriteit te bepalen.

Benoem documenten zoals je ze aan een mens zou geven

Bestandsnamen doen ertoe. Modellen gebruiken ze — soms expliciet, soms als ranking-signaal. Rekeningschema-toelichting-v2-FINAL (3).pdf is voor niemand behulpzaam. Rekeningschema-toelichting-2026-Q2.md of KPI-definities-handboek-2026.md zegt direct waar het document over gaat.

Consistente naamgeving binnen één assistent werkt in het voordeel van zowel de onderhoudende mens als het model. Prefixen als template-, voorbeeld-, handboek-, kpi- maken in één oogopslag duidelijk waar een document voor dient.

Verwijzen vanuit de system prompt

Een knowledge base die wordt genegeerd had er net zo goed niet kunnen zijn. Finance-assistenten hebben baat bij een expliciete instructie in de prompt over welke documenten beschikbaar zijn en wanneer ze te raadplegen:

"Raadpleeg altijd KPI-definities-handboek-2026.md voordat je een KPI berekent. Gebruik Variance-toelichting-voorbeelden.md als referentie voor toon en structuur. Bij vragen over ons rekeningschema: check eerst Rekeningschema-toelichting-2026-Q2.md voordat je iets zelf bedenkt — verzin geen kostenplaatsen die niet in dit bestand staan."

Deze expliciete koppeling tussen prompt en knowledge is een van de meest onderschatte verbeteringen. Zonder verwijzing laat het model knowledge vaak links liggen, vooral in RAG-opzet.

Onderhoud — plan vervanging, niet accumulatie

Knowledge veroudert. Een finance-assistent die in januari is gebouwd met de KPI-definities van december, is in juni verouderd. Een rekeningschema dat is gewijzigd na een reorganisatie is voor de oude versie geen referentie meer.

Een eenvoudig ritme voor finance-knowledge:

• Per kwartaal: loop de knowledge door. Vervang oude voorbeelden door nieuwe, werk referentiedata bij, verwijder wat niet meer relevant is.
• Bij elke significante wijziging (nieuw boekjaar, nieuwe entiteit, gewijzigd rekeningschema, nieuw fiscaal beleid): direct updaten, niet wachten.
• Bij modelupdate: snel checken of de assistent nog hetzelfde gedrag laat zien — soms gedragen modellen zich anders bij dezelfde knowledge.
• Één eigenaar per assistent, typisch een senior controller of finance-manager. Niet een commissie. Zonder eigenaar geen onderhoud.

Dateer versies in de bestandsnaam of in een kopregel — zowel voor de gebruiker als voor het model.

Privacy en toegang in finance-context

Wat in de knowledge base zit, is zichtbaar voor iedereen die de assistent mag gebruiken. Dat is de belangrijkste governance-regel.

Concrete finance-richtlijnen:

• Klantnamen, IBAN's, specifieke transacties in voorbeeldboard-packs of voorbeeld-debiteuren-mails: anonimiseren. "Klant A" werkt prima als voorbeeld.
• Salarisgegevens, personeelsdossiers: niet in een breed gedeelde finance-assistent.
• M&A-documentatie onder NDA: niet in een gewone assistent, eventueel in een aparte, klant-specifieke assistent met strikte toegangsbeperking.
• Historische jaarrekeningen: prima als referentie, mits geanonimiseerd waar nodig (zeker bij gevoelige posten).

Zie AI-governance voor finance voor de bredere tier-classificatie.