Waarom bijna elke crediteurenuitzondering bovenstrooms is gemaakt, wat een agent in de inkoopketen overneemt, en waarom de meeste bedrijven aan de verkeerde kant beginnen.
Wat is procure-to-pay?
Procure-to-pay, ook wel purchase-to-pay of P2P, is het hele proces van het moment dat iemand iets nodig heeft tot het moment dat de leverancier betaald is en de post is afgeletterd. In stappen:
- Iemand heeft iets nodig en dient een aanvraag in
- De aanvraag wordt goedgekeurd
- Er gaat een inkooporder naar de leverancier
- De goederen of diensten komen binnen en de ontvangst wordt geboekt
- De factuur komt binnen
- De factuur wordt gematcht tegen order en ontvangst
- De factuur wordt gecodeerd, goedgekeurd en geboekt
- Er wordt betaald en de betaling wordt afgeletterd
Drie termen worden hier door elkaar gebruikt. Source-to-pay begint een stap eerder, bij het selecteren van leveranciers en het onderhandelen van contracten. Procure-to-pay begint bij de aanvraag. Order-to-cash is de spiegel aan de verkoopkant: van order tot ontvangen geld.
De stappen 5 tot en met 8 zijn de crediteurenadministratie. Daar gaat AI-agents voor crediteuren over. Dit stuk gaat over wat er daarvoor gebeurt, en waarom dat bepaalt hoeveel werk er daarna overblijft.
Waar de keten in de praktijk breekt
Per stap, met wat we er in de praktijk van zien.
| Stap | Wat er misgaat | Wat we zagen |
|---|---|---|
| Aanvraag | Er is geen aanvraag. Iemand belt de leverancier. | Bij een luchtvaartbedrijf op Exact gaat inkoopordergoedkeuring volledig via de telefoon of mondeling, niet in het systeem |
| Order aanmaken | De order wordt achteraf gemaakt, of overgeslagen | Een onderhoudsbedrijf op NetSuite registreert en keurt alle facturen handmatig goed, ongeacht of er een order is |
| Ontvangst boeken | De ontvangst staat er niet als de factuur binnenkomt | Bij een retailgroep op Dynamics is matchen op regelniveau verplicht, dus zonder geboekte ontvangst loopt het vast |
| Factuur binnen | Geen referentie, geen ordernummer | Dezelfde retailgroep tikt facturen van een bandenleverancier vrijwel volledig over: "wij zoeken die band op, pakbonboeken, en dan kunnen we vervolgens matchen" |
| Matchen | Centen-, koers- en feeverschillen blokkeren de match | Een regel van 17 cent die los blijft staan. Een betaling van € 20,60 die niet op een factuur van € 20 past door een PayPal-fee |
| Entiteiten | De order staat op een andere entiteit dan de factuur | Bij een reisdienstverlener op NetSuite moet elke groepsontvangst volledig worden verwijderd en handmatig opnieuw worden opgebouwd per entiteit voordat matchen kan beginnen |
| Goedkeuren | De drempels staan in iemands hoofd, niet in het systeem | "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" |
| Betalen en afletteren | Eén betaling dekt tientallen facturen af | De betaalspecificatie zit als PDF in een aparte mail, en teams schuiven met tussenrekeningen om koersverschillen weg te werken |
Kijk naar de linkerkolom. De eerste vier rijen gaan over dingen die gebeuren voordat de crediteurenadministratie iets in handen heeft. En ze veroorzaken het merendeel van de rijen daaronder.
Waarom mensen het proces omzeilen
De reflex is om dit een discipline-probleem te noemen. Dat is het meestal niet.
Een klant zei het scherper dan wij het zouden hebben opgeschreven: operationele urgentie wint consequent van het administratieve inkoopproces. Als een vliegtuig aan de grond staat en er is een onderdeel nodig, dan wordt dat onderdeel besteld. De inkooporder komt later wel, of niet. Dat noemen ze daar retroactieve PO-creatie, en de administratieve schuld die het oplevert komt een week later bij de crediteurenafdeling terecht.
Dit is niet iets van kleine bedrijven die het nog niet op orde hebben. Een internationale fintech met vijftien entiteiten worstelt met exact hetzelfde: PO's die achteraf worden aangemaakt omdat het proces vooraf te traag was voor wat er moest gebeuren.
De conclusie die telt: mensen omzeilen het proces omdat het proces te omslachtig is voor het tempo van hun werk. Een P2P-suite die naleving afdwingt met een extra poort maakt dat erger, niet beter. Er komt gewoon een omweg omheen, en die omweg wordt de nieuwe werkelijkheid.
Wat wél werkt is de frictie weghalen waar hij zit, en het opruimen automatiseren waar hij toch ontstaat. Dat is een andere opdracht dan het proces strenger maken.
Zes dingen die een agent in de inkoopketen overneemt
1. Een aanvraag omzetten in een order
De aanvraag komt binnen als een mail, een bon, een appje of een offerte van de leverancier. Een agent leest wat er besteld wordt, bij wie, tegen welke prijs, en zet er een orderaanvraag van klaar in het systeem. De drempel om het "even snel" buiten het proces om te doen wordt daarmee lager dan de drempel om het wél te doen, en dat is de enige manier waarop naleving verbetert.
2. De ontvangst achterhalen als hij niet geboekt is
De factuur is er, de order is er, en de ontvangst ontbreekt. Dat is de meest voorkomende reden dat een 3-way match niet rondkomt. Een agent zoekt de pakbon op, kijkt in de mail van de afdeling die het heeft aangenomen, en vraagt het na als het daarmee niet lukt. Bij die laatste stap is het adres een collega, niet de leverancier.
3. Een order reconstrueren bij een factuur zonder referentie
Geen ordernummer op de factuur, of een nummer dat de leverancier verkeerd heeft overgenomen. Een agent zoekt de order zelf op basis van leverancier, bedragen, artikelen en regels, en laat zien hoe zeker hij is in plaats van te doen alsof hij het weet. Kan hij het niet rondkrijgen, dan gaat de factuur naar je team met de kandidaten erbij.
4. Verschillen classificeren voordat er iemand naar kijkt
Niet elk verschil is hetzelfde verschil. Een koersverschil, een bankkost, een afronding en een echte prijsafwijking vragen om verschillende acties, en alleen die laatste is een gesprek met de leverancier waard. Een agent bepaalt in welke categorie het valt, boekt weg wat volgens jouw regel weggeboekt mag worden, en legt de rest voor met de reden erbij.
5. Navragen bij de budgethouder wat er besteld is
Bij facturen zonder order is de enige persoon die het antwoord heeft degene die het besteld heeft. Een agent stelt die vraag, met de factuur en de regel waar het over gaat erbij, en verwerkt het antwoord zelf. Wat er nu vaak gebeurt is dat een crediteurenmedewerker die mail stuurt, er niets op hoort, en er drie dagen later achteraan gaat.
Er zijn bedrijven die deze frictie bewust laten bestaan. Eén organisatie laat leveranciersfacturen expres niet direct in de administratiemailbox binnenkomen, juist om budgethouders te dwingen hun eigen kosten en abonnementen te zien. Dat is een legitieme keuze, en het is het waard om te weten of jullie hem bewust hebben gemaakt of dat het zo gegroeid is.
6. Zichtbaar maken waar de keten structureel lekt
Dit is de stap die niemand vandaag heeft en die het meeste oplevert. Welke leveranciers factureren structureel zonder ordernummer. Welke afdelingen boeken hun ontvangsten niet. Bij welke leveranciers loopt het altijd vast op dezelfde soort afwijking.
Die lijst valt vanzelf uit het werk dat de agent doet, want hij komt elke uitzondering tegen en weet waarom hij ontstond. Voor een inkoopdirecteur is dat een bruikbaarder rapport dan wat de meeste P2P-suites uit hun eigen data halen, omdat het gaat over waar het proces in de praktijk niet gevolgd wordt in plaats van over wat er binnen het proces geregistreerd is.
P2P-suites tegenover agents
Een echte P2P-suite en een agent lossen verschillende problemen op. Het onderscheid is niet welke functies er in zitten, maar welke aanname eronder ligt.
| P2P-suite of ERP-module | AI-agent erbovenop | |
|---|---|---|
| Uitgangspunt | Iedereen volgt het proces | Het proces wordt niet altijd gevolgd, en dat is het startpunt |
| Factuur zonder order | Afkeuren of blokkeren | Order reconstrueren, voorstellen, laten bevestigen |
| Naleving | Afdwingen met een poort | Minder frictie, zodat de omweg niet meer loont |
| Ontbrekende ontvangst | Wachtrij | Opzoeken, navragen bij de collega, verwerken |
| Invoeren | Maanden, migratie, iedereen omscholen | Bovenop wat er staat, zonder migratie |
| Uitzondering | Wachtrij voor een mens | Eerst uitgezocht, dan pas een mens |
| Wat je erover kunt vertellen | Wat er binnen het proces gebeurde | Waar het proces in de praktijk niet gevolgd wordt |
Dit is geen argument om je P2P-suite eruit te gooien. Heb je een volwassen inkoopproces met echte aanvragen en geboekte ontvangsten, dan doet die suite precies wat hij moet doen en zit jouw werk aan de crediteurenkant. Is de werkelijkheid rommeliger, dan lost strenger afdwingen dat niet op.
Waar het stopt
Een agent kan geen order maken die nooit besteld is. Als niemand weet wat er is afgesproken, is er niets te reconstrueren. Wat hij wel kan is het bewijs bij elkaar zoeken en de vraag stellen aan de enige persoon die het antwoord heeft. Dat is echt werk, maar het is geen tovenarij.
Wat je ERP niet aanbiedt, kan een agent er niet in schrijven. In een pilot op Exact bleek de standaardgoedkeurder op leveranciersniveau niet uitleesbaar, omdat Exact daar geen API voor heeft. Zulke ongedocumenteerde grenzen kom je pas tegen tijdens het bouwen. Vraag ernaar per processtap die je wilt automatiseren, niet in het algemeen.
Wij bouwen de inkoopkant niet. Claridy draait op de crediteurenkant en leest je orders en ontvangsten uit je ERP. Zoek je een systeem om aanvragen, contracten en leveranciersselectie in te beheren, dan is dat een andere categorie en moet je die apart beoordelen.
Hoe je begint
Met één getal, en dat kun je vandaag ophalen.
- Meet welk deel van je facturen binnenkomt zonder bruikbaar ordernummer. Dat percentage bepaalt of je bovenstrooms of benedenstrooms moet beginnen. Onder de tien procent zit je probleem in de verwerking. Boven de dertig procent zit het in de inkoop, en dan lost een betere factuurverwerking het niet op.
- Tel hoe vaak een match strandt op een ontbrekende ontvangst. Dat is een ander probleem dan een ontbrekende order, en het heeft een andere oplossing: meestal een afdeling die geen ontvangsten boekt, niet een leverancier die iets fout doet.
- Vraag waarom de omweg bestaat. Bij elke stap die stelselmatig wordt overgeslagen, is er een reden. Meestal is dat tempo. Repareer eerst de reden, dan pas de regel.
- Zet de agent eerst onder toezicht. Elke actie als voorstel, je team keurt goed, en daarna schuif jij de drempel op op basis van wat je hebt zien gebeuren.
Veelgestelde vragen
Procure-to-pay is de hele keten van aanvraag tot betaling. Accounts payable is het crediteurendeel daarvan, dus vanaf het moment dat de factuur binnenkomt. Het merendeel van het werk in accounts payable wordt veroorzaakt door wat er in de stappen daarvoor wel of niet is gebeurd.
De factuur naast de inkooporder en de goederenontvangst leggen, en controleren of de aantallen en prijzen op regelniveau overeenkomen. Zonder geboekte ontvangst is een 3-way match niet mogelijk, en dat is de meest voorkomende reden dat hij vastloopt. Uitgebreider: 3-way matching op schaal.
Dat hangt af van waar je werk zit. Wil je aanvragen, goedkeuringen en contracten beheren, dan heb je een inkoopsysteem nodig. Zit je werk in het opruimen van wat er uit de inkoop komt, dan lost een agent op je ERP dat sneller op, zonder migratie.
Ja, en dan is het juist relevanter. Bij facturen zonder order gaat het over coderen op basis van leverancier, historie en jouw instructies, en over navragen bij de budgethouder. Dat is precies het werk dat regelgebaseerde software niet aankan.
Dat is waar de meeste ketens het eerst breken. De order staat op de ene entiteit, de factuur komt van de andere, en de ontvangst is als groepsontvangst geboekt. Meer hierover: facturen over meerdere entiteiten in Dynamics.
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 op deze keten doet, staat op de productpagina procure-to-pay. Over de crediteurenkant: AI-agents voor crediteuren. Het onderscheid tussen automatisering, workflows en agents: AI-agents voor finance. Over de architectuur: wat is een system of action voor finance.
Laatst gecontroleerd: 2026-08.