By Safock Procurement Research Team8 min read
The procure-to-pay process runs from the moment someone needs something to the moment the supplier is paid. Each handover between people is a place where money can leak. This guide walks through the steps, the leak at each one, the control that stops it, and the numbers worth watching.
The procure-to-pay process is the full cycle of buying, from a request inside the organisation to payment going out to a supplier. It crosses several teams: the people who need things, the managers who approve them, procurement, the store or receiving dock, and finance.
It is also called purchase-to-pay, and the two terms mean the same thing. The process exists to make sure every payment can be traced back to an approved need, an agreed price and a confirmed delivery. When one link in that chain is missing, the organisation is paying on trust.
The procure-to-pay process has nine steps, from identifying a need to paying the supplier. Some organisations merge steps, but each one still happens somewhere, even if only informally.
Money leaks at the handovers, where one person relies on information another person typed or remembered. Each step has its own typical leak.
Each step needs one control that stops its typical leak before the next step begins. Controls placed late in the process, at payment, have to catch everything, which is why they so often fail.
Source-to-pay covers everything in procure-to-pay plus the strategic work that comes before it: finding suppliers, running tenders and negotiating contracts. Procure-to-pay starts once those suppliers and prices exist and covers day-to-day buying.
The distinction matters when choosing tools or assigning ownership. A team with a few large annual contracts and many small orders against them spends most of its effort in procure-to-pay. A team that tenders often for one-off projects spends more time on the sourcing end.
The metrics worth tracking show where requests stall and where invoices fail. A handful, reviewed monthly, tell you more than a large dashboard nobody reads.
Two published figures give useful context. Ardent Partners' State of ePayables 2025 found that 18.4% of supplier invoices hit an exception and cannot be paid as they arrive, and that processing one invoice costs $9.84 on average, with best-in-class AP teams spending 79% less. On the stock side, DeHoratius and Raman, writing in Management Science in 2008, found that 65% of inventory records were wrong across 37 stores of one retailer, a reminder that stock figures need checking before they drive reorders.
Across many sites, the same process has to work for local managers who need speed and a head office that needs one view of spending. Most of the difficulty comes from sites doing the same steps in slightly different ways.
Start by finding where information is re-typed or remembered, because those are the points where errors and leaks enter. Then fix the earliest broken step first, since problems flow downstream and pile up at payment.
A practical order is: map the process as it really runs today, introduce a no PO, no pay rule for suppliers, move receiving onto per-line records at the dock, carry agreed prices onto purchase orders automatically, and only then tighten the match tolerance. Measure exception rates before and after each change, so you can see which fix worked.
Procurement software runs the process end to end by keeping every step as a linked record, so data entered once carries through to payment. Bollard, for example, follows a fixed loop of request, approve, order, receive, match and pay, alongside inventory and transfers between sites. The dashboard shows the value in flight at every stage and a needs-attention queue for each role, and the audit trail records every change with before and after values.
Free tool
Cost per Purchase Order Calculator
Add up the people-time behind each PO, from request to payment, and compare with benchmarks.
Runs in your browser. No sign-up.
The main stages of procure-to-pay are identifying a need, raising a requisition, approving it, sourcing a supplier, issuing a purchase order, receiving the goods, recording the invoice, matching the invoice against the order and receipt, and paying the supplier. Some organisations group these into fewer stages, such as request, order, receive and pay, but the same checks still need to happen.
Yes. Procure-to-pay and purchase-to-pay describe the same process, and both are shortened to P2P. They cover the cycle from an internal request to paying the supplier. Source-to-pay is the broader term, which adds supplier selection, tendering and contract negotiation before the buying begins, and is often owned by a strategic sourcing team.
Ownership of procure-to-pay is usually shared. Procurement owns the front half, from requisition to purchase order, and finance owns the back half, from invoice to payment. Operations owns receiving. Many organisations name a single process owner, often in finance, who is accountable for the end-to-end controls and metrics even though several teams carry out the steps.
Accounts payable is one part of procure-to-pay. It covers recording supplier invoices, matching them, resolving exceptions and paying them. Procure-to-pay is the whole cycle, including the requisition, approval, purchase order and receipt that come before the invoice. Most accounts payable problems, such as mismatched prices or billed rejected goods, start earlier in the cycle.
A no PO, no pay policy tells suppliers that invoices without a valid purchase order number will not be paid until one is provided. It moves approval to before the purchase, so staff cannot commit spending informally and ask finance to pay later. Most organisations exempt a short list of categories, such as utilities or rent, that are paid against contracts instead.
Maverick spend is buying that happens outside the agreed process, such as ordering from an unapproved supplier, skipping the requisition, or paying above the contract price. It weakens negotiated prices and makes spending harder to forecast. The usual remedies are an approved catalog for each site, a no PO, no pay rule and requisitions that are quick enough that staff have no reason to bypass them.