Key Takeaways
- A purchase requisition is an internal request to buy something; a purchase order is the external, legally binding document sent to the supplier once that request is approved.
- The requisition comes first and is about permission and budget; the purchase order comes second and is about commitment and terms.
- A requisition stays inside your organisation and creates no obligation to a supplier. A PO leaves your organisation and forms a contract once the supplier accepts it.
- You generally need both in any controlled procurement process — skipping the requisition invites maverick spend; skipping the PO invites disputes and weak audit trails.
The Short Answer
The difference between a purchase requisition and a purchase order is who they're for and what they commit you to. A purchase requisition is a request raised by an employee asking the organisation for permission to buy goods or services; it circulates internally for budget and approval. A purchase order (PO) is the document issued to the supplier after that approval, specifying exactly what is being bought, at what price, and on what terms — and it becomes legally binding once the supplier accepts it.
In sequence: someone raises a requisition, it gets approved, and the approved requisition is converted into a purchase order that goes out to the supplier. Both documents are stages in the wider procure-to-pay process, and confusing them is one of the most common sources of control gaps we see in procurement workflows. The distinction is simple once you anchor on it: the requisition asks “may we buy this?” and the purchase order says “we are buying this, here are the terms.”
What a Purchase Requisition Is
A purchase requisition is an internal authorisation request. Its job is to answer two questions before any money is committed: is this purchase justified, and is there budget for it? A typical requisition captures the item or service, quantity, estimated cost, the budget or cost centre it should be charged to, the requester, and a justification.
Crucially, a requisition creates no obligation to any supplier. It is a conversation inside your own organisation. That's what makes it a control point: it's the moment to redirect a buyer toward a preferred supplier, an existing contract, or a catalogue item before any commitment exists. Get requisitioning right and you prevent problems rather than chase them later. For the formal request itself, many teams standardise on a reusable form — the same logic behind keeping a consistent purchase order template applies to requisitions.
Requisitions also create useful demand signal. Because they capture intended purchases before they happen, a healthy requisition flow gives procurement an early view of what the business is about to buy — which categories are heating up, which suppliers are being requested, and where demand could be aggregated for a better deal. That forward visibility is impossible if buying starts at the purchase order, by which point the commitment is already made.
What a Purchase Order Is
A purchase order is the external, formal commitment. Once a requisition is approved, procurement converts it into a PO and sends it to the chosen supplier. The PO specifies the agreed items, quantities, unit prices, delivery dates, payment terms, and a unique PO number that will be referenced on the delivery note and the invoice. When the supplier accepts the PO — explicitly or by fulfilling it — it generally forms a binding contract.
The PO number is the thread that ties the whole transaction together. It links the order to the goods receipt and the invoice, which is exactly what enables the three-way match that protects accounts payable from overpayment and fraud. If you want to understand how that downstream check works, our analysis of AI-assisted three-way matching shows why a clean PO is the foundation of accurate invoice processing. For a fuller treatment of the document itself, see our explainer on what a purchase order is.
One nuance worth flagging: a purchase order is an offer until the supplier accepts it. Acceptance can be explicit (a signed confirmation) or implied (the supplier begins fulfilling the order). Until then, it is not yet a contract. This is why supplier confirmation is a distinct step in well-run processes — it converts your documented intent into a mutual, enforceable agreement, and it surfaces any price or availability discrepancy while it is still cheap to resolve.
Purchase Requisition vs Purchase Order: Key Differences
The table below lays out the practical distinctions side by side.
| Dimension | Purchase Requisition | Purchase Order |
|---|---|---|
| Direction | Internal request | External document sent to supplier |
| Purpose | Seek approval and confirm budget | Commit to buy on defined terms |
| Timing | First — before any commitment | Second — after approval |
| Legal status | No supplier obligation | Binding once supplier accepts |
| Audience | Internal approvers, finance | The supplier |
| Created by | Requester / budget owner | Procurement / purchasing |
| Key contents | Need, quantity, estimated cost, budget code, justification | Agreed items, prices, terms, delivery, PO number |
| Control role | Prevents unjustified or off-budget spend | Enables three-way match and audit trail |
How They Connect in the Workflow
Requisition and PO aren't competing documents — they're consecutive stages. The flow runs: need → requisition raised → approval → PO created → PO sent to supplier → goods received → invoice matched against the PO → payment. The requisition is the gate; the PO is the commitment that passes through it.
This sequencing is what gives procurement its control. Because approval happens at the requisition stage, no purchase order — and therefore no binding commitment — can be created without sign-off. And because the PO carries a unique number into the receipt and invoice, the transaction stays traceable end to end. Skipping either step breaks the chain: no requisition means spend escapes approval; no PO means the invoice has nothing reliable to match against. Both failures show up later as exceptions, disputes, or audit findings, and both feed the maverick-spend problem that erodes your spend under management.
When to Use Each
In a mature procurement function, almost every non-trivial purchase should pass through both stages. That said, the practical question is usually about thresholds and exceptions.
Always use a requisition when a purchase needs budget approval, when it's above a low-value threshold, or when policy requires a paper trail for justification. The requisition is cheap insurance against unbudgeted and off-contract buying.
Always use a purchase order when you need a binding commitment, when the supplier requires one to fulfil, or when you want the transaction to be matchable for clean AP processing — which is almost always. POs are what make spend auditable.
Reasonable exceptions exist for very low-value or emergency purchases handled through a corporate card or petty cash, and for certain recurring or utility payments governed by a standing contract rather than a per-transaction PO. The key is to define these exceptions explicitly in policy, not to let them emerge by accident. Teams that lean on guided buying and catalogues, like those profiled in our source-to-pay AI market analysis, can automate the routing so the right document is created without the requester having to think about it.
Common Mistakes and Misconceptions
Treating them as interchangeable. They are not. A requisition is permission to buy; a PO is the act of buying. Using the terms loosely leads to processes where commitments get made before anyone approved the spend.
Issuing POs without requisitions. When procurement cuts POs straight from emails, the approval gate disappears and spend control evaporates. The requisition step exists precisely to prevent this.
Paying invoices with no PO. Non-PO invoices are the hardest to match and the easiest route for duplicate payments and fraud. Maximising PO coverage is one of the highest-leverage controls in accounts payable.
Letting requisitions stall. If approvals are slow, requesters route around the process, which reintroduces maverick spend. Right-sized, value-based approval thresholds keep the gate effective without making it a bottleneck.
A practical rule of thumb: set a PO threshold low enough that the vast majority of spend by value flows through a purchase order, and reserve card or non-PO channels for the long tail of tiny, low-risk purchases. The goal is high PO coverage — the share of total spend made against a PO — because that single metric correlates strongly with how controlled and auditable your procurement actually is. If a large share of spend is escaping the PO process, that is usually a sign the requisition step is too slow or the catalogue too thin, not that POs are unnecessary.
Types of Purchase Orders (and Requisitions)
Both documents come in more than one flavour, and matching the right type to the purchase reduces administrative overhead. On the requisition side the distinction is mostly about routing: a standard requisition for one-off needs, a catalogue requisition drawn from pre-approved items that often auto-approves, and a service requisition for scoped work that needs a statement of work attached. On the PO side, the type you choose changes how the commitment behaves over time.
| PO type | What it is | Best for |
|---|---|---|
| Standard PO | One-time order for defined items, quantities, and prices | Most discrete, one-off purchases |
| Blanket PO | Agreement to buy up to a value or quantity over a period, drawn down via releases | Recurring buys from one supplier at agreed rates |
| Contract PO | PO tied to a master contract governing terms | Strategic suppliers with negotiated agreements |
| Planned PO | Long-term order with tentative delivery dates released later | Forecast-driven, scheduled materials |
Choosing well matters: using standard POs for high-frequency reordering buries procurement in paperwork, while a blanket PO consolidates that into a single managed agreement. For strategic suppliers, a contract PO keeps the transactional order anchored to the negotiated terms captured in your contract management template, so price and terms can't quietly drift.
Why the Distinction Matters for Control
It's tempting to treat the requisition-versus-PO question as administrative trivia, but the separation is one of the foundational controls in procurement. The requisition enforces authorisation — nothing gets committed without the right person agreeing to spend the budget. The PO enforces accountability — every commitment is documented, numbered, and matchable. Together they create the segregation that auditors look for: the person who requests a purchase is not the same person who commits the organisation to it, and both actions are recorded.
That separation is also what makes spend data trustworthy. When requisitions carry budget codes and POs carry agreed prices, finance can see committed spend before invoices arrive, and procurement can analyse what's being bought to inform category management and future sourcing. Lose the discipline and you lose the data — which is why the requisition-to-PO chain is worth protecting even when automation makes it nearly invisible to the end user.
Where Automation Changes the Picture
Modern procurement platforms blur the manual boundary between these documents without removing the control logic. Guided buying lets a requester pick a catalogue item, automatically generates a compliant requisition, routes it for the right approvals based on value and category, and converts the approved requisition into a purchase order — all without re-keying. The human decisions (justify, approve) stay; the clerical work disappears.
That automation only works on clean foundations: accurate catalogues, current supplier records, and sensible approval rules. Tools in the purchase order automation category and broader invoice and AP automation tools can take requisition-to-PO-to-invoice from a multi-day manual chain to a near-instant flow, but they amplify whatever process discipline you already have. If you're standardising the upstream documents first, pairing a reusable requisition form with a consistent contract management template gives the automation reliable reference data to act on.
Automate requisition-to-PO workflows
Compare the platforms that turn approved requisitions into purchase orders automatically and keep every transaction matchable.