A marketing manager needs a $14,000 analytics subscription. She emails her director, who replies, “Approved, go ahead.” She signs the order form. Six weeks later, finance discovers that the company already had that platform under a negotiated contract in another department, with unused seats.
Nobody did anything wrong. There was an approval. It just happened in an inbox, where no one could check the budget, spot the existing contract, or record what was authorized.
The purchase requisition process exists to move that decision out of the inbox. It is the internal request-and-approval step that happens before anyone contacts a supplier, and it is the easiest point in the entire procurement cycle to catch a purchase that shouldn't happen.
At Tradogram, we have helped thousands of organizations digitize their procurement processes, and requisitions are consistently the part of the process where you can gain the most control with the least disruption.
This guide covers what a purchase requisition is, how the process runs end to end, how to design the approval workflow, and what changes when you automate it.
Key Takeaways
- A purchase requisition is an internal request for permission to buy, and a purchase order is the external document that commits the organization to the purchase. The requisition is approved first, then becomes a purchase order. Getting that sequence right makes spend controllable, because a requisition can be declined at no cost, while a purchase order is a legally binding commitment.
- The purchase requisition process is the easiest place in procurement to prevent a bad purchase. You can check budget availability, duplicate purchases, existing contracts, and preferred vendor pricing before committing money. Every control applied later, at invoice processing or payment, is cleanup, not prevention.
- Approval delays are almost always a process problem, not a people problem. Requests that arrive without cost estimates or business justification stall because approvers cannot decide, and unclear approval limits send requests to the wrong person. Fix both by changing the requisition form and the approval rules, not by chasing approvers.
- Every approved purchase requisition creates an audit trail that connects a request to a decision to a purchase order. That record makes financial audits straightforward and lets the finance team investigate variances between an invoice and what was actually authorized.
- Automation is worth it when it enforces the rules you have already agreed on, not when it replaces the decision. Routing by amount and department, checking budgets at submission, and generating the purchase order from the approved requisition remove waiting and rekeying while leaving judgment with the approver.
What is the purchase requisition process?
The purchase requisition process is the internal workflow an organization uses to request, review, and approve a purchase before committing to a supplier. It starts when an employee submits a purchase requisition form describing what they need and why, and it ends when an approved purchase requisition is converted into a purchase order. It is the first controlled stage of the wider procurement process.
A purchase requisition, sometimes abbreviated to PR, is an internal document. It asks for permission to buy, and purchase requisitions sit at the front of the wider procure-to-pay process, before any external commitment exists.
It has no standing outside the organization and creates no obligation to anyone. That is the point: the company can still reverse the decision at no cost. For a fuller breakdown of the terminology and the components involved, see our guide to what a requisition means in procurement.
A formal purchase requisition process gives you four things a verbal or email approval cannot:
- Budget visibility before commitment. Procurement spend management software lets the budget owner see what is left, including purchases already approved but not yet invoiced.
- A consistent record. Who asked, what for, at what estimated cost, and who approved it.
- Policy applied evenly. The same spend thresholds and approval rules apply to every department, which keeps budget control consistent rather than dependent on who is asking.
- A starting point for measurement. You cannot measure a purchasing process whose first step happens in someone’s inbox.
Not every organization needs the same amount of process. A ten-person company with one approver needs a form and a threshold. A multi-location organization with departmental budget owners needs approval tiers, delegation rules, and integration with its procurement system.
The structure should match the number of people who can commit money, which is a better guide than headcount or revenue.
Purchase requisition vs. purchase order: the difference that matters
The difference between a purchase requisition and a purchase order is direction and legal weight.
A purchase requisition is internal and asks for permission. It goes from an employee to an approver inside the organization. Declining it costs nothing.
A purchase order is an external document sent to the supplier. Once accepted, it forms a legally binding contract covering price, quantity, and terms. Purchase order management software is where most organizations first see that commitment tracked properly. Canceling it may carry a cost.
The sequence matters more than the definitions. The requisition is approved first, and only then does it become a purchase order. Organizations that reverse this order, issuing purchase orders and raising requisitions afterward to satisfy the accounting system, keep the paperwork but lose the control, because by the time the requisition exists, the money is already committed.
We cover the document-by-document comparison in more depth in purchase orders vs. requisitions, including where each one sits in the procure-to-pay process.
What goes on a purchase requisition form
The purchase requisition form is the single highest-leverage thing to get right in the entire purchasing process. Every field you require is a question an approver doesn't have to go back and ask, and back-and-forth drives most approval delays.
A workable requisition form captures:
- Requester and department, so the request routes to the correct budget owner
- Item or service description with quantity and specification
- Estimated cost, per unit and total, since approval limits are usually value-based
- Budget line or cost center the purchase should draw against
- Business justification, in a sentence, explaining why this is needed now
- Suggested vendor, and whether they are on the approved vendors list
- Date required, which tells the approver how much urgency is real
- Supporting documents such as a quote, specification, or renewal notice
Two fields are worth defending when someone asks to remove them.
- Estimated cost, because without it an approver cannot check budget availability, which is the most common reason we see requisitions returned.
- Business justification, because it is the field that lets an approver distinguish a necessary purchase from a convenient one.
If your approvers routinely ask the same follow-up question, make it a field.
The purchase requisition process, step by step
A structured purchase requisition process has six steps. Organizations vary in how formally they treat each one, but skipping any of them moves a control downstream where it costs more to apply.
1. Identify the need
An employee or department identifies a requirement for goods or services. This sounds trivial, and it is the step most often skipped in practice, because the requester frequently starts by contacting a supplier for a quote and only then works backward to a formal request.
That order is worth correcting. A quick check against existing contracts, current inventory, and other departments’ upcoming purchases at this stage is what prevents duplicate purchases and captures pricing agreements you have already negotiated.
2. Complete the requisition form
The requester submits a purchase requisition form with the item description, quantity, estimated cost, budget line, business justification, and suggested vendor. Attaching a quote or specification now removes a round trip later.
3. Initial review
Before approving, someone checks the request for completeness and policy fit. In smaller organizations, the approver does this themselves. In larger ones, procurement teams screen requisitions first, checking whether an approved vendor already covers the category, whether a negotiated contract applies, and whether the estimated cost looks realistic. Keeping those records current is central to supplier management software.
This is also where preferred vendor usage gets enforced. Redirect requests to a contracted supplier when one already serves that category, not after the purchase order goes out. Negotiated contracts only save money if someone checks them before placing the order.
4. Approval decision
The requisition routes to the approver whose authority covers it, based on amount, department, category, or budget line. The approver checks budget availability, confirms the business justification, and approves the request, declines it, or sends it back for more information. A complete form is what lets them make informed decisions quickly instead of scheduling a conversation.
5. Convert to a purchase order
Once the requisition is approved, it becomes a purchase order and goes to the supplier. An approved requisition should carry its line items, quantities, prices, and terms straight through, since retyping them is where order errors originate.
6. Record and retain
Store the approved purchase requisition, the approval decision, and the resulting purchase order together. Accounts payable uses this record to check an invoice during three-way matching and invoice processing, and auditors ask for it.
The purchase requisition approval process
The purchase requisition approval process is the part of the workflow where a request is checked against budget and policy, then authorized or declined by someone with the standing to make that call. It is also where most of the elapsed time in a manual requisition process sits, and where most of the value is created.
APQC benchmarking across 514 organizations found that top performers, the top 10%, place a purchase order in a median of 8 hours against 11 hours for everyone else. The gap is rarely review time. It is the interval between a request arriving and an approver seeing it.
Set approval limits and spend thresholds first
Approval limits define the maximum value each role can authorize without escalating. Write them as a table, not a policy paragraph, for example:
- Up to $2,500: department head
- $2,501 to $25,000: department head plus finance team review
- Above $25,000: adds the CFO or an executive sponsor
- Any amount: goes to legal if it involves a new contract term
Spend thresholds should reflect real risk, not organizational hierarchy. A recurring $2,000 software renewal deserves less scrutiny than a first-time $2,000 purchase from an unvetted supplier, and approval rules that cannot make that distinction end up applied inconsistently or ignored.
A threshold can be justified on both cost and risk grounds. APQC puts the cost to process a single purchase order at anywhere from about $14 to more than $54, depending on how the work is structured. Applying a full approval chain to a $40 purchase costs more than the decision is worth.
Choose the right approval workflow shape
Three shapes cover almost every situation, and mixing them by request type is normal.
Single-level approval. One approver, usually the department head. Fast and appropriate for low-value requests within an agreed budget.
Multi-level approval. The request moves through approval tiers in sequence, typically manager, then finance, then executive. Required above a threshold, and a major source of approval bottlenecks because each tier adds waiting time.
Parallel approvals. Two or more approvers review at the same time rather than in sequence. Useful when finance and a technical reviewer both need to sign off but neither depends on the other’s decision. Parallel approvals are the most underused option and often the single fastest fix for a slow multi-level workflow.
The design goal is to match the number of approvals to the risk. As Sarah Wilson, Fractional COO and founder of Brightpoint Operations, puts it: “Finding a balance between approvals and process speed is critical.”
Route requests to the appropriate managers automatically
Manual routing, where the requester decides who to send a request to, produces two failures at once:
- Requests that sit with someone who lacks the authority to approve them
- Requests that skip an approver who should have seen them.
Configurable approval workflows solve this by routing on the data already in the request. Amount, department, category, GL code, project, and location can each drive the path, alone or in combination. Different requisition types can follow entirely different routes, so a capital expenditure and an office supplies reorder do not travel the same chain.
Build in escalation
Every approval rule needs an answer to “what happens if nobody responds.” Delegation during absence, automatic reminders, and escalation to the next tier after a set period are what keep approval delays from becoming invisible.
Without them, a single approver on vacation can stall a department’s purchasing for a week, and nobody notices until someone asks.
Why purchase requisitions matter
A formal purchase requisition process isn't paperwork for its own sake. Each control prevents a specific, expensive thing.
They stop unauthorized purchases before money moves. A requisition means no one commits company funds without someone else agreeing. That is the entire basis of purchase requisition control, and it is why the requisition, not the invoice, is the real point of financial control. Maintaining control at this stage costs a conversation, while maintaining control at the invoice stage costs a refund negotiation.
They give budget owners visibility before commitment. Approved requisitions that haven't become invoices are a real claim on a budget. Seeing them is the difference between a budget report that reflects reality and one that produces budget overruns at quarter-end.
They prevent duplicate purchases and unnecessary purchases. Centralizing purchase requests is what surfaces the second seat on the same platform, or the negotiated contract another department signed last year. Sarah Wilson, Fractional COO and founder of Brightpoint Operations, frames the point well: “The purpose of a control is not to slow down the process too much but to put an opportunity to reflect on if something is genuinely needed.”
They reduce fraud risk by separating roles. Wilson is direct about the mechanism: “Another critical area to remember when reducing fraud risk in your company’s procurement process is to separate who does the buying and who pays the invoices. The separation of duties by business function is called the segregation of duties, which means that specific processes are divided by departments to reduce overall business risk.”
They create an audit trail. Every approved requisition links a request to a decision to a purchase order. During financial audits, that chain answers the only question that really gets asked: who authorized this, and against what budget. It also gives the finance team something concrete to check when an invoice does not match what was requested.
They make purchasing measurable. As Wilson notes, “Purchase requisitions are a great starting point to measure the performance of your procurement process overall.” You cannot report on cycle time, preferred vendor usage, or realized cost savings if the first step of the purchasing process happens in an inbox.
For six specific arguments you can take into an internal conversation, Wilson’s six reasons to use purchase requisitions cover the case in more depth.
Where the requisition process usually breaks down
These are the patterns finance and procurement teams describe to us most often.
Missing cost estimates. A requisition arrives with a description and no number. The approver cannot check budget availability, so it sits. In the teams we work with, this gap stalls the most requests. The issues with incomplete requisitions don’t always stop at approval. They also arrive later as invoices nobody can match. Ardent Partners research puts invoice exception rates at 9% for best-in-class organizations against 22% for everyone else, and most of that gap is created upstream, at the request.
Approval limits nobody can state. Ask three managers who sign off on a $15,000 purchase, and you often get three answers. Requests then wait for approvals they never needed, or skip approvers they should have reached.
Sequential approval tiers that should be parallel. A three-tier chain where each reviewer waits for the previous one turns three ten-minute reviews into a nine-day process. Most approval bottlenecks are a routing shape problem.
No visibility for the requester. Someone submits a request and hears nothing. They follow up by email, which pulls the approver away from approving. Status visibility removes work rather than adding it.
Requisitions raised after the purchase. Someone buys first and files the paperwork later. The record exists, the control does not, and without proper approvals happening before the commitment, the requisition process becomes an administrative formality that people quietly stop respecting.
Purchase requisition automation
Purchase requisition automation uses software to run the request, routing, budget check, and conversion to purchase order without anyone retyping or forwarding anything.
It is worth doing when it enforces rules you have already agreed on. It is not worth doing as a substitute for agreeing to them, because automating an undefined process just encodes the disagreement into the software.
Here is what changes at each point.
Requisition submission becomes structured. A custom request form with required fields replaces free-text email. Different request types can use different forms, so a contractor engagement asks different questions than a stationery reorder.
Budgets are checked at submission, not at close. The system validates the request against the relevant budget line in real time, including already approved commitments. The budget owner sees the remaining balance on the approval screen rather than discovering the overspend later.
Routing happens on the data. Structured approval workflows send each request to the appropriate managers based on amount, department, GL code, or category, with reminders when a request sits and escalation when it stalls.
Approved requisitions become purchase orders automatically. No rekeying, and the purchase order always exists before the goods arrive.
The audit trail builds itself. Every submission, comment, edit, approval, and rejection is recorded with a timestamp, which is most of what an auditor asks for and none of what anyone wants to assemble manually.
Tradogram’s purchase requisition software reports 75% less time spent on manual approval workflows and 60% fewer compliance violations where consistent controls are applied. The results depend on how disciplined the underlying rules are, which is the honest caveat: the software enforces your policy; it does not write it.
What to look for in a purchase requisition approval system
Most teams evaluating a purchase requisition approval system compare feature lists across the entire process when they should test a handful of specific behaviors. These questions separate tools.
- Can approval rules match your actual authority table? Multi-level, parallel, and conditional routing by amount, department, category, and GL code, not just a single approver field.
- Are budgets checked at submission? A system that validates budget availability only after approval has moved the control to the wrong place.
- Can you configure the requisition form per request type? Required fields, categories, and attachments should differ between a capital purchase and a supply reorder.
- Does an approved requisition become a purchase order without rekeying? This is the join that most point tools miss.
- Is there a real audit trail? Every action, with who and when, exportable.
- Does it connect to your accounting system? Procurement integrations with QuickBooks, Xero, NetSuite, Sage, and Dynamics 365 Business Central decide whether requisition data reaches finance without export files.
- Will requesters actually use it? Requesters are the largest user group and the least invested in procurement controls. A purchase requisition tool that is harder than sending an email will be worked around, and adoption decides whether any of the other answers matter.
A requisition tool that handles only requests, with no link to purchase orders, receiving, or invoice processing, tends to reproduce the original visibility problem in software form. The value comes from the stages sharing one record.
Measuring the purchase requisition process
Four numbers tell you whether the process is working. Track them for a quarter before changing anything so you have a baseline.
Requisition cycle time. Days from requisition submission to approval, and separately from approval to purchase order. Splitting them tells you whether your problem is approvers or processes.
First-pass approval rate. The share of requisitions approved without being returned for more information. A low rate points to the form, not the requester.
Time per approval tier. This is what exposes approval bottlenecks. One tier usually accounts for most of the delay, and it is rarely the one people assume.
Percentage of spend with an approved requisition. How much purchasing actually went through the process before commitment. This is the clearest measure of whether the policy is real, and procurement reporting is what makes it visible without a manual audit.
Our guide to procurement KPIs covers the wider set, including supplier performance and compliance measures.
Fix the form and the limits, then the software
If the process needs work, the right sequence is narrower than a full redesign. Write down the approval limits by role and value, including what happens when an approver is away. Add estimated cost and business justification as required fields on the requisition form, since those two changes alone usually lift the first-pass approval rate.
Measure where the time actually goes by tier, then convert the slowest sequential step to parallel approvals if reviewers don't depend on each other. Only then configure software, and roll it out to one department first.
The organizations that improve fastest do not redesign everything at once. They make the form complete enough to decide on, put the approval limits in writing, and let the rest follow.
In Tradogram, an approved requisition carries its line items, supplier, and budget line straight into the purchase order, and the same record follows through receiving and invoice matching. That means the budget owner sees a commitment when it is approved rather than when the invoice arrives, and accounts payable checks an invoice against something instead of against memory.
If you want to see how that maps to your current approval limits, book a demo and we will walk through it with your own thresholds and departments.
