Je ERP bewaart wat er gebeurd is. Je factuurverwerkingssoftware krijgt data naar binnen. Geen van beide doet het werk. Wat een systeem nodig heeft om dat wél te doen, waarom één systeem niet allebei kan zijn, en waarom betrouwbaarheid het moeilijke deel is.
Een boekhoudsysteem is een archief. Het legt vast wat er is gebeurd, in een vorm waarin een accountant het kan controleren. Dat is precies wat je van een system of record verwacht, en het is de reden dat ERP's decennia meegaan.
Daarvoor zit je factuurverwerkingssoftware. Dat is een system of intake: het haalt de factuur uit de mailbox, leest de velden eruit, koppelt hem aan de juiste leverancier en stuurt hem naar degene die hem moet goedkeuren. In die stap zit twintig jaar softwareontwikkeling, en hij werkt. Overtypen is een opgelost probleem.
Wat geen van beide doet, is het werk.
Wat is een system of action?
Een system of action is een systeem dat het werk uitvoert in plaats van het vast te leggen of klaar te zetten: het begrijpt documenten, haalt de context erbij die het nodig heeft, en handelt binnen regels die jij hebt vastgelegd, in je bestaande systemen, met elke actie in een audit trail.
Het werk waar het over gaat zit tussen de twee bestaande lagen in. De factuur matcht niet met de order en iemand moet uitzoeken waarom. De leverancier mailt of factuur 24019 al betaald is. Er komt een bedrag binnen op de bankrekening dat bij veertien facturen hoort, met de specificatie als PDF in een aparte mail. Een kostenpost moet op een project geboekt worden dat niet op de factuur staat.
Dat is geen invoerwerk en geen archiefwerk. Het is werk dat oordeel vraagt, en het is precies het deel dat overbleef nadat het overtypen was geautomatiseerd. Het wordt bovendien stelselmatig onderschat, omdat het tussen de systemen in valt: het staat in niemands functieomschrijving, en er is nooit software voor gekocht.
De drie lagen naast elkaar
| Laag | Wat het doet | Voorbeeld | Wat er gebeurt als iets niet klopt |
|---|---|---|---|
| System of record | Vastleggen wat er gebeurd is | Exact, NetSuite, Microsoft Dynamics | De post blijft openstaan tot een mens hem oplost |
| System of intake | Documenten naar binnen krijgen en klaarzetten | Blue10, Basecone, Zenvoices, TriFact365 | Er verschijnt een uitzondering in een lijst voor een mens |
| System of action | Het werk uitvoeren binnen jouw regels | Claridy | De agent probeert het eerst zelf; lukt dat niet, dan gaat het naar een mens met het voorwerk gedaan |
Die laatste kolom is het hele verschil. Niet wat het systeem kan, maar waar het werk terechtkomt als het misgaat.
Een voorbeeld dat echt speelde
Een foodmerk op Exact Online koopt in bij een leverancier die met zes decimalen rekent. Exact rekent met twee. Ze bestellen 5.200 stuks tegen € 12,96, ze ontvangen ze, en de factuur komt binnen tegen € 12,955678 per stuk.
Nu staat er voor € 67.392,00 aan voorraad in de boeken, en factureert de leverancier € 67.369,53. Tweeëntwintig euro en zevenenveertig cent verschil op een factuur waar niemand iets fout heeft gedaan. De leverancier factureert correct, de order klopt, de ontvangst klopt.
Toch sluit het niet. De ontvangst is voor € 67.392,00 op de tussenrekening gezet en de factuur haalt daar € 67.369,53 af. Wat overblijft, blijft staan.
Zo ziet dat eruit in de drie lagen.
Het ERP legt beide getallen vast en signaleert niets. Dat is ook niet zijn taak.
De factuurverwerkingssoftware ziet een verschil en kijkt of dat binnen de tolerantie valt. Binnen: hij laat het door en het verschil blijft in de boeken staan. Buiten: hij zet de factuur in een lijst met uitzonderingen. In beide gevallen is de volgende actie een mens die uitzoekt of dit een afrondingsverschil is of een prijsfout, want een tolerantiepercentage kan die twee niet uit elkaar houden.
Een system of action rekent het na, stelt vast dat de prijs per stuk klopt en dat het verschil ontstaat door het aantal decimalen, en maakt de regel aan die nodig is om de boeking te laten sluiten. Er komt pas een mens aan te pas als het géén afronding blijkt te zijn.
Dat is geen slimmer systeem. Dat is een systeem dat de volgende stap zet in plaats van hem te tonen.
Waarom één systeem niet allebei kan zijn
De verleiding ligt voor de hand: als je toch al de order, de ontvangst en de factuur leest, waarom bewaar je ze dan niet gewoon zelf?
Doe dat niet, en accepteer het ook niet van een leverancier. Niet omdat het technisch niet kan, maar omdat het twee onverenigbare bouwopgaven zijn.
Een system of record moet stabiel en voorspelbaar zijn. Hetzelfde saldo, elke keer, jaren achtereen, controleerbaar door iemand van buiten. Een system of action moet juist omgaan met de willekeur van de echte wereld: een factuur die anders is opgemaakt, een leverancier die zijn afspraak anders uitlegt, een mail die een afwijking verklaart. Het eerste vraagt om rigide regels die alle randgevallen afvangen. Het tweede vraagt om een systeem dat interpreteert en tóch deterministisch handelt op het moment dat het deterministisch moet zijn. Dat zijn verschillende takken van sport, en teams die allebei proberen worden in geen van beide goed.
Er is ook een praktisch bezwaar. Zodra de actielaag zijn eigen waarheid bijhoudt, heb je twee administraties die uit elkaar kunnen lopen. Je accountant controleert er één, je team werkt in de andere, en het verschil ontdek je bij de jaarrekening. Bovendien verandert de invoering dan van "we zetten er iets naast" in "we migreren", en dat is precies het project dat niemand wil.
Het onderscheid is dus niet dat de actielaag naast je ERP draait, want dat zegt inmiddels iedereen in deze categorie. Het onderscheid is dat hij bewust geen geheugen van waarheid heeft. Hij leest uit je ERP, hij schrijft ernaartoe, en wat hij zelf onthoudt zijn regels en beslissingen, niet saldi. Het archief blijft één archief.
Waarom je ermee moet kunnen stoppen
Dat heeft een prettig gevolg. Zet je de actielaag uit, dan staat je administratie er precies zo bij als ervoor. Geen migratie terug, geen export, geen conversie. Je hebt een maand geleden een laag aangezet en je zet hem weer uit.
Bij een systeem dat zijn eigen boekhouding bijhoudt kan dat niet. Daar zit je waarheid inmiddels op twee plekken, en eruit stappen is zelf een project geworden.
Dat is het verschil tussen een laag en een lock-in, en het is de vraag die je moet stellen aan iedere leverancier in deze categorie die zegt dat hij naast je ERP draait: als ik over een jaar stop, wat moet ik dan doen?
Waarom bouwt je ERP dit niet gewoon zelf?
Dat gaan ze ook proberen, en een aandeelhouder die dat niet eist doet zijn werk niet. Maar er is een reden waarom dat het probleem niet oplost, en die zit in de rekensom.
Je hebt nooit één system of record. Je hebt een boekhoudsysteem, een CRM, een documentsysteem, een HR-systeem, ergens een datawarehouse. Als elk van die systemen zijn eigen agent bouwt, dan moet de agent van je boekhouding bij je mail kunnen, bij je Drive, bij je CRM. En de agent van je CRM moet bij je boekhouding kunnen, en bij je documenten. Dat is geen lijstje koppelingen meer maar een web dat kwadratisch groeit met het aantal systemen.
Kijk er vanuit beveiliging naar en de vraag beantwoordt zichzelf. Wil je twintig systemen die elk toegang hebben tot de negentien andere, met twintig rechtenmodellen om bij te houden? Of wil je één punt waar de toegang samenkomt, zoals bij een medewerker, waar je in één audit trail ziet wat er is gedaan en waarom?
Dat is de reden dat de actielaag een aparte laag hoort te zijn, en niet een functie in elk systeem afzonderlijk.
Wat dit betekent voor je ERP
Als een groeiend deel van het gebruik van een agent komt en niet van een mens, verandert wat een goed system of record is. De schermen worden minder belangrijk, en bereikbaarheid wordt het criterium: goed gedocumenteerde API's, weinig uitzonderingen, geen certificeringstraject voordat je een koppeling mag bouwen.
Dat is in het voordeel van systemen met een matige gebruikersinterface maar een goede API. Wij zien teams die op het punt stonden over te stappen naar een zwaarder ERP, die overstap uitstellen zodra het werk in het bestaande systeem wél gedaan wordt. De reden om over te stappen was zelden het systeem zelf, het waren de uren die het kostte om ermee te werken.
Eén technische kanttekening die de moeite waard is: wij werken rechtstreeks op de API's van de ERP's en niet via de standaard MCP-koppelingen die leveranciers aanbieden. Die abstractielaag ligt te hoog voor dit werk. Je hebt toegang nodig tot de velden waar het echt op vastloopt, zoals het referentieveld op een inkooporder waar de inkoper het ordernummer van de leverancier heeft ingetypt.
"Maar mijn software doet dit al"
Dat is de eerste reactie, en vaak is hij terecht. Facturen inboeken is een opgelost probleem, en als jouw software dat goed doet, moet je er niets anders voor kopen.
De betere vraag is niet wat je software kan, maar waar je team de dag aan besteedt. Wij vragen dat inmiddels standaard, en het antwoord gaat bijna nooit over de stap die de software doet. Het gaat over de stap ervoor of erna. Voordat de factuur naar de verwerking gaat, controleert iemand eerst handmatig of de bestelling wel is goedgekeurd, want dat kan het systeem niet. Dat is vier uur per week, van één persoon, en het staat in geen enkele demo.
Wij hebben 21.642 Nederlandse finance-vacatures doorgenomen en per genoemde taak bekeken of die direct te automatiseren is.
Hoe verder je van het invoeren af komt, hoe minder er automatisch gaat, en dat is precies het werk dat niemand heeft gekocht en dat toch iedere dag gebeurt.
Waarom is dit niet gewoon "AI erbovenop"?
Hier gaat de discussie meestal mis, en niet zonder reden: veel leveranciers van bestaande software hebben er een AI-laagje op geplakt en gouden bergen beloofd. Wie daar een keer zijn neus heeft gestoten, is terecht wantrouwig.
Het verschil is betrouwbaarheid. Een systeem dat in 95 procent van de gevallen gelijk heeft, klinkt uitstekend. In een boekhouding is het onbruikbaar. Vijf procent van tweeduizend facturen per maand is honderd foute boekingen, en ze allemaal terugvinden kost meer tijd dan ze zelf boeken had gekost. Erger nog: een systeem dat meestal klopt, leert je team om niet meer te controleren. Dan zijn die honderd fouten onzichtbaar tot de accountant erover valt.
Daarom is de bouwvorm die werkt niet "AI die beslist", maar een scheiding: de AI leest, de regel beslist. Dat klinkt tegenstrijdig voor een AI-product, maar dat is het niet. Hoe minder AI er in de daadwerkelijke uitvoering zit, hoe voorspelbaarder het werk wordt. De AI doet waar zij goed in is, namelijk taal en context begrijpen: welke regel op de factuur hoort bij welke orderregel, wat de leverancier in zijn mail bedoelt, welk project genoemd wordt. Wat er vervolgens gebeurt, is deterministische logica die jij hebt vastgelegd en die elke keer identiek draait.
Leg je één keer uit hoe jouw crediteurenproces werkt, dan wil je niet dat het systeem de maand erna creatief wordt en het anders doet. Het moet hetzelfde blijven, met interpretatie alleen op de plekken waar interpretatie hoort.
Dat is ook wat het onderscheidt van een regelsysteem uit de vorige generatie. Daar moest jij vooraf elke situatie bedenken en als regel invoeren. Hier beschrijf je in gewone taal hoe er verwerkt moet worden, inclusief je uitzonderingen, en dat wordt code. Corrigeert je team een boeking, dan wordt die correctie zelf een regel. Je onderhoudt geen regels, je werkt iemand in.
Eerst onder toezicht, daarna zelfstandig
Een system of action hoort niet op dag één zelfstandig te draaien, en een leverancier die dat belooft moet je wantrouwen. De volgorde die werkt: eerst stelt het systeem elke actie voor en keurt jouw team goed. Je ziet waar het goed zit en waar niet. Vervolgens zet je een drempel: boven een bepaalde zekerheid voert het systeem zelf uit, daaronder gaat het naar je team. Die drempel schuif jij op, op basis van wat je hebt zien gebeuren, niet op basis van wat de leverancier beloofde.
Het aardige is dat het risico van proberen laag is, en structureel lager dan bij de vorige generatie. Je gaat geen migratie in. Je zet er iets naast dat één klus overneemt. Werkt het, dan breid je uit. Werkt het niet, dan zet je het uit.
Wat dit betekent voor de prijs
Deze categorie verandert ook waar je voor betaalt, en dat is geen bijzaak.
Een system of record beprijs je per gebruiker. Logisch: het is een archief waar mensen in kijken. Een system of intake beprijs je per document, want het verwerkt stuks.
Bij een system of action klopt geen van beide. Per gebruiker slaat nergens op, want het doel is juist dat er minder mensen in het scherm hoeven. Per document is ook raar, want een factuur die volledig automatisch doorgaat en een factuur waarvoor het systeem drie bronnen erbij haalt en de leverancier mailt, zijn niet hetzelfde product.
Wat overblijft is afrekenen op afgemaakt werk. Daar hoort één eerlijke kanttekening bij die klassieke software niet had: er zitten echte variabele kosten onder. Meer werk laten doen kost meer, en een leverancier die dat wegmoffelt, verrekent het later ergens anders.
Wij hebben dat vertaald naar een vast maandbedrag per volumeband in plaats van een prijs per verwerkte eenheid. Niet omdat afrekenen op uitkomst verkeerd is, maar omdat de waarde voor een finance-team vaak in de voorspelbaarheid zit. Wie een budget moet halen, betaalt liever iets meer met zekerheid dan iets minder met een rekening die kan uitschieten. Andere leveranciers in deze categorie kiezen bewust voor afrekenen per afgeronde taak, en dat is net zo verdedigbaar. Wat je niet meer hoeft te accepteren is een prijs per gebruiker voor software die juist bedoeld is om gebruikers uit het proces te halen.
Waar het ophoudt
Een system of action neemt de uitzondering niet weg, het bereidt hem voor. De factuur waar echt een beslissing over moet worden genomen, de leverancier die zijn afspraak anders uitlegt dan jij, de kosten die niemand had begroot: die komen bij een mens terecht. Het verschil is dat ze aankomen met het uitzoekwerk gedaan, in plaats van als een regel in een wachtrij.
En het strategische werk blijft mensenwerk. Uitleggen waaróm een keuze is gemaakt, een investeerdersgesprek voeren, de afweging maken die niemand in een regel kan gieten: daar gaat dit niet over. Waar het wel over gaat, is al het voorbereidende werk tot aan dat punt.
Bij lage volumes speelt dit allemaal niet. Onder de circa honderd facturen per maand zit er te weinig herhaling in om iets te leren.
De vraag die je een leverancier stelt
Niet of er AI in zit. Dat zegt inmiddels iedereen. De vraag is: wat gebeurt er met de factuur die niet matcht? Verschijnt hij in een lijst, of probeert het systeem eerst zelf uit te zoeken waarom, en komt hij pas bij mijn team als dat niet lukt?
Het antwoord daarop is het verschil tussen software die je werk toont en software die je werk doet.
Veelgestelde vragen
Een systeem dat niet alleen data vastlegt of binnenhaalt, maar het werk uitvoert: documenten begrijpen, de context erbij halen, en binnen vastgelegde regels handelen in je bestaande systemen, met elke actie in een audit trail.
Een system of record, zoals je ERP, bewaart wat er is gebeurd. Een system of action zorgt dat het gebeurt. Ze vervangen elkaar niet: de actielaag schrijft naar het record, en je boekhouding blijft staan waar hij staat. Het praktische onderscheid: bij een system of record gaat elke uitzondering naar een mens, bij een system of action eerst naar de agent.
Technisch kan het, verstandig is het niet. Een system of record moet stabiel en voorspelbaar zijn, een system of action moet omgaan met alles wat afwijkt. Dat zijn verschillende bouwopgaven, en een systeem dat zijn eigen waarheid bijhoudt levert bovendien twee administraties op die uit elkaar kunnen lopen.
Dat proberen ze. Het probleem is dat je nooit één system of record hebt. Als elk systeem zijn eigen agent krijgt, moet elk systeem toegang krijgen tot alle andere, en dat web groeit kwadratisch. Eén laag met één auditeerbaar toegangspunt is beheersbaar, twintig agents met wederzijdse toegang niet.
Agent is hoe het gebouwd is, system of action is wat het moet opleveren. Het onderscheid dat telt is niet of er een agent in zit, maar of de AI beslist of alleen leest. Bij ons leest de AI en beslist de regel.
Nee, en dat hoeft ook niet. Werk eerst onder toezicht, met elke actie als voorstel, en zet daarna zelf de drempel waarboven het systeem zelfstandig uitvoert. Elke boeking blijft herleidbaar tot de regel en de bron waarop hij gebaseerd is.
Dat is precies waarom de beslissing deterministisch moet zijn. Een boeking die uit een regel volgt, is uit te leggen en te herhalen. Een boeking die uit een voorspelling volgt, is dat niet.
Nee, en dat is het punt. Je zet er iets naast dat één klus overneemt. Bevalt het niet, dan zet je het uit en is er niets veranderd aan je administratie.
Meer over hoe de drie generaties techniek zich tot elkaar verhouden: de vergelijkingsgids factuurverwerkingssoftware. Het afrondingsvoorbeeld staat uitgewerkt in het artikel over 3-way matching. Wil je weten wat het handmatige werk je nu kost: de ROI-calculator.
Bron vacature-analyse: Claridy, 21.642 Nederlandse finance-vacatures, 2026. Laatst gecontroleerd: 2026-08.