Welke taken in je crediteurenadministratie een agent vandaag echt afmaakt, welke hij half doet, en welke je er beter buiten houdt.
Wat is een AI-agent voor crediteuren?
Een agent heeft handelingsvermogen. Hij volgt geen pad dat jij vooraf hebt uitgetekend, maar bepaalt binnen bandbreedtes zelf welke stappen nodig zijn: eerst de order erbij, dan de ontvangst, dan de mail van vorige week waarin een toeslag werd aangekondigd. Bij de volgende factuur kan die route er anders uitzien, omdat de situatie anders is. Het verschil met regelgebaseerde automatisering en met workflows staat uitgebreider in AI-agents voor finance.
Twee dingen uit dat artikel zijn hier nodig, want ze bepalen wat je koopt.
Het label zegt niets. AI-first en AI-native gaan over hoe iets gebouwd is. Agent gaat over wat het kan. Je kunt AI-native zijn en toch een workflow draaien zonder enig handelingsvermogen, en je kunt een agent bouwen bovenop een systeem van twintig jaar oud. Wat je wilt weten is niet de bouwgeschiedenis, maar wat er gebeurt met jouw factuur die niet matcht.
De verdeling die werkt is: de AI leest en zoekt uit, de regel beslist. Bijna alle bestaande factuurverwerking heeft AI, en die zit vrijwel altijd op dezelfde plek, namelijk in de leesstap. Een PDF wordt omgezet naar velden, en bij regelherkenning naar artikelen, aantallen en prijzen. Dat is knap werk, het is al jaren goed, en het beslist niets.
Dat er € 12,96 per stuk op de factuur staat, is een leesresultaat. Of dat klopt tegenover de bestelling, of een verschil van € 22,47 een afrondingsverschil is of een prijsfout, op welk grootboek het moet, en wie je erover mailt: dat zijn beslissingen. Een agent begint precies daar. De order staat op 400 stuks en de factuur op 380. Het PO-nummer staat er niet op. De leverancier factureert vanuit een andere entiteit dan waar besteld is. Op dat punt legt scan-en-herkensoftware de factuur in een wachtrij, en dat is precies wat je van die categorie mag verwachten. Een agent gaat uitzoeken waarom.
Waar de tijd echt heen gaat op een crediteurenafdeling
De verhouding die dit gesprek beslecht is niet hoeveel facturen er automatisch doorgaan, maar hoe de tijd verdeeld is.
In de praktijk zien wij bij Claridy steeds hetzelfde. De twintig procent van de facturen die niet in de regels past, kost meer dan tachtig procent van de tijd. Precies de gevallen die je niet had voorzien, zijn de gevallen waar iemand een half uur aan kwijt is: het ordernummer dat de leverancier verkeerd overnam, het bedrag dat drie cent afwijkt, de creditnota die bij een factuur uit een vorige periode hoort, de vraag per mail waarom er nog niet betaald is.
Dat is de reden dat een hoger herkenningspercentage je niets meer oplevert. Die tachtig procent was nooit het probleem. Een crediteurenafdeling die goede scan-en-herkensoftware draait, verwerkt de makkelijke facturen al vrijwel zonder aanraking, en de dag vult zich alsnog.
Wat dit betekent voor je afweging: gaat het inlezen bij jou nog handmatig, koop dan scan-en-herkensoftware en geen agent. Dat is goedkoper en het lost je probleem op. Zit het inlezen al goed en gaat de tijd naar alles daaromheen, dan koop je met meer scan-en-herken niets.
Zes dingen die een crediteuren-agent overneemt
1. De facturenmailbox afhandelen
Niet alleen facturen. In een gedeelde inkoopmailbox zitten facturen, creditnota's, pakbonnen, aanmaningen en gewone vragen door elkaar. Een agent herkent per bericht wat voor document het is, koppelt het aan de juiste entiteit en administratie, en verwerkt het meteen in plaats van het door te zetten naar een mens die het opnieuw moet beoordelen.
Dat scheelt twee stappen die nu overal handmatig zijn. Bij een internationaal softwarebedrijf op NetSuite downloadt het AP-team facturen uit gedeelde mailboxen en stuurt ze door naar landspecifieke adressen van de scansoftware. Bij een retailgroep op Dynamics slepen medewerkers elke ochtend facturen met de hand vanuit de mail in het documentsysteem. Een groep bedrijven heeft de inkoopmailbox opgesplitst per bv, puur omdat hun scanoplossing entiteiten niet uit elkaar houdt.
Daarnaast beantwoordt de agent wat er binnenkomt: betaalstatus, een aangekondigde creditnota, een prijsverschil dat uitleg nodig heeft. In de thread, met het juiste document erbij.
2. Matchen op regelniveau, 2-way en 3-way
Factuur tegen order, en waar er ontvangsten zijn ook tegen de ontvangst. Op regelniveau, want dat is wat de meeste ERP-inrichtingen afdwingen. Een retailgroep op Dynamics zei het zo: "Wij doen wel die matching op regelniveau, omdat het systeem dat vraagt."
Het werk zit in de gevallen die daar net buiten vallen, en dat zijn er meer dan je zou willen:
- Het ordernummer staat niet op de factuur, of de leverancier heeft het verkeerd overgenomen. Een onderhoudsbedrijf op NetSuite registreert facturen zelfs volledig buiten het inkooporderproces om, ongeacht of er een order is.
- Eén factuur hangt aan meerdere inkooporders, of aan een order die in delen is geleverd.
- De aantallen kloppen wel en de prijs niet, of andersom.
Een agent zoekt de order er zelf bij op basis van leverancier, bedragen en regels, laat zien hoe zeker hij is, en komt pas bij je team als hij het niet rondkrijgt.
De regel waarop hij matcht, schrijf je zelf, in gewone taal. Geen tabel met veldposities per leverancier.
3. Coderen op regelniveau, over alle dimensies
Grootboekrekening, kostenplaats, project, btw-code, en wat er verder in jouw administratie aan assen hangt. Per factuurregel, niet per factuur, want één factuur kan over drie kostenplaatsen gaan.
De volgorde die werkt: eerst de leverancier. De meeste leveranciers boeken elke keer hetzelfde en dan is het klaar. Is de leverancier niet consistent, en dat komt vaak voor bij grote leveranciers die van alles leveren, dan kijkt de agent naar de historie van vergelijkbare regels en naar de instructies die jij hebt gegeven. Die instructies schrijf je in gewone taal, niet als een tabel met vaste posities per leverancier.
Het punt dat er het meest toe doet: het systeem moet leren van je correcties. Boekt je team een regel drie keer anders dan voorgesteld, dan hoort dat de vierde keer goed te gaan zonder dat iemand een regel heeft aangepast. Vraag hier expliciet naar bij een leverancier, want het is het verschil tussen software die beter wordt en software die elk kwartaal onderhoud vraagt.
4. Het verschil uitzoeken en erover mailen
Dit is één taak, geen twee. Een verschil dat je niet uitzoekt, kun je niet uitleggen, en een mail die je stuurt zonder te weten wat er mis is, levert een tweede mail op.
Twee soorten afwijkingen, en een agent hoort ze allebei te pakken.
De rekenkundige. Tellen de regels op tot het totaal, klopt de btw over het juiste bedrag, staat er een korting op die nergens is doorgerekend. Bij een retailgroep op Dynamics bleef een regel van 17 cent los staan die het systeem niet kon matchen. Zulke gevallen kosten geen minuut werk, ze kosten alleen aandacht, en dat is precies wat schaars is.
En de inhoudelijke. Het verkeerde btw-tarief, verlegde btw die niet verlegd is, facturatie vanuit of naar de verkeerde entiteit, een IBAN dat afwijkt van wat er in je crediteurenstamgegevens staat, een ontbrekend ordernummer.
Wat de agent doet: narekenen, de order en de ontvangst en de eerdere correspondentie erbij halen, en als het daarmee niet rond komt een mail klaarzetten met het verschil er concreet in.
Naar de leverancier of naar een collega, en dat onderscheid is belangrijker dan het lijkt. Een prijs die afwijkt van de order is iets voor de leverancier. Een aantal dat afwijkt van wat er ontvangen is, is iets voor de collega die het heeft besteld of aangenomen. Een agent die alles naar de leverancier stuurt, verplaatst het werk alleen maar.
Vervolgens verwerkt hij het antwoord en pakt de factuur weer op. Zonder dat er iemand een herinnering in zijn agenda hoeft te zetten.
5. Aanbieden ter goedkeuring
Niet doorzetten volgens een vaste route, maar bepalen wie hierover moet beslissen en het aan die persoon voorleggen. Dat verschil is de kern van wat je van een agent mag verwachten.
De drempels waarop dat gebeurt, verschillen per bedrijf en staan vaak nergens in een systeem. In één administratie op Exact Globe geldt: is de bestelorder gematcht, dan is onder de vijfduizend euro geen goedkeuring nodig. Een retailgroep op Dynamics hanteert een andere regel: "Als de match op inkoopregel is, dan mag je hem altijd afboeken. Als hij op leverancier en bedrag matcht, wil ik dat er altijd nog een werknemer naar kijkt."
Je mag verwachten dat de agent die regels toepast zonder dat iemand ze per factuur opnieuw invoert, zelf de juiste goedkeurder bepaalt op basis van leverancier, bedrag, kostenplaats en wat er eerder is gebeurd, en de factuur voorlegt met alles erbij wat die persoon nodig heeft om ja of nee te zeggen. Dus de order, de ontvangst, de afwijking en wat de agent daarover heeft uitgezocht. Een goedkeurder die eerst zelf op zoek moet, keurt niet sneller goed.
6. Afletteren van betalingen en leveranciersopgaven
De factuur is betaald, en dan begint het laatste stuk handwerk. De bankmutatie moet tegen de openstaande posten, en dat gaat zelden een op een.
Waar het misgaat is elke keer hetzelfde. Eén betaling dekt dertig facturen af, met een betaalspecificatie die als PDF in een losse mail zit. Er is deelbetaald. Er is een creditnota verrekend die bij een factuur uit een vorige periode hoorde. Bij een reisdienstverlener op NetSuite kon een betaling van € 20,60 niet worden gekoppeld aan een factuur van € 20, omdat er een PayPal-fee overheen was gegaan. Datzelfde bedrijf beschrijft hoe teams met tussenrekeningen gaan schuiven om koersverschillen en fees weg te werken, puur omdat het ERP de match niet rondkrijgt.
Een agent leest de betaalspecificatie uit de bijlage, koppelt de regels aan de openstaande posten, en boekt het verschil weg volgens de regel die jij hebt vastgelegd: koersverschil, bankkosten, betalingskorting. Wat hij niet rond krijgt, komt bij je team met de kandidaten erbij in plaats van als een lege regel op een bankafschrift.
Hetzelfde geldt voor leveranciersopgaven. Wat staat er volgens de leverancier open, wat staat er volgens jou open, en welke facturen zitten in het verschil. Dieper hierop: reconciliatiesoftware en afletteren en bankmutaties afletteren in NetSuite.
Traditionele factuurverwerking tegenover AI-agents
Het verschil zit in de uitvoering. Traditionele software volgt regels die jij hebt bedacht. Agentic software is gebouwd voor de gevallen die je niet had bedacht, en dat zijn er in een crediteurenadministratie meer dan je zou willen.
| Taak | Traditionele verwerking | AI-agent |
|---|---|---|
| Facturenmailbox | Splitst niet tussen documentsoorten en entiteiten; iemand beoordeelt en zet door | Herkent het documenttype en de entiteit, verwerkt direct en beantwoordt vragen in de thread |
| Matchen | Matcht op regelniveau waar de gegevens exact aansluiten; wijkt de order af, dan wachtrij | Zoekt de order zelf op leverancier, bedrag en regels, en laat zien hoe zeker hij is |
| Coderen | Vaste positie per leverancier; uitzonderingen naar een mens | Per factuurregel over alle dimensies, kijkt naar historie en jouw instructies, leert van correcties |
| Verschil uitzoeken en mailen | Markeert de afwijking en zet hem in een wachtrij | Rekent na, haalt order, ontvangst en correspondentie erbij, mailt de leverancier of de collega en verwerkt het antwoord |
| Aanbieden ter goedkeuring | Vaste route naar een vaste rol | Bepaalt zelf de juiste goedkeurder en legt alles voor wat nodig is om te beslissen |
| Afletteren | Alleen de exacte match; de rest is handwerk | Leest de betaalspecificatie uit, koppelt deelbetalingen en verrekeningen, boekt het verschil volgens jouw regel |
| Boeken | Vaste regels, geen AI nodig | Ook hier vaste regels: deterministische code die jij in gewone taal hebt beschreven, geen inschatting van een model |
Die laatste rij is geen ontbrekende functie. Het is een ontwerpkeuze, en het is de belangrijkste zin in dit artikel.
Waar je juist geen handelingsvermogen wilt
Het is verleidelijk om te denken dat je zoveel mogelijk agent wilt. Er kunnen immers meer dingen worden opgelost.
Maar hoe meer vrijheid, hoe minder voorspelbaar. Een administratie heeft één eigenschap nodig die de meeste andere systemen niet nodig hebben: dezelfde invoer moet dezelfde uitkomst geven. Elke keer, ook over een jaar, ook als iemand het naloopt.
Een systeem dat deze factuur vandaag op 4300 boekt en volgende maand op 4310 omdat het de situatie anders inschatte, is onbruikbaar. Hoe redelijk die inschatting ook is. Je accountant vraagt waarom deze boeking zo gemaakt is, en "het model vond van wel" is geen antwoord.
Reken het ook even door. Een systeem dat in 95 procent van de gevallen gelijk heeft, klinkt uitstekend. Bij tweeduizend facturen per maand zijn dat honderd foute boekingen, en die allemaal terugvinden kost meer tijd dan ze zelf boeken had gekost. Erger nog: een systeem dat meestal klopt, leert je team om te stoppen met controleren. Dan blijven die honderd fouten onzichtbaar tot de accountant erover valt.
De verdeling die wel werkt is dus dezelfde als hierboven. De agent mag alles doen om erachter te komen wat er aan de hand is. Wat hij daarna in je ERP schrijft, volgt code die jij in gewone taal hebt beschreven en die je kunt teruglezen.
Waar het stopt
Drie dingen die een agent op crediteuren niet oplost, en die je van je leverancier moet horen voordat je tekent.
Onder de vijftig facturen per maand werkt het nog steeds, maar de vraag is of het genoeg oplevert. Technisch is er geen ondergrens. Een agent leert van herhaling, en bij weinig facturen is er minder om van te leren, maar de rekensom die telt is een andere: wat kost het je nu, en weegt de tijdwinst op tegen de prijs en de moeite van het inrichten. Bij vijftig facturen per maand is dat vaak een eerlijk nee. Vraag om die doorrekening voordat je begint, niet erna.
Wat je ERP niet aanbiedt, kan een agent er niet in schrijven. Dit is concreter dan het klinkt. In een pilot op Exact bleek de standaardgoedkeurder op leveranciersniveau niet uitleesbaar, simpelweg omdat Exact daar geen API voor heeft. Zulke ongedocumenteerde grenzen kom je pas tegen tijdens het bouwen. Vraag ernaar per proces dat je wilt automatiseren.
Soms wil je de goedkeuring helemaal niet buiten je ERP. Financeafdelingen houden goedkeuringsstromen vaak liever in NetSuite of Dynamics, omdat ze hun collega's dan geen tweede tool hoeven te leren en geen extra licenties hoeven te beheren. Dat is een goed argument. Een agent die daarin meebeweegt is beter dan een agent die zijn eigen goedkeuringsscherm oplegt.
Hoe je begint
Begin bij de uitzonderingen, niet bij het volume. Dat is de omkering die de meeste trajecten mist.
- Tel wat er blijft liggen. Niet hoeveel facturen je verwerkt, maar hoeveel er per maand blijven hangen en waarom. Die tweede lijst is je businesscase.
- Schrijf je tolerantieregels op. Die heb je al, ze staan alleen in iemands hoofd. Onder welk bedrag mag het door. Welk soort verschil is een afronding en welk soort is een prijsfout. Wie moet er meekijken boven welk bedrag.
- Bepaal per stap waar het handelingsvermogen mag zitten. Uitzoeken: ja. Boeken: nee, tenzij het via vastgelegde regels loopt.
- Zet het eerst onder toezicht. Het systeem stelt elke actie voor, je team keurt goed. Je ziet waar het klopt en waar niet, en daarna schuif jij de drempel op. Een leverancier die voorstelt om op dag één zelfstandig te draaien, moet je wantrouwen.
- Meet op doorlooptijd van de uitzondering. Niet op herkenningspercentage. Dat cijfer was al hoog voordat je begon.
Het risico is laag omdat je geen migratie ingaat. Je zet er iets naast dat één klus overneemt. Werkt het niet, dan zet je het uit en staat je administratie er precies zo bij als ervoor.
Veelgestelde vragen
Agentic software die zelf bepaalt welke stappen nodig zijn om een inkoopfactuur af te handelen: documenten herkennen, matchen tegen order en ontvangst, coderen op regelniveau, verschillen uitzoeken, de leverancier of een collega benaderen, de factuur ter goedkeuring aanbieden en de betaling afletteren. Hij werkt in je bestaande ERP en legt elke actie vast in een audit trail.
Die categorie is scan-en-herkensoftware: de factuur wordt gelezen, herkend en klaargezet voor boeking. Voor die laag werkt het goed. Wijkt de factuur af, dan signaleren ze dat en zetten ze hem in een wachtrij. Een agent gaat op dat punt uitzoeken waarom, en komt pas bij je team als dat niet lukt. Je hoeft ze niet te vervangen, want een agent kan er bovenop draaien op dezelfde mailbox en dezelfde ERP-data.
Stel één vraag aan de leverancier: wat gebeurt er met de factuur die niet matcht? Verschijnt hij in een lijst, of probeert het systeem eerst zelf uit te zoeken waarom? Het label AI-first of AI-native helpt je hier niet bij, want dat gaat over hoe het product gebouwd is en niet over wat het doet met jouw afwijkende factuur.
Dat hoeft niet eens de vraag te zijn. Al het werk vóór de boeking kan hij wel doen: uitzoeken waarom een factuur afwijkt, het ordernummer opsporen dat de leverancier verkeerd heeft genoteerd, een oplossing voorstellen en de mail klaarzetten. Bij Claridy is de boeking zelf deterministische code die jij in gewone taal hebt beschreven, geen inschatting van een model. De AI leest en zoekt uit, de regel beslist.
Dat hoort de kern te zijn. Boekt je team een regel een paar keer anders dan voorgesteld, dan moet dat daarna vanzelf goed gaan zonder dat iemand een instelling verandert. Vraag hier expliciet naar, want het is het verschil tussen software die beter wordt en software die onderhoud vraagt.
Ja, dat zijn de drie waar Claridy op draait: lezen en terugschrijven zonder eigen administratie ernaast. Per ERP verschilt wel wat er via de API beschikbaar is, en dat merk je pas in de details. Vraag per proces dat je wilt automatiseren of het echt kan.
Bij Claridy € 499 per maand vast, met 3-way matching voor € 250 extra per entiteit, maandelijks opzegbaar.[^bron1] Vergelijk dat met wat de uitzonderingen je nu kosten, niet met de prijs per factuur van je scansoftware. Die twee lossen verschillende dingen op.
Verwerking binnen de EU, read-only waar dat kan, en een exporteerbare audit trail per actie. Het SOC 2-traject loopt en de certificering komt eraan. Uitgebreider: is AI veilig voor je boekhouding.
Wat Claridy hier precies doet, staat op de productpagina's automatische factuurverwerking en procure-to-pay. Over de architectuur hierachter: wat is een system of action voor finance. Het onderscheid tussen automatisering, workflows en agents: AI-agents voor finance. Alle factuurverwerkingsleveranciers naast elkaar: de vergelijkingsgids. Dieper op matchen: 3-way matching op schaal.
Laatst gecontroleerd: 2026-08.