The two terms get used interchangeably, and most of the time everyone still understands each other. But a purchase requisition and a purchase order are different documents, aimed at different audiences, created at different moments — and the difference is exactly where purchasing control lives.
A purchase requisition is an internal request for permission to buy: an employee describes what they need, and it routes to whoever has to approve it. A purchase order is an external commitment: the numbered document a company sends to a vendor after approval, which the vendor fulfills and invoices against. The requisition asks; the purchase order commits.
The two documents, side by side
| Purchase requisition | Purchase order | |
|---|---|---|
| Audience | Internal — approvers, finance, department leads | External — the vendor |
| Purpose | Ask for permission to buy something | Commit the company to buying it |
| Created by | The person who needs the thing | Purchasing or finance, after approval |
| Legal weight | None — it’s an internal form | A binding offer; accepted, it forms a contract |
| Number | Optional internal reference | Always numbered — vendors and auditors track by it |
| What happens next | Approved, rejected, or sent back with questions | Fulfilled by the vendor, then matched against delivery and invoice |
What belongs in a requisition
A requisition is only as useful as the decision it lets an approver make. If the approver has to reply asking what it’s for or what it costs, the form failed. A good requisition carries:
- Line items with quantities and estimated prices — not “some equipment, ~$2k”
- A suggested supplier, if the requester has one
- The department or project the cost belongs to
- A sentence of justification — what breaks or stalls without it
- Attachments where they help: quotes, spec sheets, screenshots
The routing matters as much as the form. Who approves should depend on the amount, the category, and the department — a $150 office-supply order shouldn’t travel the same path as a $15,000 equipment purchase. This is the part email and chat can’t do: they collect opinions, but nothing enforces that the right people said yes before money moves. (It’s also the part SpendCue formalizes as purchase requests — same document as a requisition, plainer name.)
What belongs in a purchase order
The purchase order is the requisition’s output, translated for an external reader. The vendor doesn’t care who approved it — they care what to deliver, where, and how they’ll get paid:
- A unique PO number — the reference everything downstream hangs on
- Exact items, quantities, and agreed prices
- Delivery address and expected date
- Payment terms
- Who to contact with questions
Because an accepted PO forms a contract, it’s also the document that protects both sides: the vendor knows the order is real and authorized, and the buyer has something concrete to check the delivery and the invoice against. That check — order vs receipt vs invoice — is what 3-way matching means, and it only works if the PO exists as a real, numbered document rather than a promise in an email thread.
Where teams get this wrong
Three patterns show up over and over in teams that run purchasing over email:
- The requisition is skipped. Someone buys first and asks forgiveness later. The approval, if it happens at all, happens after the money is committed — which is to say it isn’t an approval, it’s a notification.
- The approval is informal. A thumbs-up in a chat thread approves a number that later turns out to have been a different number. Nobody can reconstruct who agreed to what.
- The PO never exists. The vendor works from an email, the invoice arrives weeks later, and there’s nothing to match it against. Finance pays it because refusing takes more work than paying.
None of these are character flaws — they’re what happens when the process lives in tools that weren’t built for it. The fix isn’t more discipline; it’s making the compliant path the easy path.
How the flow works when it works
- Someone needs something and submits a requisition with real line items.
- It routes to the right approvers based on amount, category, and department.
- On approval, the requisition becomes a numbered purchase order — in SpendCue this happens automatically, and the vendor-ready PDF is emailed in one click.
- The vendor delivers; receiving is logged against the PO.
- The invoice arrives and is matched against the order and the receipt before payment.
Every step leaves a record, and nothing is ordered without an approved request behind it. That’s the entire point of the two-document system — not paperwork for its own sake, but approval placed before commitment instead of after.
Do small teams even need requisitions?
If one person does all the buying, no — a requisition to yourself is theater. The moment more than one person can spend company money, the requisition step is just the approval step written down, and the question becomes whether you want it enforced by a system or remembered by a person. Teams usually formalize it after a specific incident: a surprise invoice, a duplicate order, a budget discovered blown mid-quarter.
You don’t need an ERP for any of this — the whole request-to-PO loop runs fine as standalone purchase order software. What matters is that the two documents exist and that the first one is approved before the second one goes out.