Purchase Requisition vs Purchase Order: The Difference That Controls Spend

The One-Line Answer, Up Front

If you only take one thing: the requisition is the request, the purchase order is the order. A requisition is you asking your own business for permission to spend. A purchase order is your business telling a supplier to deliver. One is a conversation that stays indoors; the other is a commitment that goes out the door and creates a liability.

Everything else follows from that. Because the requisition is internal, it’s where approval belongs — you can still say no, nothing has been promised. Because the purchase order is external, saying no after it’s issued means cancelling on a supplier already told to proceed. That’s why the approval lives on the requisition, not the PO: the requisition is the last moment the decision is cheap.

What a Purchase Requisition Is

A purchase requisition is a formal internal request to buy something. Someone in the business needs an item or a service, so they raise a request stating what it is, how much, why, and which budget it comes out of — and it routes to someone with the authority to approve that spend. No supplier is involved. No money is committed. It exists entirely so the decision to spend is made on the record, by the right person, before an order goes anywhere.

Its whole reason for being is sequence. With no requisition step, the first time anyone with budget responsibility hears about a purchase is when the invoice lands — goods already ordered, delivered, often used. The requisition drags that decision to the front, so the business approves spend rather than merely paying for it after the fact. A finance lead we spoke to put the shift plainly: before requisitions, the team were bookkeepers reacting to whatever arrived; after, they were the ones deciding what got bought.

What a Purchase Order Is

A purchase order is the document your business sends to a supplier that says: deliver these items, in these quantities, at this price, to this address, on these terms. Once the supplier accepts it, it’s a binding commitment — a contract, in effect. That’s the key difference in weight. The requisition is a request that can be declined; the PO is an instruction that, once out, obliges you to pay for what you’ve asked for.

Because it’s the commitment, the PO carries the details that make the transaction checkable later: the agreed price, the delivery terms, a PO number the supplier quotes on their invoice. That number is what lets you match the bill back to the order when it arrives. A requisition can’t play that role, because it never went to the supplier and isn’t what they’re billing against. The PO is the anchor the whole downstream check hangs off.

The Sequence, and Why Order Matters

The correct flow is short: someone raises a requisition, it gets approved, and the approved requisition becomes a purchase order that goes to the supplier. Request, approve, commit. Each step depends on the one before it — you can’t approve what wasn’t requested, and you shouldn’t commit what wasn’t approved. The requisition front-loads the decision so the PO is a formality: by the time it’s issued, the hard question of should we spend this is already answered.

Get the order wrong and the control collapses. If the PO goes out first and the requisition is reconstructed afterwards — or never raised at all — the approval that was supposed to gate the spend is now happening after the commitment. That’s not approval, it’s rubber-stamping a decision someone already made. The requisition-first sequence is the entire mechanism; reverse it and you’ve kept the paperwork but thrown away the point.

Who Sees Each One

The cleanest way to keep the two straight is to ask who’s meant to read it. The requisition is internal — the requester, their manager, the approver, finance. It can carry things you’d never show a supplier: which cost centre it hits, the justification, whether there’s budget left. It’s a working document for deciding, and it stays in the family.

The purchase order is supplier-facing. It’s written for the vendor and contains only what they need to fulfil and invoice: items, quantities, agreed price, delivery details, terms, the PO number. The internal reasoning that lived on the requisition doesn’t travel onto the PO — the supplier has no business seeing your budget lines. If you ever find internal budget notes on a document a supplier holds, the seam between the two has broken.

What Each One Actually Controls

The requisition and the PO control different risks, and that’s why serious businesses run both. The requisition controls budget and authority — the internal questions. Is there money for this? Is the person approving it allowed to approve spend of this size? Authority limits live here: a team lead to £1,000, a department head to £10,000, a director above that, with anything over a limit escalating automatically. The requisition is the checkpoint that stops someone committing spend above their level.

The purchase order controls the supplier commitment — the external questions. What exactly did we agree to buy, at what price, on what terms, and what will we accept an invoice against? So the two are complementary, not redundant: the requisition governs whether the spend should happen and who said so; the PO governs what was agreed with the outside party and holds the line when the invoice arrives. Drop the requisition and you lose budget and authority control. Drop the PO and you lose your grip on what the supplier can bill you for.

The Conversion Seam: Approved Requisition → PO

Here’s where the whole thing is won or lost. An approved requisition should convert into a purchase order in one step — the items, quantities, supplier and budget line are already captured and already signed off, so raising the PO is a conversion, not a fresh entry. The PO that reaches the supplier is, by construction, one that passed approval, because it was born from an approved requisition rather than typed up from scratch. No re-keying, no drift between what was approved and what got ordered.

That join is what most businesses miss, and it’s where unapproved orders slip through. When the requisition is an email and the PO is a spreadsheet — or the two live in separate systems that don’t talk — someone re-keys the order by hand. Every re-key is a chance for the quantity to grow, the price to change, or a line nobody approved to appear on the PO. Worse, when the seam is missing entirely, people skip the requisition and go straight to the PO because it’s faster. Good purchase order software closes that gap by making the approved requisition the only way a PO gets created — so what was approved is what gets ordered, full stop.

Do You Always Need Both?

Honestly, no — and pretending otherwise is how you end up bolting five sign-offs onto a box of pens. A very small business raising the occasional PO, where the owner is also the approver and sees every order anyway, doesn’t need a formal requisition step. The requisition exists to move a spend decision to someone who wouldn’t otherwise see it before the money’s committed. If the person raising the order and the person who’d approve it are the same, a separate requisition is just friction with no control gained.

The distinction starts to matter the moment those two roles split — when someone can commit spend that someone else is accountable for the budget on. That’s usually a second location, a team lead who orders their own consumables, or a budget owner who no longer sees every purchase land. At that point the PO on its own stops being a control: it commits money without anyone testing whether there was budget or authority behind it. Below that threshold, a clean PO process is plenty. Above it, running POs without requisitions means committing spend nobody approved.

Common Mistakes That Blur the Two

The most common one is treating the PO as the approval. Businesses raise a purchase order, route that for sign-off, and call it controlled — but by the time a PO exists, the intent to buy is already formed and often communicated to the supplier. Approving the PO is approving the commitment after it’s shaped, not the request before it. The approval belongs on the requisition, where saying no is still free.

A second mistake is the reverse: raising a requisition, approving it, then re-keying it into a PO in a disconnected system — so the “approved” version and the “ordered” version drift apart and aren’t the same thing. A third is skipping the requisition whenever it feels slow, which is really a symptom of a requisition process too heavy for the size of the spend. The fix for all three is the same shape: keep the request and the order as two stages of one flow, put the approval on the requisition, and make the approved requisition convert straight into the PO. A well-run requisition process isn’t two systems bolted together — it’s one path from request to committed order, with the approval baked into the middle.

FAQ

What is the difference between a purchase requisition and a purchase order?

A purchase requisition is internal and asks permission — can we buy this? — while a purchase order is external and instructs a supplier — send us this. The requisition comes first: it captures the request and gets it approved against budget and authority. Only after approval does it become a purchase order that’s sent to the supplier and creates a commitment. In short, the requisition is the request and its sign-off; the PO is the commitment to a third party. Skipping the requisition means the approval that should precede the order never happens.

Which comes first, the requisition or the purchase order?

The requisition comes first, always. Someone raises a requisition, it’s approved against budget and authority, and the approved requisition then converts into a purchase order that goes to the supplier. The PO is what an approved requisition becomes — not a separate document raised in parallel. The order matters because the approval is supposed to gate the spend: if the PO goes out first, the commitment has already been made before anyone decided whether it should be. Reversing the sequence keeps the paperwork but loses the control.

Does a small business need both a requisition and a purchase order?

Not necessarily. A very small business where the owner raises and approves every order themselves doesn’t gain anything from a separate requisition step — the person requesting and the person approving are the same, so a clean PO process is enough. The requisition earns its place the moment those roles split: when someone can commit spend against a budget that someone else is accountable for. At that point a PO on its own commits money without testing budget or authority, and the requisition is what puts that check back in front of the commitment.

Can a purchase order be raised without a requisition?

Technically yes, and in a one-person operation that’s fine. But in a business where spend needs approving, raising a PO without a requisition means the order is committed to a supplier without anyone having tested it against budget or authority first — that’s how maverick spend gets in. The safer pattern is that a PO can only be created from an approved requisition, so every order that reaches a supplier passed approval by construction. If POs can be raised freely with no requisition behind them, the approval step is optional — which in practice means it gets skipped.

How OpsMavix Can Help

Most businesses don’t get this wrong because they don’t understand the difference — they get it wrong because their tools force the two documents apart. The requisition lives in an email or a shared sheet, the PO in an accounts package that can’t see the budget the requisition was checked against, and someone re-keys between them. That gap is where orders go out unapproved and where the numbers quietly drift. OpsMavix builds right-sized systems for businesses stuck in that gap — too messy for spreadsheets, not ready for a full ERP — where request and order are two stages of one flow rather than two disconnected documents.

We build the requisition, the approval routing and authority limits, and the one-step conversion into a purchase order as a single path, keyed to how you actually buy — heavy scrutiny where the money is, invisible where it isn’t, and no re-keying anywhere. From there the same discipline carries through to invoice approval workflow automation and matching, so spend is controlled from the first request to the final payment. If you want the machinery behind it, our purchase requisition software breakdown goes deeper. If purchase orders are reaching suppliers before anyone with budget authority has seen them, we’ll show you where and what it’s costing. Book a Free Operations Leak Audit