Purchase order process flowchart
Purchase order process flowchart: requisition, budget check, approval thresholds, supplier quotes, PO issue, goods receipt, three-way match and payment.
How it works
Name the roles you actually have
Rename the five swimlanes to your real functions. Smaller teams often merge Procurement into Finance and AP; larger ones split receiving out of the Requester lane. Use one lane per decision-maker, not per person, or the chart stops matching reality the moment someone changes job.
Set your approval thresholds
Replace the generic "Value over approval threshold?" decision with the figures from your delegation of authority schedule, and state the currency. Add a second threshold decision only if you genuinely have three tiers, and set it high enough that it triggers rarely.
Put the budget check where the system enforces it
Move the budget check earlier if your system blocks a requisition at submission, or leave it after manager sign-off if finance validates afterwards. Also decide whether it tests committed spend (open requisitions and open POs) or only posted actuals, and note that on the step.
Adapt the sourcing rules
Add a branch that lets catalogue items or contracted rates skip the quote step, and record how many quotes your policy requires at each value band. If purchasing cards or framework agreements bypass the PO entirely, draw that as its own path rather than pretending it does not happen.
Define the match tolerance and the exception owner
Write your price and quantity tolerance into the three-way match decision, for example 2 percent or 50, and name who owns the mismatch queue. Without a stated tolerance the exception branch absorbs every rounding difference and the queue becomes the real process.
Circulate the map and keep one current version
Share the chart with procurement, finance and every approver named in it, capture their sign-off, and link the approved version from your purchasing policy so people work from the current flow rather than a screenshot in an old training deck.
Frequently asked questions
What is the difference between a purchase requisition and a purchase order?
A requisition is an internal request to buy. It carries the cost centre and coding, is routed for budget and management approval, and creates no obligation to the supplier. A purchase order is the external commitment sent once the requisition is approved, fixing item, quantity, price and delivery terms. In this chart the requisition is raised in the Requester lane, and Procurement issues the PO only after both the manager approval and the budget check have passed.
What is a three-way match?
A three-way match compares the purchase order (what you agreed to buy), the goods receipt note (what actually arrived) and the supplier invoice (what you are being asked to pay). If all three agree within tolerance, the invoice can be approved for payment without further review. It is the main control against paying for goods never received, or at a price never agreed. In this template it is the decision node that gates payment, with a mismatch branch back to procurement.
What should happen when the invoice does not match the PO or the receipt?
Send it to a named owner rather than leaving it in the AP queue. The usual causes are a price change the supplier applied without a PO amendment, a short or partial delivery, or a goods receipt nobody recorded. The template routes mismatches to procurement to resolve with the supplier, then returns to the match decision once the PO, GRN or invoice has been corrected, so nothing gets paid on the strength of an email.
How many approval levels should a purchase order process have?
Fewer than most organisations run. Two covers the majority of spend: the budget holder for everything, plus a second approver above a value threshold taken from your delegation of authority schedule. Each extra level adds cycle time and encourages people to split orders to stay under a limit, which is exactly the behaviour the threshold is meant to prevent.