What is procure-to-pay?
Procure-to-pay is the run from a site asking for material to the vendor being paid for it — requisition, purchase order, receipt, invoice, match, payment.
Also called P2P.
Procure-to-pay in plain words
Mining it shows two things at once: where material requests stall before they reach a vendor, and where payments leave earlier or later than the terms that were agreed.
Procure-to-pay: a worked example
One material request, from site to vendor payment.
- Requisition raised → PO issued
- 7 d
- PO issued → goods received
- 12 d
- Goods received → invoice matched
- 19 d
- Matched → payment released
- 17 d
- Total
- 55 days, with the longest wait at matching
Read from the PO date instead of the requisition, the first seven days vanish — and that is the stretch site complains about.
Why does procure-to-pay matter?
Both ends cost money. A slow front end delays site work; a fast back end spends cash before it needed to be spent.
Where does procure-to-pay mislead?
Purchase orders raised after the invoice has arrived are common and will make this process look fast when read from the PO date. Mine it from the requisition, or the delay before the PO is simply not in the data.
What do people get wrong about procure-to-pay?
- Mining from the purchase order
- POs raised after the invoice has arrived are common, and they make the process look fast while the real delay sits before the PO existed.
- Treating matching delay as a finance problem
- Most match failures trace back to a missing GRN or a rate that was never updated on the PO. The fix is upstream of the people being chased.
How does Crestline measure procure-to-pay?
Crestline mines the process from the requisition, groups match failures by cause, and flags payments that left earlier or later than that vendor's agreed terms.
The procure-to-pay lens