3-way matching automatiseren

3-way matching is de controle waarbij je inkooporder, ontvangstbon en factuur naast elkaar legt voordat je betaalt. Het is saai, repetitief en regelgestuurd, en daarmee in theorie het perfecte automatiseringsproject. In de praktijk hangt alles af van één cijfer: welk deel van je facturen de eerste keer matcht.

Wat het is, in één alinea

Bij 3-way matching vergelijk je drie documenten voordat een inkoopfactuur wordt goedgekeurd: de inkooporder (wat je hebt besteld), de ontvangstbon (wat er binnenkwam) en de factuur (wat de leverancier in rekening brengt). Kloppen aantal, prijs en artikel op alle drie, dan mag hij door. Wijkt er iets af, dan gaat hij naar een mens.

Het doel is niet administratief netjes zijn. Het is voorkomen dat je betaalt voor iets dat je niet hebt besteld, niet hebt ontvangen, of niet tegen die prijs hebt afgesproken.

Het cijfer dat alles bepaalt

Vraag bij elke leverancier van matchingsoftware hetzelfde: welk percentage van onze facturen matcht bij de eerste poging, zonder menselijke handeling?

Dat cijfer bepaalt je hele businesscase, want de rekensom is asymmetrisch. Een factuur die matcht kost bijna niets. Een factuur die niet matcht kost een mens die uitzoekt waarom, iemand belt, en het corrigeert. In de praktijk kost het uitzoeken van één uitzondering al snel het tienvoudige van een geslaagde match.

Dat betekent iets contra-intuïtiefs: de winst zit niet in het automatiseren van de matches, maar in het verkleinen van de uitzonderingenstroom. Software die je matchpercentage van 70 naar 85 tilt is meer waard dan software die de geslaagde matches iets sneller verwerkt.

Waarom facturen niet matchen

Bijna altijd om een van deze zes redenen. Alleen de eerste twee zijn echt een softwareprobleem.

Vier van de zes zijn organisatorisch. Dat is de belangrijkste boodschap van dit stuk: als je matchpercentage laag is omdat er zonder inkooporder wordt besteld, koop je met software een duurdere versie van hetzelfde probleem.

Meet daarom eerst waarom je uitzonderingen ontstaan, voordat je iets aanschaft. Een steekproef van vijftig mismatches en een streepjeslijst is genoeg. Die twee uur bepalen of je project slaagt.

Tolerantie: de knop die het meeste verschil maakt

Tolerantie is de marge waarbinnen je een verschil accepteert zonder menselijke controle. Meestal in te stellen als bedrag, als percentage, of als beide.

Te strak afgesteld en alles valt uit; te ruim en je betaalt fouten door zonder dat iemand kijkt. De werkbare aanpak:

• Begin met de data die je al hebt. Kijk naar je laatste duizend facturen en vraag: bij welk bedrag en welk percentage ligt de grens waaronder een verschil vrijwel nooit een echte fout was?

• Stel per categorie in, niet globaal. Een tolerantie van 2% is redelijk op kantoorartikelen en roekeloos op grondstoffen.

• Zet een absolute bovengrens naast het percentage. 2% van 500 euro is prima, 2% van 400.000 euro is dat niet.

• Evalueer na een kwartaal. Kijk of er binnen de tolerantie fouten zijn doorgeglipt. Zo niet, dan kan hij waarschijnlijk ruimer.

Een leverancier die tolerantie presenteert als "instellen en klaar" heeft er weinig mee gewerkt. Het is een knop die je bijstelt.

Wat AI hier wel en niet toevoegt

Klassieke matching is regelwerk en heeft helemaal geen AI nodig. Waar modellen wel iets toevoegen:

• Documentherkenning. Van een pdf of scan naar gestructureerde regels. Dit is echt opgelost en de reden dat matching bij ongestructureerde facturen nu wel kan.

• Artikelcodes koppelen. Als de leverancier "M8 bout RVS A2 20mm" schrijft en jouw systeem "BOUT-M8-A2-020" kent, is dat een matchingprobleem waar een model beter in is dan een regel.

• Uitzonderingen voorstellen. Niet automatisch goedkeuren, maar wel voorstellen wat er waarschijnlijk aan de hand is en wie het moet oplossen. Dat scheelt de zoektijd, niet de beslissing.

Waar AI niet hoort: het zelfstandig goedkeuren van betalingen buiten tolerantie. Dat is precies het soort besluit waar een verkeerde uitkomst geld kost en waar je een audittrail wilt die een mens kan uitleggen.

De rekensom, met de uitzonderingen als hoofdrol

Het voorbeeld hieronder laat zien waarom het matchpercentage zwaarder weegt dan het volume. Vul je eigen cijfers in.

Aannames: 800 inkoopfacturen per maand. Een geslaagde match kost 0,5 minuut aan controle. Een uitzondering kost gemiddeld 9 minuten aan uitzoeken, bellen en corrigeren. Volledig belaste kosten: 45 euro per uur.

Bij 60% first-time match:

• 480 matches x 0,5 min = 240 min

• 320 uitzonderingen x 9 min = 2.880 min

• totaal 3.120 minuten = 52 uur, oftewel 2.340 euro per maand

Bij 85% first-time match, met precies hetzelfde volume:

• 680 matches x 0,5 min = 340 min

• 120 uitzonderingen x 9 min = 1.080 min

• totaal 1.420 minuten = 23,7 uur, oftewel 1.065 euro per maand

Verschil: circa 1.275 euro per maand, puur door het matchpercentage. Er is geen enkele factuur bijgekomen of afgegaan.

Draai de som ook eens andersom: houd het matchpercentage gelijk en verhoog het volume met 25%. De besparing die dat oplevert is veel kleiner. Dat is het argument om je energie in de uitzonderingen te steken en niet in doorlooptijd.

Beginnen zonder iets te kopen

Als je nu geen matching-oplossing hebt, is dit de goedkoopste eerste stap, en hij kost je een middag:

1. Pak de laatste vijftig facturen die niet automatisch door konden. Uit je boekhoudpakket of gewoon uit de map van de crediteurenadministratie.

2. Turf de oorzaak met de zes categorieën uit de tabel hierboven. Niet interpreteren, gewoon turven.

3. Kijk naar de verdeling. Zitten de meeste in "geen inkooporder" of "ontvangstbon ontbreekt", dan is je project een procesafspraak en geen aanschaf.

4. Als de meeste in prijs- of aantalverschillen zitten, dan is tolerantie je eerste knop, en die zit vaak al in je huidige pakket.

5. Pas daarna kijk je naar software, met een concreet beeld van welk deel van je uitval hij daadwerkelijk oplost.

Deze volgorde bespaart regelmatig het hele project. Een leverancier zal je dit niet aanraden, wat begrijpelijk is.

Bij welk volume loont dit?

Vuistregels die in de praktijk standhouden, met de kanttekening dat variatie zwaarder weegt dan volume:

• Onder ~200 inkoopfacturen per maand: meestal niet, tenzij je een specifiek risico afdekt. De inrichting van tolerantie, stamdata en koppelingen weegt zwaarder dan de bespaarde tijd.

• 200 tot 1.000 per maand: het hangt op je uitzonderingspercentage. Zit je al rond de 80% first-time match, dan is de winst beperkt. Zit je op 50%, dan is er veel te halen, maar zit de winst waarschijnlijk deels in je proces.

• Boven ~1.000 per maand: vrijwel altijd, al was het maar omdat handmatig matchen op dit volume ook een foutenprobleem wordt.

Reken het door zoals in wat automatische factuurverwerking kost: jouw volume, jouw uurkosten, jouw uitzonderingspercentage.

Wat je vraagt aan een leverancier

1. "Welk first-time-match percentage halen klanten met een leveranciersbestand als het onze?" Vraag door op "als het onze".

2. "Ondersteunen jullie deellevering en deelfacturatie?" Dit is de meest voorkomende reden voor uitval en niet elk pakket doet het goed.

3. "Hoe stellen we tolerantie per categorie in?" Alleen globaal is te grof.

4. "Wat gebeurt er bij een factuur zonder inkooporder?" Er moet een route zijn, want die facturen bestaan altijd.

5. "Hoe koppelen jullie leverancier-artikelcodes aan de onze?" Handmatig, met regels, of met een model dat leert.

6. "Wat zie ik in het audittrail bij een automatisch goedgekeurde factuur?" Zonder dat is elke controle achteraf een reconstructie.

Wat je meet nadat het draait

Vier cijfers, maandelijks. Meer is ruis.

Die laatste wordt bijna nooit gemeten en is de belangrijkste. Tolerantie ruimer zetten verhoogt je matchpercentage direct, wat er goed uitziet in een rapportage. Of het verstandig was, blijkt alleen als iemand steekproefsgewijs terugkijkt of er fouten doorheen zijn geglipt. Plan die steekproef in, elk kwartaal, en houd hem klein: twintig facturen is genoeg om een trend te zien.

Let ook op een patroon dat pas na maanden zichtbaar wordt: stijgt je matchpercentage terwijl je uitzonderingen per oorzaak niet dalen? Dan is er waarschijnlijk iets ruimer gezet in plaats van opgelost.

Veelgestelde vragen

Wat is het verschil tussen 2-way en 3-way matching? Bij 2-way matching vergelijk je alleen inkooporder en factuur. Bij 3-way komt de ontvangstbon erbij, zodat je ook controleert dat het daadwerkelijk is geleverd. 2-way is prima voor diensten waar niets fysiek binnenkomt; voor goederen mist het de belangrijkste controle.

Bestaat 4-way matching? Ja, dan komt een keuringsrapport erbij. Relevant in productie en bouw waar geleverd niet hetzelfde is als goedgekeurd. Voor de meeste MKB-bedrijven is het overbodige complexiteit.

Moet elke factuur door 3-way matching? Nee, en dat is een veelgemaakte fout. Terugkerende kosten zoals huur, abonnementen en energie hebben geen inkooporder en horen in een aparte route. Alles door één proces duwen creëert uitzonderingen die er niet hoefden te zijn.

Kan dit met ons huidige boekhoudpakket? Vaak meer dan mensen denken. Exact, Twinfield en AFAS hebben matchingfunctionaliteit die niet altijd aan staat of niet is ingericht. Controleer dat voordat je iets aanschaft.

Wat als leveranciers hun facturen niet gestructureerd aanleveren? Dat is de normale situatie en het is opgelost met documentherkenning. Wat het niet oplost is een leverancier die stelselmatig anders factureert dan besteld; dat is een gesprek, geen technisch probleem.

Kort samengevat

3-way matching is een goed automatiseringsproject omdat de regels duidelijk zijn en het volume hoog. Maar de winst zit in de uitzonderingen, niet in de matches, en vier van de zes oorzaken van uitval zijn organisatorisch. Meet eerst waarom jouw facturen niet matchen. Als het antwoord "er wordt besteld zonder inkooporder" is, dan is dat je project, niet de software.

Loopt je maandafsluiting uit doordat dit blijft liggen: maandafsluiting versnellen met AI. Wil je zien welke tools er zijn: invoice reconciliation software vergeleken.

Aan de slag

Plan een vrijblijvende kennismaking. We kijken naar je uitval van de afgelopen maand en zeggen eerlijk of dit een softwareprobleem is of een procesprobleem.