Procure-to-pay (P2P) process flowchart (need to payment)
Procure-to-pay process flowchart from an identified need to a paid supplier: requisition, budget and delegated-authority approval, contract check, PO issue, receipt, three-way match, no-PO exceptions and the payment run.
How it works
Rename the lanes to your organisation
Replace Requester, Budget holder, Procurement, Supplier, Accounts payable and Finance with the roles you actually have. Split accounts payable from Finance only if different people post invoices and release payment runs; merge them if one person does both, rather than leaving a lane that never acts. If a shared service centre holds the invoice work, name it. If goods-in is a separate team from the requester, add a warehouse lane and move the receipt step into it.
Write both approval thresholds as figures
"Funds available in the cost centre?" and "Above the delegated authority limit?" are inert until you attach numbers. Publish the delegation schedule as amounts by role, state whether the test is the order value or the whole-of-life contract value, and decide how commitments already raised against the same budget line are counted. Then write down what happens to a requirement split into two under-limit orders, because splitting to dodge the next signature is the most common way this control is defeated.
Set the three-way match tolerance
Put your real figures on "Three-way match within tolerance?": a percentage and an absolute cap on price, whichever is lower, and a tighter tolerance on quantity than on price. Decide separately how carriage, duty, rounding and foreign exchange differences are treated, because those break more matches than the goods ever do. State who may override a match failure and record every override, since an unlogged override is indistinguishable from no control at all.
Define receipting for services, not just goods
"Goods or service receipt recorded?" is the gate that fills most exception queues: goods get a receipt on the dock, services frequently get nothing. Name who confirms that a service was delivered — normally the requester who asked for it, not the buyer who placed the order — and set the deadline from the order's expected completion date. For milestone or retainer contracts, decide whether receipt is per milestone or per period, and put open unreceipted orders on somebody's report so they are chased before month end.
Agree the no-PO exception route and its exemptions
"Retrospective PO authorised?" is what makes no-PO-no-pay workable. Decide which categories are genuinely exempt, such as utilities, rent, statutory fees and some professional retainers, and exclude them at the "Purchase order referenced?" gate rather than arguing case by case. Then name the authoriser — the budget holder who would have approved the original requisition, never accounts payable — and report retrospective orders monthly by department, so the exception stays exceptional.
Walk it through with the people who do the work, then publish a version
Take the finished chart to a requester, a budget holder, a buyer, an AP clerk and whoever releases the payment run, and correct it to what actually happens rather than what the policy says. Ask each of them which step they have quietly stopped doing. Agree the measures that come out of "Update the vendor and spend records", then publish that revision while keeping the earlier ones, so anyone opening the chart later can tell which version they are reading.
Frequently asked questions
What are the steps in a procure-to-pay (P2P) process?
A complete cycle runs: identify the need; raise a requisition with a specification and cost centre coding; confirm funds are available; check the value against the delegated authority schedule and escalate anything above it; check whether an approved contract or framework already covers the requirement and go to market if not; issue the purchase order to the supplier; receive the goods or services and record the receipt against the order; take in the supplier invoice and check that it quotes a valid purchase order and that a receipt exists against it; run the three-way match of order, receipt and invoice; resolve variances outside tolerance as exceptions with the supplier; post the matched invoice; release it in a payment run; and update the vendor and spend records so the next sourcing round has evidence. The list is not the hard part. What breaks the cycle is the receipt nobody records and the invoice that arrives with no order behind it.
What is a three-way match and what tolerance should I set?
A three-way match pays an invoice only where the purchase order, the goods receipt and the invoice agree on item, quantity and price. The definition is the easy part; the figures are the work. Matching to the penny would push almost every invoice into a queue, so set both a percentage and an absolute cap on price variance and apply whichever is lower, and hold quantity to a tighter tolerance than price — a small price difference is a rounding argument, a small quantity difference is missing stock. Write separate rules for carriage, duty, rounding and exchange differences, which break more matches than the goods ever do. Then decide what happens with services, where there is often no countable receipt at all and organisations fall back to a two-way match against the order or to a milestone confirmation from the requester. Publish who may override a failed match and log every override: an unwritten tolerance is applied differently by every clerk, and an unlogged override means the control cannot be evidenced even when it worked.
What does no PO, no pay mean in practice?
It means an invoice that does not quote a valid purchase order is not paid, and is returned to the supplier instead. The reasoning is that without an order there is no agreed price, no commitment recorded in the ledger, and no evidence that anyone with authority approved the spend before it was incurred. In practice a blanket policy fails unless two things are settled first. There must be a published list of exempt categories — commonly utilities, rent, business rates, statutory fees and some professional retainers — which are excluded at the gate rather than argued over individually. And there must be a defined exception route for everything else: in this chart an unreferenced invoice goes to "Retrospective PO authorised?" in the budget holder's lane, so the person who should have raised the requisition has to authorise it after the fact, it is logged, and it is reported by department. Without that route the desk quietly raises retrospective orders itself and the policy becomes paperwork.
How is this different from the ERP P2P process flow template?
They are the same cycle written for different readers. The procure-to-pay process flow template at /templates/erp/p2p-process-flow frames the cycle as a set of control points for SOX and ICFR purposes: process owner, system of record, approval gate and evidence at each step, in the form an external auditor walks in a controls test. This page is the operational flow for the people who run it — six swimlanes, the two-part approval gate, the tolerance decision, the exception loop and the no-PO route — and it is written to be edited into your own thresholds rather than presented to an auditor as-is. There is also a scope difference at the ends: this chart starts at the identified need and finishes at the spend report, whereas the control-framed version concentrates on the requisition-to-payment span where the financial statement assertions sit. Use that one for the audit file, this one for the process.
Should I use this or the individual purchase order and invoice flowcharts?
Use this one when the problem crosses stages, and the single-stage pages when it does not. This chart compresses each stage to the steps that the next stage depends on, so it can show the whole cycle on one page — which is what you need when receipts are missing, when invoices arrive without orders, or when nobody can say how long requisition-to-payment actually takes. It is deliberately shallower than the stage pages. If you are redesigning approval thresholds and requisition coding, /templates/purchase-requisition-process goes much further. For order raising and issue, /templates/purchase-order-process. For the goods-in dock, discrepancies and carrier claims, /templates/goods-receiving-process. For the per-invoice path including duplicate checks and coding, /templates/invoice-approval-process. For the payment run, statement reconciliation and period-end accruals, /templates/accounts-payable-process. Most organisations end up with both: this one in the policy, the stage charts in the work instructions.