Leer driewegmatching-automatisering met praktische tabelontwerpen en een visuele workflow die betalingen vasthoudt totdat PO, ontvangst en factuur aantallen en prijzen overeenkomen.
Driewegmatching-automatisering is eenvoudig: je betaalt een factuur alleen wanneer deze overeenkomt met wat je hebt besteld en wat je daadwerkelijk hebt ontvangen. De drie documenten zijn de inkooporder (PO), het ontvangstbewijs (receipt) en de leveranciersfactuur (invoice).
Zonder deze controle kan accounts payable betalen op basis van één verkeerd of onvolledig document. Een leverancier kan meer eenheden factureren dan geleverd zijn, een andere prijs gebruiken dan afgesproken, of een dubbele factuur sturen die in een e-mailthread als nieuw lijkt.
Deze fouten zien er zelden dramatisch uit op dag één. Ze verschijnen als kleine lekken: een regelpost twee keer gefactureerd, een zending die een paar eenheden te kort is, een prijsverhoging die nooit is goedgekeurd, of vrachtkosten die onterecht zijn toegevoegd. Na verloop van tijd worden die kleine fouten echte kosten.
Het doel is niet simpelweg om "facturen goed te keuren." Het doel is betalingen te blokkeren totdat de sleutelvelden die je kiest (meestal hoeveelheid, eenheidsprijs en totalen) overeenkomen tussen PO, ontvangst en factuur. Als ze niet overeenkomen, zou de factuur niet in e-mail moeten verdwijnen. Ze moet in een uitzonderingswachtrij terechtkomen met een duidelijke reden-code en de exacte velden die verschillen.
Driewegmatching legt ook een duidelijke scheidslijn tussen teams. Inkoop is verantwoordelijk voor wat is besteld (voorwaarden en prijs). Ontvangst bevestigt wat er is aangekomen (hoeveelheden en data). Finance bepaalt wat wordt betaald (factuurcontrole en vrijgave).
Stel verwachtingen vroeg: dit is een proces- en datavraagstuk, geen simpele goedkeuringsknop. Als PO-regels vaag zijn, ontvangsten niet worden vastgelegd, of facturen niet aan een PO-regel zijn te koppelen, zal automatisering je niet redden.
Driewegmatching werkt alleen wanneer elk document een duidelijke eigenaar heeft. Als "wie wat bijwerkt" vaag is, blokkeert het systeem ofwel te veel goede betalingen (waardoor mensen omzeilen), of het laat slechte betalingen door.
Een praktisch eigendomsmodel is:
Elk document heeft ook een minimale set velden nodig zodat matching geen giswerk is.
PO (purchase order) heeft leverancier-ID, PO-nummer, regelitems (SKU of dienst), bestelde hoeveelheid, eenheidsprijs, valuta, belastingregels en betalingsvoorwaarden nodig.
Ontvangst heeft een PO-referentie, ontvangstdatum, ontvangen hoeveelheden per PO-regel en wie het heeft ontvangen nodig. Voor diensten behandel je het als acceptatie en registreer je de goedkeurder.
Factuur heeft leverancierfactuurnummer, factuurdatum, PO-referentie (of een veilige manier om de PO te vinden), regeldetails (aantallen, eenheidsprijs), belastingen/verzending en het totaal nodig.
Bepaal ook wanneer de match draait. Het moet geen éénmalig evenement zijn. Trigger het telkens wanneer de werkelijkheid verandert:
Gedeeltelijke ontvangsten en meerdere facturen zijn normaal. Een PO-regel kan in drie leveringen binnenkomen en over twee facturen worden gefactureerd. Je logica moet cumulatief ontvangen versus cumulatief gefactureerd per PO-regel vergelijken, niet slechts één document tegelijk.
Voordat je tabellen of workflowstappen aanraakt, stem af op de regels die het hele systeem zullen sturen. Vage regels creëren voorspelbare fouten: ofwel blokkeert het systeem te veel (waardoor mensen het omzeilen), of het blokkeert te weinig (waardoor slechte facturen toch betaald worden).
Kies het matchniveau. Alleen op header-niveau matchen controleert totalen op documentniveau. Dat klinkt makkelijker, maar faalt snel bij gedeeltelijke leveringen, nabestellingen, vrachtregels of gemixte belastingtarieven. Matching op regel-niveau kost meer tijd om op te zetten, maar is de veiligere standaard omdat je hetzelfde vergelijkt tussen PO, ontvangst en factuur: de specifieke regel, de hoeveelheid en de eenheidsprijs.
Definieer harde blokkades vs waarschuwingen. Een harde blokkade betekent dat betaling niet kan doorgaan totdat het probleem is opgelost. Een waarschuwing betekent dat de factuur door kan gaan, maar dat iemand het risico moet erkennen.
Typische startpunten:
Houd toleranties expliciet. Definieer de methode (percentage, absoluut bedrag, of het hoogste van de twee) en wie het beheert. Voorbeeld: toegestaan +/- 1% of +/- $5 per regel, waarbij finance toleranties alleen mag wijzigen met een auditnotitie.
Gebruik een kleine, gedeelde set statussen. Vermijd aangepaste statussen per team. Een eenvoudige set is meestal genoeg: Matched, Hold, Exception, Approved. "Hold" betekent dat betaling is geblokkeerd. "Exception" betekent dat een mens het moet beoordelen. "Approved" betekent dat een benoemde persoon de afwijking heeft geaccepteerd en vastgelegd waarom.
Driewegmatching-automatisering werkt alleen als je datamodel een PO-regel, wat er is ontvangen en wat er is gefactureerd aan elkaar kan koppelen. Elke factuurregel moet matchbaar zijn met een specifieke PO-regel (of duidelijk gemarkeerd als non-PO), en elke ontvangstregel moet de resterende hoeveelheid op die PO-regel verminderen.
Begin met kerntabellen voor inkoop:
Ontvangsten hebben hun eigen records nodig, zelfs als een "receipt" slechts een bevestiging is. Houd ontvangsten gescheiden van facturen zodat je kunt aantonen wat en wanneer is aangekomen:
Facturering weerspiegelt ontvangst. Sla op wat de leverancier per regel in rekening bracht en koppel het aan de PO-regel die het zou moeten dekken:
Maak ten slotte een betalingsgericht record dat je workflow kan blokkeren. Sommige teams noemen dit een bill, payment request of pay run item:
Voor audit en nette uitzonderingafhandeling voeg consistente lifecycle-velden toe op headers (POs, ontvangsten, facturen, betalingen): status, created_at/created_by, approved_at/approved_by, posted_at, en (optioneel) source_document_id voor imports.
Matching werkt het beste wanneer elk document terug te leiden is naar hetzelfde regelitem. Dat betekent stabiele ID's, schone links en totalen die uit de regels kunnen worden herberekend.
Zorg dat elke tabel zowel een stabiele interne ID als het externe nummer heeft waar mensen op zoeken:
De belangrijkste koppelingen zijn op regel-niveau:
Dit stelt je in staat hoeveelheid en prijs te vergelijken zonder te moeten raden.
Om met gedeeltelijke leveringen om te gaan, bereken lopende totalen per PO-regel: received_qty (som van receipt-regels) en invoiced_qty (som van invoice-regels). Bereken dan remaining_qty = ordered_qty - received_qty en open_to_invoice_qty = received_qty - invoiced_qty. Deze waarden maken duidelijk of een factuur te vroeg, te laat of te hoog is gefactureerd.
Overschrijf geen historie wanneer een PO verandert. Sla een PO-revisienummer op en/of behoud oude PO-regels (met een active-flag) of schrijf een wijzigingslog (wie wat wijzigde, wanneer, oude waarde, nieuwe waarde).
Voeg basis-guardrails toe om duplicaten en slechte joins te voorkomen:
Driewegmatching-automatisering heeft meestal drie toegangspunten: een factuur arriveert (e-mail, upload, EDI), een ontvangst wordt geboekt, of een PO wordt gewijzigd (prijs, hoeveelheid, status). De workflow moet op al deze gebeurtenissen reageren, zodat een factuur van hold af kan zodra het ontbrekende stuk beschikbaar komt.
1) Valideer eerst de basis van de factuur. Bevestig dat de leverancier actief is, de PO bestaat, de valuta overeenkomt met de PO, en dat totalen intern consistent zijn (regel-totalen tellen op, belasting is redelijk, geen negatieve hoeveelheden tenzij je credits ondersteunt). Als dit faalt, stuur de factuur direct naar Hold met een duidelijke reden.
2) Match per regel, niet alleen op header. Voor elke factuurregel vind je de gerelateerde PO-regel en de ontvangsttotalen tot nu toe. Vergelijk:
3) Stel status in en handhaaf blokkades. Een veelgebruikt patroon:
Wanneer Hold wordt ingesteld, maak je een payment hold-record dat de betaalrun moet respecteren. Houd holds gescheiden van de factuur zodat holds kunnen worden toegevoegd, vrijgegeven of vervangen zonder factuurhistorie te herschrijven.
4) Leg reden-codes vast waar finance op kan vertrouwen. Vermijd alleen-vrije-tekst holds. Gebruik codes zoals PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH, of CURRENCY_MISMATCH, plus een korte toelichting.
Een uitzonderingswachtrij is waar matching bruikbaar wordt, niet alleen strikt. Finance zou alleen facturen moeten zien die een beslissing vereisen, met genoeg context om snel te beslissen en een schoon auditspoor achter te laten.
Een gangbare aanpak is een speciale tabel zoals ExceptionCases. Elke rij vertegenwoordigt één geblokkeerde factuur (of factuurregel) en verwijst terug naar de factuur-, PO- en ontvangstrecords. Houd de matching-engine hier read-only. De wachtrij is bedoeld voor beslissingen en documentatie.
ExceptionCasesSla op wat er mis is, hoe groot het is, wie eigenaar is en wat er daarna gebeurt:
Sla ook samenwerking en auditgegevens op: opmerkingen (auteur, tijdstempel) en bijlage-metadata (bestandsnaam, type, uploaded_by, uploaded_at). Zelfs als bestanden elders staan, hoort de metadata bij de case zodat de geschiedenis intact blijft.
De wachtrijweergave moet een compacte takenlijst zijn: leverancier, factuurnummer, type uitzondering, ernst, bedrag, deadline, eigenaar en een duidelijke "waarom geblokkeerd"-boodschap.
Het openen van een case toont een naast-elkaar overzicht: PO-regels, ontvangen hoeveelheden, factuurregels en de exacte velden die faalden.
Beperk acties en maak ze veilig:
Voorbeeld: een factuur is geblokkeerd omdat 8 eenheden zijn ontvangen maar 10 zijn gefactureerd. Finance kan een gecorrigeerde factuur aanvragen of een override goedkeuren voor de 8 ontvangen eenheden en de resterende 2 on hold laten staan.
Een inkoper maakt een PO voor 100 stuks van artikel A à $10,00 per stuk. De PO-totaal is $1.000. Twee dagen later boekt het magazijn een ontvangst voor 80 stuks.
Vervolgens komt er een factuur binnen voor 100 stuks à $10,00 per stuk. De match moet de factuurregels vergelijken met wat er is ontvangen, niet alleen met wat is besteld.
Op die regel:
De factuur komt op "Hold" omdat 20 eenheden geen ontvangst hebben. Finance ziet een case met een duidelijke reden (Hoeveelheidsvariantie: +20) en de kerngetallen naast elkaar.
Meldingen moeten naar degene gaan die het het snelst kan oplossen: meestal de ontvanger (om te bevestigen of een ontvangst ontbreekt) en de inkoper (om na te gaan of de zending daadwerkelijk te kort was).
Wanneer de resterende 20 eenheden arriveren, boekt het magazijn een tweede ontvangst van 20 eenheden. Het systeem voert de matching opnieuw uit: received wordt 100, unmatched wordt 0, de factuur gaat naar Matched en de hold wordt vrijgegeven.
Voeg nu een prijsvariantie toe. Als de leverancier 100 eenheden factureert à $10,50 in plaats van $10,00, dan klopt de hoeveelheid wel maar niet de prijs. Verwacht resultaat: de factuur blijft op hold en wordt gerouteerd met een reden zoals "Price variance: +$0.50/unit (+$50 total)."
De meeste matchingfouten gaan niet over rekenen. Ze komen door zwakke datakoppelingen en losse controle over geposte documenten.
Enkel op factuurtotaal matchen. Een header kan er goed uitzien terwijl een regel te duur of te kort is. Doe matching op regel-niveau, en wees expliciet over wat mag verschillen (vaak vracht) en wat niet mag (ontvangen hoeveelheid en eenheidsprijs).
Aannemen van één ontvangst en één factuur per PO. Reële inkoop kent gesplitste zendingen en gedeeltelijke facturatie. Ondersteun meerdere ontvangsten en meerdere facturen op dezelfde PO-regels en houd openstaande hoeveelheden per regel bij.
Toestaan van bewerkingen op geposte ontvangsten of facturen zonder spoor. Als iemand aantallen later stiekem kan veranderen, stopt matching bewijslast te zijn. Lock geposte records en corrigeer via aanpassingsdocumenten die historie bewaren.
Ontbrekende duplicaatpreventie. Hetzelfde leverancierfactuurnummer kan twee keer worden ingevoerd, of een PDF kan door een andere persoon opnieuw worden geüpload. Voeg uniekheid vroeg toe (vendor + invoice number, eventueel datum/bedrag) en toon een duidelijke melding bij detectie van een duplicaat.
Vage uitzonderingsredenen. Finance moet niet hoeven gokken. Gebruik reden-codes die netjes routeren: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch.
Betalingsblokkade is het punt waarop matching geen rapport meer is maar een controle. Als de basis niet solide is, creëer je ruis voor finance en te late betalingen voor leveranciers.
Test een kleine set facturen die van elkaar verschillen: een schone match, een gedeeltelijke ontvangst, een prijswijziging en een belastingverschil. Als er eentje niet netjes matcht, repareer dan eerst data en regels.
Checklist:
Behandel driewegmatching-automatisering als elke andere controle: bewijs dat het werkt op een klein deel van de uitgaven en rol het daarna uit.
Begin met een pilot die makkelijk te monitoren is. Kies één business unit, een kleine leveranciersgroep die schone facturen stuurt, of één artikelcategorie. Houd regels in het begin strikt (exacte hoeveelheid en prijs) zodat datakwaliteitsproblemen snel zichtbaar worden.
Meet succes met een eenvoudig finance-overzicht: holds per week, top reden-codes, tijd van hold tot vrijgave, hoeveel holds echte mismatches waren, en welke leveranciers herhaalde uitzonderingen veroorzaken.
Als je snel wilt prototypen, kan een no-code platform helpen omdat je tabellen, matchingregels en routering kunt modelleren zonder te programmeren. Bijvoorbeeld, in AppMaster (appmaster.io) kun je de PO-, ontvangst-, factuur- en uitzonderings-tabellen bouwen en de hold-logica verbinden in een visueel business process zodat dezelfde regels bij elke trigger draaien.
Test met echte facturen uit de pilotgroep, inclusief gedeeltelijke ontvangsten en veelvoorkomende leveranciersfouten. Verwacht dat je matching-sleutels bijstelt en kleine toleranties toevoegt nadat je patronen ziet. Zodra holds redelijk lijken en de tijd tot oplossing verbetert, breid je uit en voeg je rijkere regels toe (belasting- en vrachtverwerking, eenheidconversies, split shipments) zonder de kerncontrole te verliezen: geen betaling vrijgeven totdat de match is opgelost.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
