Purchase Requisition vs Purchase Order: Why Both Documents Matter for Financial Control
Most procurement processes start with a PO. Someone needs something, they raise a purchase order, get it approved, and send it to the supplier.
The missing step: the purchase requisition. It's the internal document that says "we need this" before the PO says "we're buying this." It's not just a formality — it's a different control at a different stage of the process.
Understanding both, and why they're distinct, clarifies the whole procurement document flow.
What a Purchase Requisition Is
A purchase requisition (also called a purchase request or PR) is an internal document raised by a person or department who needs goods or services. It's a request for permission to buy — it doesn't commit to any purchase until it's approved.
What a purchase requisition contains:
- Who is requesting
- What department
- What's needed (product description, specification)
- How many / what quantity
- Why it's needed (business justification)
- When it's needed by
- Estimated cost
- Suggested supplier (optional)
The requisition goes to whoever has authority to approve that purchase. When approved, it becomes the authorization for procurement to raise an actual purchase order.
What a Purchase Order Is
A purchase order is the external document sent to a supplier. It's a formal, often legally binding commitment to buy. It specifies: what, how many, at what price, delivered where, by when.
The key difference from a requisition: a PO is sent outside the business. A requisition stays inside.
Why the Distinction Matters
The requisition controls "should we buy this?" The PO controls "are we committed to buying this?"
These are two separate questions with two separate control points.
Without a requisition step, the first control happens at PO approval — which means someone has already invested time specifying exactly what to buy from which supplier at what price before getting authorization. If the PO is rejected, that work was wasted.
Worse: if PO approval is rubber-stamped because the work is already done and the need seems real, the practical control has shifted much earlier — to whoever decided to start the process. And whoever that is, they may not have the financial authority they effectively assumed.
The requisition catches this earlier:
- Is this purchase actually needed?
- Does it fit within budget?
- Is this the right time to buy?
- Is the proposed approach (supplier, specification) sensible?
These questions are easier (and cheaper) to ask before the PO is drafted than after.
The Full Procurement Document Flow
For a controlled procurement process:
1. Purchase Requisition — Department raises internal request 2. Requisition Approval — Relevant manager authorizes the purchase 3. Supplier Selection — Procurement identifies the best supplier (may involve quotes if above a threshold) 4. Purchase Order — Procurement creates and sends PO to supplier 5. PO Approval — Finance or senior management approves the financial commitment (especially for high-value orders) 6. Acknowledgment — Supplier confirms receipt and acceptance of PO 7. Delivery — Goods arrive 8. Goods Received Note — Warehouse confirms what was received 9. Supplier Invoice — Supplier bills for the delivery 10. Three-Way Match — PO + GRN + Invoice are reconciled 11. Payment Approval — Finance authorizes payment 12. Payment — Funds transferred
Not every purchase needs every step. A standard consumable reorder below a threshold might skip requisition and go straight to PO. But for any significant or non-routine purchase, the full chain provides genuine financial control at each stage.
This is what financial controls look like in practice — not a policy document, but a document flow that makes unauthorized spending structurally difficult.
When to Require a Requisition
Not everything needs a formal requisition. The overhead isn't worth it for genuinely routine purchases.
Require a requisition for:
- Non-routine purchases (anything not covered by a standing purchase order or pre-approved supplier arrangement)
- Capital expenditure
- New supplier purchases
- Purchases above a defined threshold
- Anything outside the current budget
Skip the requisition for:
- Routine replenishment orders against pre-approved reorder points
- Small purchases below a threshold where the cost of process exceeds the control value
The threshold for what "requires" a requisition should be documented in your procurement policy.
The Budget Connection
A purchase requisition is where budget impact should be assessed. Before approval, the approver should see:
- What budget line does this fall under?
- How much of that budget is remaining?
- Does this purchase fit within the available budget?
When requisitions are managed in a system connected to your budget tracking, this check happens automatically — the approver sees the budget position at the point of approval, not after the purchase is made.
This is one of the areas where approval workflows in a system significantly outperform email-based approvals — the system can surface budget context that email cannot.
The Three-Way Match Starts Here
The audit trail for three-way matching starts with the requisition. A well-implemented matching process links:
Requisition → PO → GRN → Invoice → Payment
Each stage references the previous document. This creates a complete, traceable chain from "we decided to buy" to "we paid." Without the requisition as the first document in the chain, you're starting the trail later than ideal.
For any audit or financial review, being able to show the full document chain — including the original business justification — is significantly stronger than showing only the PO and invoice.
Sevenledger's procurement module manages the full document chain from requisition through payment — with approval workflows at each stage, budget visibility at point of decision, and automatic three-way matching for every supplier invoice.