Purchase requisition process flowchart

What the purchase requisition process is

A purchase requisition is an internal request to buy something. It carries no obligation to a supplier: it exists so the organisation can agree what is being bought, who is paying for it and whether the money is there, before a buyer commits. The requisition process is everything between someone identifying a need and procurement converting an approved requisition into a purchase order.

Requisitions rarely stall on the approval decision itself. They stall because the specification is too vague to buy from, because the cost centre or GL code is missing, or because nobody is sure who signs once the value crosses a threshold. Each of those sends the request back to the requester, usually days later and usually by email, so the return trip never appears in the system's cycle-time report. Mapping the requisition stage across lanes makes those loops visible and shows who is holding the request at any point.

This template covers the requisition stage only, in detail, across five lanes: requester, line manager, budget holder, procurement and finance. It includes the budget availability check, the line manager decision, value-threshold routing to a second approver, procurement's "Correctly specified?" review with a return-for-clarification loop, and a separate fast track for urgent requisitions that still records why the fast track was used.

What this flowchart covers

In this template

• The Requester lane up front: purchase need identified, requisition raised with a specification someone can actually buy from, then cost centre and GL code added before it moves.
• An "Urgent requisition?" branch at the point of raising, sending standard requests into the normal approval sequence and urgent ones into the fast track.
• A budget availability check in the Budget holder lane, whose "No" branch reaches a "Resubmit with changes?" decision that either returns to the requisition or ends at "Requisition declined".
• Two approval gates in sequence: the line manager decision, then "Value over approval threshold?", which routes anything above the limit to a second approver in the Budget holder lane. A rejection at either gate rejoins the same resubmit decision rather than dying silently.
• Procurement's "Correctly specified?" review with a return-for-clarification loop back to the requester, so an unbuyable requisition comes back while it is still a requisition.
• Two closing paths that meet at PO creation: finance confirming coding and funds on the standard route, and emergency authorisation by the budget holder plus a recorded fast-track justification on the urgent one.

When to use this template

• Documenting the requisition stage before configuring approval rules in an ERP or procure-to-pay tool, where the route has to be agreed before anyone builds it.
• Cutting requisition cycle time when requests keep bouncing back for missing coding or an unusable specification.
• Setting or reviewing delegation of authority thresholds, when you need one picture of who approves what at which value.
• Onboarding requesters and approvers who need to see where their step sits and what happens downstream if they leave it.
• Bringing urgent purchases under control by defining a fast track that exists on paper, instead of phone calls that route around the process entirely.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.