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.
What the procure-to-pay (p2p) process flowchart (need to payment) process is
Procure-to-pay is the process that almost every organisation runs and almost nobody owns. Purchasing owns the order, the budget holder owns the approval, the warehouse owns the receipt and accounts payable owns the invoice, and each of those four is measured on its own stage, so each one is efficient and the cycle as a whole is slow. The damage always lands at the far end. An invoice cannot be matched because nobody recorded the receipt, or because the order was raised after the goods arrived, or because the price on the order was never the price that was agreed. Accounts payable then absorbs the consequence of decisions made weeks earlier by people who will never see the exception queue, and the fix that gets applied is a retrospective purchase order, which clears the backlog and destroys the commitment accounting at the same time. Nobody measures requisition-to-payment as a single number, so the total cycle time is invisible even to the people who complain about it, and the supplier chasing payment is the only party with a view of the whole thing.
This page is the operational end-to-end flow, and it is deliberately the stitching rather than the detail. Each stage on it already has a page of its own: the internal route a request takes before any order exists is at /templates/purchase-requisition-process, order raising and issue at /templates/purchase-order-process, the goods-in dock at /templates/goods-receiving-process, the per-invoice path at /templates/invoice-approval-process, and the whole AP function including payment runs and period-end accruals at /templates/accounts-payable-process. If you only need one stage, go to that stage's page: the depth there is greater than anything here. Sourcing strategy, tendering, evaluation and the supplier relationship afterwards belong to /templates/procurement-process, which starts from the same identified need but turns left into the market rather than into the ledger. And if what you actually need is the control-framing of the same cycle for SOX, ICFR or an external walkthrough, /templates/erp-p2p-process-flow is written for that audience. This chart is for the person asked to make the cycle work.
Three things that written P2P procedures leave implicit are drawn here as branches. The approval gate is split in two, because "Funds available in the cost centre?" and "Above the delegated authority limit?" are different questions with different owners (budget says the money was planned, delegation says this person may commit it) and conflating them is how a funded order gets signed by somebody with no authority to sign it. Matching is split in two for the same reason. "Goods or service receipt recorded?" is asked before "Three-way match within tolerance?", because a missing receipt goes back to the requester and a price variance is a conversation with the supplier, and a queue that mixes the two never gets worked. The tolerance is a threshold rather than a pass mark: the only place in the cycle where an organisation states in figures how much variance it will pay without asking, and left unwritten every clerk applies a different one. And the no-PO route is drawn rather than denied. "Purchase order referenced?" sends an unreferenced invoice to "Retrospective PO authorised?" in the budget holder's lane, which either produces an authorised order that re-enters the match or ends at "Invoice returned unpaid, no PO raised", because a no-PO-no-pay policy with no exception route is not a policy, it is a queue.
What this flowchart covers
In this template
- Six swimlanes (Requester, Budget holder, Procurement, Supplier, Accounts payable and Finance) across six phases: Requisition, Approval, Sourcing and PO, Receipt and invoice, Match and exceptions, and Payment and reporting.
- A two-part approval gate: "Funds available in the cost centre?" declines or defers the requisition on a No, and "Above the delegated authority limit?" routes anything above the signer's limit through "Obtain higher authority sign-off" in the Finance lane before procurement sees it.
- The call-off versus market fork at "Contract or framework in place?", where a Yes goes straight to "Issue the purchase order to the supplier" and a No detours through "Run a sourcing exercise and award" first.
- The commitment chain that makes matching possible at all: the purchase order, "Deliver the goods or perform the service", "Record receipt against the purchase order" and "Submit the invoice for payment", each in the lane of the person who actually does it.
- Matching drawn as two blocks rather than one: "Goods or service receipt recorded?" returns a blocked invoice to "Record receipt against the purchase order" in the requester's lane, while "Three-way match within tolerance?" sends a variance to "Log the exception and query it", the supplier corrects the invoice or issues a credit, and "Exception resolved?" either re-runs the match or leaves the process at "Dispute handled under the contract".
- The no-PO exception route and the tail nobody draws: "Retrospective PO authorised?" either loops back into the match or ends at "Invoice returned unpaid, no PO raised", while the clean path runs through "Post the matched invoice for payment", "Release the payment run to the supplier" and "Update the vendor and spend records" to "Cycle closed and spend reported".
When to use this template
- You are writing or refreshing a purchasing policy and need one diagram that shows the whole cycle, rather than four stage documents that each stop at a hand-off and contradict each other about who does the next bit.
- Your accounts payable exception queue is growing and you need to show that most of the causes sit upstream, in missing receipts and orders raised after the fact, not in the AP team.
- You are introducing or enforcing a no-PO-no-pay policy and need the exception route, the exempt categories and the authoriser agreed before the first invoice is returned.
- You are configuring or migrating an ERP or P2P suite and the tolerance figures, approval thresholds, receipting rules and exception reason codes have to be settled as a process before anyone touches a configuration screen.
- You are onboarding requesters, budget holders or a new shared service centre and want the whole cycle, its two rejection routes and its dispute hand-off taught from a single picture.
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.