3-way matching automatiseren met AI: van inkooporder tot boeking (2026)

Wat 3-way matching is, waarom het in de praktijk handmatig werk blijft, en wat een systeem moet kunnen om de uitzonderingen wél af te handelen. Met cijfers uit ruim 20.000 Nederlandse finance-vacatures.

3-way matching is de controle die een inkoopfactuur vergelijkt met twee andere documenten: de inkooporder, met wat er besteld is en tegen welke prijs, en de goederenontvangst, met wat er echt geleverd is. Kloppen alle drie, dan mag de factuur geboekt en betaald worden zonder dat iemand ernaar kijkt.

Elk pakket voor factuurverwerking zegt tegenwoordig dat het dit met AI doet. Dat is een makkelijke claim, want het merendeel matcht vanzelf: één order, één levering, bedrag klopt. De vraag is wat er gebeurt met de rest.

Claridy in het kort

Werk je met inkooporders en goederenontvangsten, dan gaat dit over een fors deel van je crediteurenwerk. Uit onze analyse van ruim 20.000 Nederlandse finance-vacatures blijkt hoe ongelijk dat verdeeld is: bij bedrijven op NetSuite vraagt 12,7 procent van de vacatures expliciet om matchingwerk en bij Dynamics 12,3 procent, tegen 5,5 procent bij Exact. Ruim twee keer zo vaak dus. Eén kanttekening daarbij: grotere bedrijven zitten vaker op Dynamics, NetSuite en SAP, en werken ook vaker met inkooporders. Het ERP en de bedrijfsgrootte lopen in deze cijfers door elkaar.

Waarom bestaat het inkooporderproces?

Voordat je iets automatiseert loont het om te weten waar de controle vandaan komt, want dat bepaalt wat je niet mag weggooien. Er zijn vier redenen.

Functiescheiding. De drie documenten komen uit drie verschillende handen. Inkoop bestelt, het magazijn ontvangt, crediteuren betaalt. Niemand kan in zijn eentje een inkoop verzinnen én betaalbaar stellen. Dat is de reden dat het drie documenten zijn en geen twee, en het is de kern van je administratieve organisatie.

Je betaalt alleen voor wat je echt hebt gekregen. Te veel gefactureerd, een prijs die stilletjes omhoog is gegaan, dezelfde factuur twee keer, of een factuur van een leverancier bij wie nooit iets is besteld. Zonder de order en de ontvangst ernaast zie je dat niet aankomen.

Verplichtingen zijn zichtbaar vóór de uitgave. De order legt vast wat je hebt toegezegd. Je budget klopt dus op het moment van bestellen, en niet pas als de factuur binnenkomt.

Je cijfers vallen in de juiste periode. Bij ontvangst wordt de verplichting geboekt op de rekening "nog te ontvangen facturen", dus je resultaat klopt ook als de factuur pas volgende maand komt. En je voorraadwaarde klopt, omdat ontvangst en factuur op dezelfde orderregel landen.

Dit is dus een controle die je wilt hebben. Wij schreven eerder dat controle zelden het antwoord is op een proces dat niet gevolgd wordt, en dat blijft staan. Het verschil zit niet in de controle zelf maar in waar de wrijving terechtkomt. Kost het juiste pad twintig minuten, dan wijken mensen uit naar de omweg: de order die pas ná de factuur wordt aangemaakt, het bestaande leveranciersrecord dat er dicht genoeg bij zit. Kost het juiste pad geen moeite, dan houd je de controle én de naleving. Meer daarover: ondersteunen in plaats van controleren.

2-way of 3-way: wat vergelijk je waarmee?

De Engelse termen zijn ook in Nederland de gangbare. Je hoort zelden iemand over tweeweg- of drieweg-matching praten.

2-way matching: factuur tegen inkooporder. Je vergelijkt wat de leverancier factureert met wat je besteld hebt, tegen de prijs die je hebt afgesproken. Dat dekt twee van de vier redenen hierboven af: de uitgave is vooraf goedgekeurd en de verplichting stond al in je systeem. Wat het niet dekt is de vraag of je het ook daadwerkelijk hebt gekregen.

3-way matching: factuur tegen order én ontvangstbevestiging. Zodra je dat laatste wél wilt weten, heb je een derde bevestiging nodig van iemand anders dan de besteller en de betaler. Bij fysieke goederen is dat de goederenontvangst in het magazijn, en daar komt 3-way matching dan ook verreweg het vaakst voor. Maar het gaat niet om fysiek of niet-fysiek, het gaat om die onafhankelijke bevestiging. Bij diensten kan dat een afgetekende urenstaat zijn of een opleveringsbevestiging. Veel bedrijven registreren dat niet, en daarom is 2-way daar in de praktijk het werkbare antwoord.

Vuistregel: heb je een magazijn, dan heb je 3-way nodig, en dan is het ook wat je voorraadwaarde en je grootboek schoon houdt. Koop je vooral diensten in, dan is 2-way genoeg en zit het werk in het goedkeuringsproces in plaats van in de ontvangst.

Waarom mislukt 3-way matching in de praktijk?

Het simpele geval is geen probleem. Het werk zit in drie stappen, en het gaat in alle drie mis.

Stap 1: de juiste order vinden

Elk matchingpakket gaat ervan uit dat jouw inkoopordernummer op de factuur staat. Vaak staat het er niet, en wat er wél staat is meestal een nummer van een heel ander soort.

De leverancier zet zijn éigen ordernummer op de factuur. Je extractie leest dat keurig uit als inkoopordernummer, waarna het tegen niets matcht. Jouw inkoopordernummer staat wel ergens: in het referentieveld van je eigen order, waar de inkoper het heeft ingetypt toen hij bestelde.

Bij maakwerk wordt de order pas aangemaakt nádat de goederen binnen zijn, dus de leverancier kón het inkoopordernummer niet kennen. Wat er wel is, is een werkordernummer, en dat is waarop gematcht moet worden.

Soms staat het inkoopordernummer helemaal niet op de factuur maar in de bijlage: een pakbon, een vrachtbrief, een Excel met een specificatie erin.

En als er niets bruikbaars is, blijft de omweg over: het verzendnummer op de factuur tegen het referentieveld van de goederenontvangst, en van daaruit naar de order.

Vier routes dus, naar hetzelfde doel, en welke er geldt verschilt per leverancier. Soms ligt de verbinding in je ERP, soms in een document dat als bijlage meekomt. Een pakket dat één route kent, faalt op de andere drie.

Stap 2: de regels aan elkaar koppelen

Matchen op ordertotaal werkt niet zodra er deelleveringen zijn of meerdere orders op één factuur staan. Het moet per regel. Alleen: waarop koppel je een factuurregel aan een orderregel?

Er is geen universeel kenmerk. Bij de ene leverancier is het je eigen artikelnummer, bij de andere hún artikelnummer, en bij de meeste is er geen bruikbaar nummer en blijft alleen de omschrijving over. Die moet dan genormaliseerd worden op product, variant en formaat, en bevestigd met hoeveelheid en bedrag.

Dan de eenheden. Eén leverancier factureert per stuk terwijl je order in zespakken staat, dus alles moet door zes. Een andere factureert in tonnen waar je order in kilo's staat. Dat is geen algemene regel maar een tabel per leverancier en per artikel, en je ontdekt een nieuwe pas als hij stukloopt.

En vergelijken doe je tegen wat er ontvangen is, niet tegen wat er besteld is. Inkoop mag meer ontvangen dan besteld; dat wordt goedgekeurd en als voorraad geboekt. De juiste vergelijking is ontvangen min al gefactureerd, cumulatief bijgehouden per orderregel, omdat er meerdere facturen op één regel kunnen landen.

Stap 3: het verschil verklaren

Hier gaat het meeste mis, en hier zit het belangrijkste onderscheid van het hele proces. Een verschil tussen order en factuur heeft drie oorzaken, en die horen bij drie verschillende mensen.

Dat onderscheid is het verschil tussen een werkend systeem en een uitzonderingenbak. Een tolerantie van een half procent kent het verschil niet: die accepteert een afronding van drie cent en een prijsfout van drie cent op precies dezelfde manier, en die tweede had iemand moeten zien.

Wat als de factuur eerder komt dan de goederen?

Dit is geen fout, en toch behandelen de meeste systemen het als een fout. Leveranciers sturen de factuur mee met de zending, het transport doet er een paar dagen over, en de match faalt dus op iets dat over drie dagen vanzelf klopt.

De juiste behandeling is de factuur vasthouden en de controle dagelijks opnieuw draaien tot de ontvangst er is, en de rekening "nog te ontvangen facturen" wekelijks aflopen om te zien wat er sindsdien is dichtgekomen. Afkeuren en terugsturen is het verkeerde antwoord op een probleem dat alleen over timing gaat.

Wat moet AI kunnen om 3-way matching te automatiseren?

Vijf dingen, en alleen het eerste gaat over lezen.

Lezen is niet het moeilijke deel. Herkenning is de afgelopen jaren echt beter geworden: velden en regels worden nauwkeurig uitgelezen, ook uit een lay-out die je nooit eerder zag. Maar bij matching was het lezen zelden het knelpunt. Als het nummer dat op de factuur staat het ordernummer van de léverancier is, helpt beter lezen je niet.

Doorredeneren naar de juiste order. Dit is waar het echt begint. Het inkoopordernummer staat er niet, dus: welk soort nummer staat er dan wel, waar in het ERP zou het inkoopordernummer kunnen staan, zit het misschien in de bijlage, of kom ik er via de pakbon? Dat is geen extractie maar een zoektocht met meerdere routes, waarbij het systeem moet weten welke route bij welke leverancier hoort.

Het verschil uitrekenen, op regelniveau. Eenheden omrekenen. Cumulatief bijhouden wat er per orderregel al gefactureerd is. Ontvangen min gefactureerd bepalen. Het exacte bedrag van de afwijking berekenen in plaats van alleen constateren dat er een afwijking is.

Begrijpen waardoor het komt. Een verschil van € 0,03 is een afronding of een prijsfout, en dat is niet aan de tolerantie te zien maar aan de oorzaak. Het systeem moet die oorzaak vaststellen, want die bepaalt wie het oplost. En ook bij een afronding moet er iets gebeuren: zolang het verschil er staat blokkeert het de boeking, dus er moet een extra regel worden aangemaakt voordat de factuur het ERP in kan.

De context erbij halen die niet in je ERP staat. Hier wordt het interessant, en hier ligt de lat. De leverancier mailt dat hij 80 stuks stuurt in plaats van 100 en dat de rest volgende week komt. Of hij kondigt een creditnota aan. Of er zit een bericht bij dat een artikel is vervangen door een gelijkwaardig alternatief met een ander artikelnummer. Een medewerker die die mail heeft gelezen keurt de factuur voor 80 stuks gewoon goed en escaleert niets, want zij wéét het al. Een regelmotor ziet een hoeveelheidsverschil en stopt.

Het verschil tussen een systeem dat naar je factuurregels kijkt en een systeem dat functioneert als collega zit precies daar. Kan het de mail, de bijlage of het bericht in de leveranciersmailbox vinden waarin de afwijking al is uitgelegd, dat koppelen aan déze factuur en déze orderregel, en op grond daarvan besluiten dat er niets aan de hand is? Dat is de standaard waaraan je een systeem zou moeten meten, want dat is wat de mens die je wilt ontlasten de hele dag doet.

En dan komt het laatste, en daar houden de meeste pakketten op. Ze signaleren. Er verschijnt een uitzondering in een lijst, en daarna is het weer mensenwerk: uitzoeken wat er aan de hand is, de order erbij pakken, de ontvangst opzoeken, een mail typen.

Wat doet het systeem als er iets niet klopt?

Bij een hoeveelheidsverschil gaat er een mail naar supply chain, met het ordernummer, de ontvangst, de gefactureerde en de ontvangen aantallen, en het verschil al uitgerekend. Niet "er is een afwijking", maar welke regel, hoeveel, en tegen welke ontvangst.

Bij een materieel prijsverschil gaat er een mail naar degene die de orders beheert, met de orderprijs, de factuurprijs en het bedrag dat het scheelt, zodat die de order kan bijwerken. Daarna wordt automatisch opnieuw gematcht.

Bij een ontbrekende ontvangst of een ontbrekende pakbon gaat er een bericht naar de leverancier, met de order erbij.

Is de afwijking al ergens uitgelegd, in een mail van de leverancier of in een bijlage bij de factuur, dan wordt die eerst opgezocht. Staat daar dat er 80 in plaats van 100 zijn verstuurd en dat de rest volgt, dan is er geen verschil om te escaleren maar een deellevering om te verwerken. Er komt pas iemand aan te pas als die uitleg er niet is.

Bij een afronding gebeurt er niets menselijks. Er moet wel een extra regel worden aangemaakt, want anders blokkeert het verschil de boeking. Waar die regel heen gaat bepaal jij: op voorraadverschillen, of als extra regel op de inkooporder zodat voorraad en crediteuren weer in balans komen.

Bij een factuur die te vroeg is wordt niets afgekeurd. De factuur wordt vastgehouden en de controle draait morgen opnieuw.

En als alles klopt, is de actie de boeking zelf: de factuur gaat het ERP in met elke regel gekoppeld aan de juiste orderregel, en dáármee loopt de rekening "nog te ontvangen facturen" vanzelf leeg. Dat is het verschil tussen een systeem dat je werk toont en een systeem dat je werk doet.

Heb je matchingsoftware, of een intelligent systeem?

Generatie 1 is OCR met regels: een sjabloon per leverancier, een boekingsregel per situatie. Werkt zolang alles is zoals je het van tevoren hebt bedacht, en stap 1 is meteen fataal.

Generatie 2 is diezelfde architectuur met een AI-laag op de herkenning. Het lezen werd beter, de verwerking bleef een regelmotor. Eén tolerantie, geen onderscheid tussen een afronding en een prijsfout, en nog steeds geen tweede route naar het inkoopordernummer.

Generatie 3 begint niet bij het lezen maar bij het werk: doorredeneren, uitrekenen, verklaren, context erbij halen, handelen. Dat is geen betere herkenning, dat is oordeel dat als regel is vastgelegd en daarna elke keer identiek draait.

De vraag om aan een leverancier te stellen is dus niet of hij 3-way matching doet. Dat doet iedereen. De vraag is wat er gebeurt met de factuur waar het inkoopordernummer niet op staat, en wie er een mail krijgt als de aantallen niet kloppen.

Meer over de drie generaties en welk pakket in welke zit: de vergelijkingsgids factuurverwerkingssoftware. Zoek je specifiek een alternatief voor je huidige pakket, dan gaan we daar dieper op in bij alternatieven voor Blue10.

Kan Exact, NetSuite of Dynamics 3-way matching zelf?

Alle grote ERP's kennen het concept. Het verschil zit in wat er gebeurt zodra een factuur afwijkt van het standaardpad.

Hoe Claridy het doet

Claridy zoekt eerst de order en kent alle vier de routes: jouw ordernummer op de factuur, het ordernummer van de leverancier in je eigen referentieveld, een werkordernummer bij maakwerk, en de omweg via het verzendnummer op de pakbon. Per leverancier vastgelegd, niet per factuur geraden.

Daarna wordt elke factuurregel aan één orderregel gekoppeld, op artikelnummer waar dat bestaat en op genormaliseerde omschrijving waar het niet bestaat, met de eenheidsomrekening per leverancier erbij. Vergeleken wordt er tegen ontvangen min gefactureerd, cumulatief bijgehouden.

Verschillen worden uit elkaar getrokken en krijgen elk hun eigen actie, zoals hierboven beschreven. Bijlagen en de leveranciersmailbox worden meegelezen, want daar staat vaak de uitleg die het verschil verklaart.

Jij beschrijft de spelregels in gewone taal: afrondingen tot een halve cent per regel automatisch boeken, prijsafwijkingen boven de twee procent naar inkoop, transportkosten altijd naar kostenplaats logistiek. Die beschrijving wordt deterministische logica, dus dezelfde factuur geeft altijd dezelfde uitkomst en elke stap staat in de audit trail. Elke correctie van je team wordt een regel, dus dezelfde uitzondering komt geen tweede keer terug.

Bij een groep die wij analyseerden had 91 procent van de facturen een order, en daarvan matchte 95 procent regel voor regel. Dat is 86 procent van alle facturen die zonder mens door kan. De overige 14 procent, de facturen zonder order en de regels die echt afwijken, blijft bij je team, met het voorwerk gedaan.

Wil je weten wat het handmatige werk je nu kost, dan reken je dat na met de ROI-calculator. En de andere kant van hetzelfde werk, het afletteren van binnenkomende betalingen, staat in de gids over bankmutaties verwerken en afletteren.

Veelgestelde vragen

Bron vacature-analyse: Claridy-analyse van 21.642 Nederlandse finance-vacatures, 2026, taken geclassificeerd met AI volgens onze eigen rubriek. Laatst gecontroleerd: 2026-08.