Purchase requisition process flowchart
Purchase requisition process flowchart: specification and GL coding, budget check, manager and threshold approval, procurement review and an urgent fast track.
How it works
Name the roles you actually have
Rename the five swimlanes to your real functions. In smaller organisations the line manager and the budget holder are the same person: merge those lanes rather than drawing two approvals that one person gives at once. Use one lane per decision-maker, not per named individual, so the chart survives someone changing job.
Set your thresholds and the second approver
Replace the generic "Value over approval threshold?" decision with the figures from your delegation of authority schedule, and state the currency. Name who the second approver is at each band. Add a third band only if you genuinely have one, and watch for requisitions split just under a limit.
Decide what the budget check tests, and when
Move the check earlier if your system blocks a requisition at submission, or leave it before the approval gates if finance validates afterwards. Record whether it tests committed spend (open requisitions and open purchase orders) as well as posted actuals, because the two give different answers.
Write down what "correctly specified" means
Turn procurement's review into a stated checklist: quantity and unit of measure, need-by date, specification or quote attached, contracted supplier or catalogue item, and correct GL code. Without it, the return-for-clarification loop runs on individual judgement and requesters cannot predict it.
Bound the fast track before you publish it
Define who may invoke an urgent requisition, cap the value, require the same cost centre and GL coding as any other request, and set when the fast-track justifications get reviewed. An unbounded fast track becomes the default route within a quarter.
Circulate the map and keep one current version
Share the chart with procurement, finance and every approver named on it, capture their sign-off on the chart itself so there is a record of who agreed which version, and link the current version from your purchasing policy rather than pasting a screenshot into a 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 specification, the cost centre and the GL code, is routed for budget and management approval, and creates no obligation to a supplier. A purchase order is the external commitment issued once the requisition is approved, fixing item, quantity, price and delivery terms. Everything in this chart happens before the PO exists; the final step is procurement raising the purchase order from the approved requisition.
Who should approve a purchase requisition?
Two roles, sometimes held by one person. The line manager confirms the need is real and appropriate; the budget holder owns the money and confirms the cost centre can carry it. Above a value taken from your delegation of authority schedule, a second approver signs as well. Procurement reviews the requisition but does not approve the spend, which keeps the person specifying the purchase separate from the person committing the funds.
What should a purchase requisition include?
Enough for someone else to buy it without asking you anything: a description or specification, quantity and unit of measure, need-by date, estimated value and currency, cost centre and GL code, any contracted or preferred supplier, a quote or link where one exists, and a short business justification. Missing coding and vague specifications are the two things that send requisitions back, which is why this template puts both before the first approval gate.
How should urgent or emergency requisitions be handled?
With a route that is defined rather than improvised. In this chart an urgent flag goes to a "Urgent need justified?" check, and anything that fails it drops back into the standard sequence. Genuine urgencies get single-approver authorisation from the budget holder, but still record a fast-track justification and still meet the same PO creation step. Cap the value the fast track can carry and review the justifications periodically, or the exception quietly becomes the process.