What is a purchase requisition?
A purchase requisition is an internal request an employee submits to get approval to buy goods or services before any money is committed. It captures what the person wants to buy, why, from whom, and at what cost, then routes to the right approvers, typically a manager, finance, and sometimes IT, security, or legal. Once approved, the requisition becomes the basis for a purchase order, which is the formal commitment sent to the supplier.
A purchase requisition is an internal document, not something a supplier ever sees. It exists so a company can review and approve spend before anyone commits to it. Think of it as the "can I buy this?" step that comes before the "we are buying this" step.
The distinction matters because most spend problems start at this stage. When employees skip the requisition and buy directly, finance finds out about the cost when the invoice arrives. By then the money is spent, the contract is signed, and the chance to negotiate is gone.
How does a purchase requisition work?
The requisition process follows the same basic shape in most companies, whether it runs through a procurement platform or not:
- An employee raises the request. They describe what they need (say, 20 licences of a design tool), the supplier, the estimated cost, and the business justification.
- The request routes for approval. A typical chain includes the budget owner, then finance. Higher-value or higher-risk purchases pull in more reviewers: IT for software, security for anything touching customer data, legal for contract terms.
- Approvers review and respond. They approve, reject, or send it back with questions. This is where finance checks the budget line and procurement checks whether a contract with an existing supplier already covers the need.
- The approved requisition becomes a purchase order. The purchase order (PO) is the external document sent to the supplier, confirming the company's commitment to buy at the agreed price and terms.
Typical breaking points for this process are familiar to anyone who has worked at a scaling company. The requisition "process" is a form buried in a wiki, approvals happen over email, and nobody can answer the Slack message asking "any update on my request from two weeks ago?" So people stop submitting requests and buy first, apologise later. Finance calls this maverick spend, and it typically accounts for a meaningful share of indirect purchasing at companies without a working intake process.
What is the difference between a purchase requisition and a purchase order?
People confuse these two constantly, so here is the clean split:
A requisition asks the question. A purchase order answers it. If a supplier ever asks for your "requisition number," they almost certainly mean your PO number, because the requisition never leaves the building.
Some companies also use the term purchase request interchangeably with purchase requisition. In practice they mean the same thing, though "requisition" tends to appear in more formal or ERP-driven environments.
Why do purchase requisitions matter for finance and procurement teams?
Requisitions are the single point where a company can influence spend before it happens. Every other financial control, from invoice matching to spend analysis, is retrospective. The requisition is the only proactive one. That gives it three specific jobs:
Budget control before commitment. Finance sees the cost against the budget line while there is still a choice to make. Rejecting a requisition costs nothing. Disputing an invoice after the work is done costs relationships, time, and often the money anyway.
Risk review at the right moment. Software purchases need security review. New suppliers need vetting. Contracts need legal eyes. The requisition is the natural trigger for all of these checks, because it fires before signature rather than after.
Duplicate and contract awareness. A good requisition process catches the marketing team about to buy a tool the sales team already licenses, or a new contract with a supplier the company already has terms with. Procurement teams routinely find overlapping subscriptions this way, and consolidating them is one of the fastest savings available.
The honest objection is that requisitions slow people down, and badly run ones do. A requisition that sits in a manager's inbox for ten days teaches the requester to route around the process. The fix is not removing the step but making it fast: clear routing rules, parallel approvals instead of sequential ones, and automatic escalation when a request stalls. This is the problem intake and orchestration platforms like Omnea are built for, replacing the buried form and email chains with a single request flow that routes each purchase to the right approvers automatically and shows the requester exactly where their request sits.
What makes a requisition process actually get used
A requisition process only controls spend if employees use it, and employees only use it if it is easier than going around it. Three things separate processes that work from processes that exist on paper:
- One front door. Employees should raise every request in one place, whether it is new software, a contractor, or a renewal. If people have to guess which form applies, they guess wrong or give up.
- Routing that matches risk. A $200 subscription does not need the same approval chain as a $200,000 contract. Tiered thresholds keep low-risk requests moving in hours rather than weeks.
- Visible status. Requesters who can see where their request sits and who is holding it stop chasing over Slack, and approvers who know they are the bottleneck respond faster.
Get those three right and the requisition stops being paperwork and starts being the point where finance, procurement, and the rest of the business agree on a purchase before it happens, which is considerably cheaper than arguing about it afterwards.