Order-to-cash, procure-to-pay en record-to-report

Wat zijn order-to-cash, procure-to-pay en record-to-report?

Het zijn de drie procesfamilies waar het meeste ERP- en automatiseringswerk op mikt, en elke naam zegt waar de reeks begint en waar ze stopt. Order-to-cash (O2C) loopt van een bestelling van een klant tot het geld op je rekening staat. Procure-to-pay (P2P) loopt van iemand die iets nodig heeft tot de leverancier betaald is. Record-to-report (R2R) loopt van een geboekte transactie tot de cijfers die je rapporteert.

Die manier van benoemen is bewust gekozen. Verkoop, magazijn, aankoop en boekhouding hebben elk hun eigen afdelingswoord voor hun stuk van het werk. Order-to-cash weigert er daar een van te kiezen en benoemt de hele reeks, van het eerste systeem dat de bestelling aanraakt tot het laatste dat de betaling aanraakt.

Het zijn woorden uit de sector, geen norm, dus vraag altijd waar iemand de grenzen legt voor je cijfers naast elkaar zet. De business process catalog van Microsoft voor Dynamics 365 geeft order to cash nummer 65 en record to report nummer 90, en noemt de aankoopfamilie source to pay: die begint een stap vroeger, bij het zoeken en kiezen van leveranciers in plaats van bij de aanvraag. Het opleidingsmateriaal van SAP en de meeste process-miningleveranciers houden het op het kortere procure-to-pay.

Order-to-cash, stap voor stap

De reeks is: een klant bestelt, je kijkt kredietlimiet en beschikbaarheid na, je bevestigt, je levert, je factureert, de klant betaalt, en je koppelt die betaling aan de juiste factuur. Microsoft omschrijft het als alles wat gebeurt vanaf het moment dat een klant bestelt tot de betaling ontvangen en afgepunt is tegenover de factuur. De reeks eindigt op de bank, en daarom staat er cash in de naam en geen factuur.

Vier cijfers zeggen je hoe ze draait.

• DSO (days sales outstanding). Celonis omschrijft het als de gemiddelde tijd in dagen die een bedrijf nodig heeft om betaald te worden voor goederen en diensten die het op krediet verkocht: openstaande klantenvorderingen gedeeld door de omzet op krediet, maal het aantal dagen in de periode. Het vertaalt zich rechtstreeks in cash.

• Doorlooptijd van bestelling tot levering. De klok van de klant, van bestellen tot de goederen bij hem staan. Dit is het cijfer dat in klachten opduikt.

• Factuurjuistheid. Het aandeel facturen dat de eerste keer juist buitengaat: juiste prijs, juiste hoeveelheid, juist btw-nummer, juiste bestelreferentie.

• Betwistingsgraad. Het aandeel facturen waar een klant vragen bij stelt. Een betwisting zet de betaalklok stil zonder de factuur stil te zetten, en zo duwt ze de DSO omhoog op een manier die op een dashboard leest als klanten die traag betalen.

Wat een probleem kost. Een groothandel met 3 miljoen euro omzet heeft 500.000 euro openstaande klantenvorderingen. DSO is dan 500.000 gedeeld door 3.000.000, maal 365: ongeveer 61 dagen, op betaaltermijnen van 30. Een dag DSO is 3.000.000 gedeeld door 365 waard, zo'n 8.200 euro. Van 61 naar 45 dagen gaan maakt 16 maal 8.200 vrij, ruwweg 130.000 euro cash, eenmalig. Dat is de kredietlijn die het bedrijf bij de bank huurt om zijn eigen factuurgewoonten te financieren. De klanten blijken niet de hoofdoorzaak: ongeveer een factuur op zestien krijgt een vraag over een prijs of een geleverd aantal, en zo'n vraag blijft een dag of negen liggen voor iemand ze beantwoordt.

Procure-to-pay, stap voor stap

De reeks is: iemand heeft iets nodig, er komt een aanvraag die goedgekeurd wordt, een bestelbon vertrekt naar de leverancier, de goederen of de dienst komen toe en worden in het systeem ontvangen, de leveranciersfactuur komt binnen, ze wordt gematcht en goedgekeurd, en ze wordt betaald. De volgorde is het hele punt. Een factuur die binnenkomt voor er ooit een bestelbon gemaakt is, valt tegen niets te matchen, en vanaf dan is het een telefoontje en geen proces.

Three-way matching is de controle in het midden daarvan. De documentatie van Microsoft over leveranciersfacturen omschrijft het als de prijsinformatie op de factuur vergelijken met de prijs op de bestelbon, en het aantal op de factuur met het aantal op de geboekte goederenontvangsten. Drie documenten moeten kloppen: wat je besteld hebt, wat je gekregen hebt, en wat er aangerekend wordt. Bij two-way matching valt de ontvangst weg en vergelijk je enkel factuur met bestelbon. Toleranties maken het werkbaar: een bedrijf laat bijvoorbeeld een prijsafwijking van een paar procent toe en houdt alles daarbuiten tegen tot iemand het goedkeurt. Het gaat zelden mis doordat een foute factuur erdoor glipt. Het gaat mis doordat een juiste factuur een week blijft hangen omdat niemand in het magazijn de goederenontvangst geboekt heeft.

• Touchless-graad. Het aandeel leveranciersfacturen dat binnenkomt, uitgelezen, gematcht, goedgekeurd en geboekt wordt zonder dat er iemand aan te pas komt. De benchmark van Ardent Partners over leveranciersadministratie uit 2025 zet de koplopers op 49,2 procent, wat meteen zegt dat de helft van je facturen met de hand behandelen nog altijd een goed resultaat is.

• Kost per factuur. Dezelfde benchmark laat de koplopers een factuur verwerken voor 2,78 dollar, tegenover een gemiddelde rond de tien. Bijna heel dat verschil zit in matchen en goedkeuringen doorsturen, niet in typen.

• Tijdig betalen. Te laat betalen kost je goodwill bij leveranciers en kortingen voor snelle betaling; alles betalen op de dag dat het binnenkomt kost werkkapitaal.

• Maverick buying. Elke aankoop buiten het afgesproken pad om, in de woorden van Esker: buiten het aankoopbeleid, de afgesloten contracten of de lijst met voorkeursleveranciers. Een leverancier zonder contract, geen bestelbon, een bedrijfskaart. Je meet het als het aandeel uitgaven dat binnenkomt zonder bijhorende bestelbon.

Wat een probleem kost. Een producent verwerkt 6.000 leveranciersfacturen per jaar en meet zijn eigen kost op ongeveer 8 euro per stuk aan werktijd. Een op vijf gaat er vanzelf door. Van de facturen die wel aangeraakt worden, hangt ruwweg de helft vast omdat de goederenontvangst nooit geboekt is, dus belt de boekhouding naar het magazijn en verwerkt ze de factuur twee dagen later opnieuw. Ontvangsten boeken op de dag van levering, meer niet, tilt de touchless-graad naar 45 procent: 1.500 facturen minder met de hand, ongeveer 12.000 euro per jaar. Op dezelfde site wordt 180.000 euro van de 1,2 miljoen niet-strategische uitgaven buiten contract gekocht, en een steekproef van tien artikels toont dat die aankopen zo'n 8 procent boven de onderhandelde prijs liggen, nog eens 14.000 euro. Geen van beide cijfers vroeg nieuwe software. Beide vroegen een bestelbonnummer op de factuur.

Record-to-report, stap voor stap

De reeks is: transacties worden vastgelegd in de deeladministraties, ze boeken door naar het grootboek, rekeningen worden aangesloten, correcties en overlopende posten worden geboekt, entiteiten worden geconsolideerd, en de cijfers komen buiten. Microsoft groepeert dezelfde familie als gegevens verzamelen, boekingen, rekeningen aansluiten, financiële rapportering en financiële analyse, en noemt het het registratie- en afsluitproces.

R2R verschilt op één punt van de twee andere, en dat punt bepaalt hoe het zich gedraagt: week na week zit er niemand van buiten het bedrijf achter. Geen klant wacht op je bankaansluiting en geen leverancier belt over je overlopende posten, dus schuift het werk naar achter in de rij. Dat je het laat schuiven, kost je pas later iets, in de vorm van beslissingen op oude cijfers.

• Dagen tot afsluiting. Tel de kalenderdagen tussen de proefbalans en het moment waarop de geconsolideerde cijfers getekend zijn. De benchmark voor algemene boekhouding van APQC meet net dat, en de gepubliceerde medianen over alle sectoren liggen al jaren rond een werkweek. Belangrijker dan het cijfer zelf is de lijn in je eigen cijfers: duurde de afsluiting in januari zes dagen en in juni negen, dan is er iets veranderd in de processen die de cijfers aanleveren.

• Manuele boekingen. Elke manuele boeking is ofwel een echte boekhoudkundige afweging, ofwel een systeem dat niet geboekt heeft wat het had moeten boeken. Splits ze op naar oorzaak: die tweede groep is een instellingsprobleem, geen boekhoudprobleem.

• Openstaande aansluitingsverschillen. Posten op bank-, intercompany- en wachtrekeningen die nog niemand verklaard heeft. De ouderdom van de oudste zegt meer dan het aantal.

Wat een probleem kost. Een groep van twee vennootschappen met veertig medewerkers boekt zo'n 180 manuele boekingen per maand. De controller klokt ze op ongeveer zeven minuten per stuk om op te maken, na te kijken en te klasseren: 21 uur per maand, zo'n 250 uur per jaar, aan 60 euro all-in per uur goed voor 15.000 euro. Uitgesplitst naar oorzaak zijn 110 van de 180 elke maand dezelfde overlopende posten, en die zet een terugkerende boekingssjabloon vanzelf klaar. Dat is ongeveer 9.000 euro van die 15.000, en het haalt twee dagen van een afsluiting die nu twaalf werkdagen duurt. Die twaalf dagen zijn de duurste helft: de marge van juni ligt op 18 juli op het bureau van de zaakvoerder, dus een verkeerd geprijsde productlijn die sinds begin juni verkocht wordt, wordt eind juli rechtgezet, na zeven weken bestellingen aan de verkeerde marge.

Waarom die namen wel de moeite zijn

De eerste reden is commercieel: de markt is rond deze eenheden georganiseerd. Process-miningleveranciers verkopen een order-to-cash-app en een procure-to-pay-app, en de catalog van Microsoft gaat onder elk van die namen zes niveaus diep, tot testgevallen toe. Zeg je dat de facturatie traag is, dan krijg je een demo. Zeg je dat je order-to-cash-cyclus 61 dagen duurt en dat je de betwistingen verdenkt, dan krijg je een gesprek over je eigen cijfers.

De tweede reden is dat elke familie over afdelingen heen loopt, en juist daarom een eigen naam nodig heeft. Order-to-cash passeert langs verkoop, magazijn, facturatie en debiteurenbeheer, en niemand in de hiërarchie is baas over de hele reeks. Elke afdeling optimaliseert dus haar eigen stuk terwijl het totaal achteruitgaat. Verkoop belooft een leverdatum die het magazijn niet haalt, het magazijn levert in de goedkoopste samenstelling en de factuur gaat verkeerd buiten, en debiteurenbeheer belt een klant die gelijk heeft om te weigeren. Het lemma over de procesbeheerder gaat over de job om die reeks samen te houden.

De derde reden is waar het geld zit. Zowat elk meetbaar verlies in deze drie families zit op een overdracht en niet in een stap, en bij een overdracht is er geen afdeling om de rekening naartoe te sturen. De volgende sectie benoemt de drie die het meeste kosten.

Het Process Classification Framework van APQC, de andere veelgebruikte indeling, snijdt hetzelfde werk net andersom. De dertien categorieën op het hoogste niveau zijn functioneel, zoals Market and Sell Products and Services en Manage Financial Resources, en één order-to-cash-reeks passeert door meerdere daarvan. De functionele indeling dient om te zeggen wie wat doet; de end-to-end-namen dienen om één bestelling helemaal te volgen.

Waar de drie processen elkaar raken

De catalog van Microsoft zet record to report stroomafwaarts van zowel order to cash als source to pay, en de twee operationele families stroomop- en stroomafwaarts van elkaar. Dat geeft je drie raakvlakken die je op een bord kan aanwijzen.

Een onbetaalde O2C-factuur wordt een R2R-probleem. Ze veroudert tussen de openstaande posten, ze bepaalt de voorziening voor dubieuze debiteuren, en als ze in de verkeerde periode gefactureerd is, verschuift ze omzet over de afsluitdatum. De boekhouding discussieert dan over een cijfer waarvan de oorzaak een leveringsdiscussie van twee maanden geleden is, die verkoop per mail geregeld heeft.

Een ontbrekende goederenontvangst in P2P blokkeert twee processen tegelijk. De boekhouding kan de factuur niet three-way matchen, dus de leverancier wacht. Tegelijk klopt de overlopende post voor ontvangen maar niet gefactureerde goederen niet, dus sluit R2R af op een voorraad- en kostcijfer dat niet overeenkomt met wat er in de rekken ligt.

Een rechtstreekse levering knoopt O2C en P2P aan elkaar in één stap. Microsoft merkt op dat bij rechtstreekse levering de verkooporder zelf de bestelbon bij de leverancier kan aanmaken. Vanaf dat moment hangt de leverdatum van je klant aan die van je leverancier, en komt een vertraging in de aankoop bij jou binnen als een verkoopklacht.

Procure-to-pay tegenover order-to-cash

Op papier lijken ze elkaars spiegelbeeld: dezelfde documenten, dezelfde matchinglogica, omgekeerde richting. In de praktijk gedragen ze zich helemaal anders, en dat komt door de kant van de tafel waar je zit.

Bij order-to-cash ben jij de verkoper. Jij stuurt de factuur en dan wacht je, want het geld komt binnen wanneer iemand anders beslist het vrij te geven. Je blootstelling zit in de timing, en die timing is de keuze van je klant. De DSO drukken betekent dus zijn gedrag veranderen, met herinneringen, kredietlimieten, blokkeringen op bestellingen en, helemaal aan het einde, stoppen met leveren. Dat is een commerciële beslissing voor het een procesbeslissing is.

Bij procure-to-pay ben jij de koper. De factuur komt binnen en jij beslist wanneer de betaling vertrekt, dus je leverancier is degene die op jou wacht. De touchless-graad optrekken betekent veranderen wat je eigen mensen doen, en dat kan je op een dinsdag beslissen zonder aan iemand buiten het huis iets te vragen. Daarom geraken projecten rond procure-to-pay meestal af, terwijl projecten rond order-to-cash uitdraaien op een discussie over betaaltermijnen en wie mag beslissen om niet meer te leveren aan een klant.

Zonder ERP heb je die drie processen ook

De software maakt de processen niet. Een bedrijf van tien mensen dat offertes in Word maakt, factureert uit een boekhoudpakket en zijn voorraad in Excel bijhoudt, draait order-to-cash precies zoals hierboven beschreven. Wat verschilt, is waar de timestamps liggen. In een ERP is het moment waarop een bestelling bevestigd werd een veld in een tabel. In een mailbox is het een verzonden bericht dat niemand ooit optelt, en daarom heeft process mining in zo'n bedrijf weinig om mee te werken, terwijl datzelfde bedrijf je meestal op één namiddag kan tonen waar het wachten zit.

De eerste zet is dus geen systeem. Kies één van de drie families, schrijf de stappen op één blad met een naam bij elke stap, neem daarna de dossiers van vorige maand en tel hoeveel er in die volgorde doorgegaan zijn en hoeveel niet. Dat tweede getal is je lijst. In een KMO is die meestal kort en meestal dezelfde drie oorzaken: een goedkeuring die bij één persoon ligt, een document dat twee keer aangemaakt wordt, en een stap waar niemand verantwoordelijk voor is omdat ze tussen twee mensen valt die allebei denken dat de andere ze doet.