Purchase Requisition Approval Process: Thresholds, Approval Chains, and Workflow
By Kirill Stolbushkin
Short answer: A purchase requisition approval process is how a request to buy something gets checked and authorized before anyone places an order. An employee submits a requisition, someone checks it against policy and budget, it goes to the people with spending authority for that amount and category, and it comes back approved, rejected, or returned for changes. Once approved, purchasing turns it into a purchase order. The two things that decide whether the process works are your spending limits and how you handle the requests that do not fit them.
In many smaller companies, buying starts with a chat message: "Can I get this?" Sometimes the right person answers. Sometimes the purchase happens first and the approval is pieced together later. A clear requisition process gives requesters one way to ask, approvers what they need to decide, and finance a view of spend before it is committed.
Purchase requisition vs purchase order
A purchase requisition is an internal request. It says what someone needs, why, roughly what it costs, and which budget pays for it. It commits nothing.
A purchase order is an external document sent to a vendor. Once the vendor accepts it, it is a commitment to buy.
The requisition is where you decide whether to spend. The purchase order is where you buy. This guide covers the first part and stops at the approved requisition.
Where the process starts and stops
The process begins with a submitted request and finishes when an approved requisition reaches the person who places orders. Everything after that, raising the purchase order, receiving the goods, matching the bill, and paying, belongs to the wider procure-to-pay cycle. Our procure-to-pay use case shows an example app that takes a request through conditional approval, the purchase order, delivery, and reconciliation. Vendor bills get their own invoice approval workflow later, with different checks and different people.
The purchase requisition approval process, step by step
Step 1: The requester submits a complete requisition
Give every request a single entry point, such as one form. A requisition should carry:
What is being bought, how many, and a description specific enough to order from.
Estimated cost, plus quotes if your policy asks for them above a certain amount.
A suggested vendor, if the requester has one in mind.
The department, project, or budget line paying for it.
The date it is needed by.
A short business reason.
Make the required fields actually required.
Step 2: Check it against policy
Purchasing or finance does a quick screen before any approver sees it:
Can it be bought from an approved vendor or under an existing contract?
Is the same request already in progress?
Does it look split? Two requests for half the amount each, submitted a day apart, are a classic way around a spending limit.
Are the required quotes attached?
Anything that fails goes back to the requester with a specific reason.
Step 3: Check the budget
Confirm the budget line has room. If it does, the request moves on. If it does not, have a written rule for what happens next: the budget holder agrees to the overspend, finance moves money from another line, or the request waits for the next period.
Step 4: Route it to the right approvers
Your spending limits table, covered below, picks the approvers from the amount, the category, and a few other facts about the request. Requesters should never have to figure out who to ask.
Step 5: Add specialist reviews in parallel
Some purchases need a different kind of review whatever they cost:
IT or security for software, cloud services, and anything that touches company data.
Legal when the purchase comes with new contract terms.
Purchasing when the vendor is new and needs to be set up.
None of these depends on the others, so they can run alongside the budget approval rather than in a queue behind it. Software and IT requests often arrive through the IT helpdesk instead of the purchase form. Apply the same approval rules there too.
Step 6: Decide
Each approver can say yes, say no and explain why, or send the request back for changes. A request sent back goes to the requester, then through the policy check again. A declined request ends there, and the requester hears the reason.
Step 7: Hand off to purchasing
Purchasing receives the approved requisition and raises the purchase order. If the final price comes in noticeably above the approved amount, beyond the variance your policy allows, the request goes back for approval instead of going ahead quietly.
How to set spend thresholds
Spend thresholds, also called approval limits or spending authority, set how much each role can sign off on. Put them in a table and tie them to roles rather than names, so the table still works after people change jobs.
Factors that usually drive routing:
Amount: the main driver. Bigger requests go higher.
Category: software, contractors, capital equipment, and marketing often have dedicated approvers.
Budget status: in budget or over it.
Vendor: already approved or brand new.
Commitment length: a one-off purchase or a multi-year contract.
An example, with the dollar limits left for you to fill in:
Small, in budget, from an approved vendor: the requester's manager signs off, or your policy may allow automatic approval.
Mid-sized: the manager first, then the budget holder.
Large: the finance manager or controller joins the chain.
Very large or strategic: a founder, CEO, or CFO has the final say.
Software, at any amount: IT reviews it. New contract terms: legal reviews them.
Keep the bands few. Every level adds waiting, and approvers who see too many small requests stop reading them.
Designing approval chains
Sequential approvals happen in order, typically manager, then finance, then an executive. They make sense when a later approver needs the earlier decision first.
Parallel approvals go to several people at once. They suit independent reviews, like finance and IT both looking at a software purchase. Switching independent reviews from sequential to parallel is often the quickest way to speed up a slow chain.
Two more rules help. Give each approver a backup, so time off does not freeze requests. And agree on a response window: when it passes, the approver gets a nudge, and if it passes again the backup takes over.
Segregation of duties
A requisition process is also a control. Keep these duties apart, even in a small company:
Nobody approves their own request.
Whoever approves a purchase does not also place the order with the vendor.
Whoever signs for the delivery is not the only person who approves the vendor's bill.
Whoever adds vendors to the approved list cannot approve purchases from those vendors.
If one person must hold two of these roles, have someone else review their purchases each month. If you need to document these controls for an audit, our guide to SOX internal controls documentation explains what reviewers look for. If you map procurement for clients, see process mapping for consultants.
Handling the exceptions
Urgent purchases: an emergency route that only named people can use, with approval required within a few days afterwards.
Over budget: follow the written rule from step 3.
Silent approver: a nudge, then the backup approver.
Write each path down.
How the process maps to BPMN
Each step above becomes a shape in a BPMN diagram. If any of these are new to you, the BPMN symbols cheat sheet covers them.
Start event: a requisition is submitted.
Lanes: requester, purchasing, budget holder, finance, and specialist reviewers, laid out as swimlanes so you can see where duties stay separate.
Exclusive gateways: complete or incomplete, in budget or over, and which spending band applies.
Inclusive gateway: pulls in IT, legal, or vendor setup reviews when the request needs them, with a matching gateway that waits for all of them to finish.
Timer boundary events: a nudge to a slow approver, then a handover to the backup.
Loop: requests sent back return to the requester.
End event: requisition approved and passed to purchasing.
How to model and automate this in Vevos
Type out your purchasing policy in plain sentences, or upload the policy document you already have, and Vevos generates a BPMN 2.0 model with lanes, gateways, and timers, plus process documentation you can share. For example:
"An employee submits a purchase request with a budget line and a reason. Purchasing checks it is complete and not already requested. If the budget line has no room, the budget holder decides. Larger requests also go to the controller, and the largest to the CEO. Software requests go to IT at the same time. Approvers get a nudge after two days, and after four days the request moves to their backup. Approved requests go to purchasing to raise the PO."
Go through the model with purchasing and two or three regular approvers, then run last month's requests through it on paper to see if every one lands in the right place. Before go-live, push one mock request all the way from submission to purchasing. Our guide on how to review an AI-generated process model has a checklist for that review.
Start with the free AI process mapper, no account needed. You can start free, with $9 and $29 plans for more room. When you want a working requisition approval app, Conductor Agents, the Vevos agents that build apps from a model, can build and deploy one from your reviewed model, starting on Tempo at $199/month. Details are on the pricing page.
FAQ
What is a purchase requisition approval process?
It is the path a request to buy something takes before an order is placed: submission, policy and budget checks, routing to approvers by spend threshold, specialist reviews where needed, and a decision. An approved requisition becomes a purchase order.
What is the difference between a purchase requisition and a purchase order?
A purchase requisition is an internal request to spend money and commits nothing. A purchase order goes to a vendor and becomes a commitment once accepted. The requisition is approved first, then the purchase order is raised from it.
Who approves a purchase requisition?
Whoever holds spending authority for that amount and budget, usually the requester's manager or the budget holder for smaller requests, with finance and senior leaders added above set thresholds. Some categories, such as software or new contracts, add IT or legal review whatever the amount.
How many approval levels should a requisition have?
As few as your risk allows. Three or four spending bands plus a couple of category rules are often enough for a small team. Add a level only where the risk is genuinely higher.
When does a small company need a formal requisition process?
When more than one person can spend company money, or when purchases regularly happen before anyone approves them. Until then, a simple rule about who can buy what may be enough.
What happens after a purchase requisition is approved?
Purchasing raises a purchase order with the vendor. Delivery, bill approval, and payment follow as separate steps with their own controls.
Related blog posts
- Work Order Process: From Maintenance Request to Close-Out, Step by Step — The work order process for facilities, property management, and field service teams: eight steps from maintenance request to close-out, how to set priorities and cost approvals, the exceptions that stall jobs, and how to draw it as a flowchart.
- Client Onboarding Process: A Step-by-Step Workflow for Agencies and Service Firms — A practical client onboarding process for agencies, consultants, and B2B service teams: seven steps from signed contract to first delivery, which steps every client gets, which depend on the service, and how to map it so nothing gets dropped.
- Customer Support Escalation Process: How to Build a Ticket Escalation Workflow — How to design a customer support escalation process: support tiers, severity levels, clear triggers, handoffs that carry context, an escalation matrix, and how it all maps to a ticket escalation workflow.