PURCHASE TO PAY

Wij helpen organisaties met digitale transformatie en procesoptimalisatie van purchase to pay.

TECHNOLOGIE

Wij gebruiken verschillende cloud-oplossingen die passen bij omvangrijker organisaties.

TECHNOLOGIE

Wij werken met verschillende P2P oplossingen die koppelen met toonaangevende ERP systemen.

2 min read

Bespaar geld door meer fouten toe te laten

Bij de implementatie van een purchase-to-pay systeem, wordt gedefinieerd onder welke condities een factuur mag worden ‘gematched’ tegen een order. "Deze condities worden meestal vastgesteld met ‘common sense’ en zijn vaak gebaseerd op jaren van ervaring in het crediteurenproces", vertelt Vincent Wouters. Soms is er zelfs een duidelijke policy aanwezig dat het verschil nooit groter mag zijn dan een bepaald bedrag.

Alle facturen waarvan de afwijking met de order/ontvangst meer afwijkt dan bedrag X, mogen niet automatisch verwerkt worden. Het factuur matching systeem wordt dan zo ingericht dat iedere keer dat een factuur niet voldoet aan de criteria, deze wordt aangeboden voor handmatige verwerking.

Vincent: "Dit betekent dat een factuur apart wordt genomen en wordt opgepakt door een crediteurenmedewerker. In de meeste gevallen kan deze medewerker het prijsverschil niet beoordelen. Hij zal de factuur naar de persoon doorzetten die de bestelling heeft geplaatst. De besteller zal naar de factuur kijken en concluderen dat het verschil verklaarbaar is. De prijzen in het bestelsysteem zijn bijvoorbeeld niet bijgewerkt of om andere redenen blijkt het prijsverschil toch correct te zijn. Hierna wordt de factuur door één of meerdere mensen goedgekeurd en doorgezet voor betaling. Als de prijs niet verklaarbaar is, zal de besteller contact opnemen met de leverancier en een creditfactuur vragen."

Wat hebben we geleerd van dit factuur matching scenario?

We hebben de gewoonte om principes en regels te behouden als ze in het verleden goed werkten. Maar wat als we de data van deze scenario’s kunnen gebruiken om te controleren of de factuur matching condities correct worden gedefinieerd?

 

In de afbeelding een data analyse van een Nederlandse organisatie waar de factuur niet meer mag afwijken dan 10 euro en maximaal 1 procent van het totale factuurbedrag. Wat we zien is de afwijking van de factuur (hoe verder van het midden, hoe groter de afwijking), het aantal facturen met deze afwijking (hoogte van de staaf) en het totale bedrag van de afwijkingen (rode lijn).

Onderzoek van de data leert dat 97 procent van de facturen met een afwijking tussen 0 en 40 euro wordt goedgekeurd zonder communicatie met de leverancier en zonder verzoek tot creditering. Verrassend misschien, maar wel de praktijk.

Maar als de toleranties worden verhoogd van 10 naar 40 euro, zal 100 procent in plaats van 97 procent automatisch worden verwerkt. We missen dan 3 procent die ten onrechte wordt goedgekeurd. Dat lijkt natuurlijk nadelig, maar deze organisatie hoeft door deze aanpassing 7.000 facturen minder te beoordelen! Indien de crediteurenmedewerker en de inkoper gemiddeld minimaal 15 minuten per uitgevallen factuur bezig zijn, is dit 1.750 uur werk. Dit kan dus een significante kostenbesparing zijn tegenover 3 procent onterecht betaalde leveranciers. En de leveranciers die structureel te hoog factureren zijn daarnaast heel eenvoudig in beeld te brengen. Beperkt risico toch?

Conclusie

Mijn conclusie is dat ook in het financiële domein kritisch gekeken moet worden naar principes en regels uit het verleden. Binnen de huidige geautomatiseerde processen kan een bijstelling in factuur matching veel opleveren. Met (big) data analyse en de juiste analytics zijn de rekensommetjes snel gemaakt. Succes.

Vincent Wouters
Managing Director, ICreative
vwouters@icreative.nl
06 22 455 138

Over ICreative

ICreative levert als Basware en Kofax partner, purchase to pay en e-facturatie oplossingen aan grote ondernemingen, multinationals, onderwijs- en overheidsinstellingen. Onze oplossingen bieden meer controle op bedrijfsuitgaven en minder complexiteit van het inkoop tot betalingsproces. Ongeacht de ERP systemen in gebruik, zoals SAP, Oracle en Microsoft, en ongeacht het aantal landen, kantoren, valuta’s en talen waar (mee) wordt gewerkt.