AWRA OpsHub Search

Purchase Requisition vs Purchase Order: The Difference That Protects You

A requisition is an internal request to buy; a purchase order is an external commitment to a supplier. Confusing the two is how organizations end up legally bound to spend money nobody actually approved.

Procurement Insights AWRA OpsHub Team 7 min read

The two documents look similar on paper and are constantly confused in practice, but they do opposite jobs and face opposite directions. A purchase requisition is internal and inward-facing: a member of staff asking their own organization for permission to buy something. A purchase order (PO) is external and outward-facing: the organization telling a supplier, in a binding way, "we commit to buy this, at this price." The requisition asks; the PO commits. Getting the sequence right — request approved before commitment made — is the single most important control in buying.

Illustration of an approval and contract flow
The requisition is the internal ask; the purchase order is the external commitment. Approval belongs between them — never after.

The purchase requisition: the internal ask

A requisition captures who needs what, why, when, and roughly at what cost — and routes it to the person with authority to approve the spend. Nothing has been promised to anyone outside the organization at this stage. It is where budget checks happen, where a manager can question the need, and where the approval threshold decides how far up the chain the request must travel. A good requisition process means no money is committed until someone accountable has said yes.

The purchase order: the external commitment

Once a requisition is approved, it becomes a purchase order sent to the chosen supplier. The PO states exact items, quantities, agreed prices, and delivery terms — and once accepted, it is a contract. This is why the order of operations matters so much: a PO issued before internal approval binds the organization to spend money that was never sanctioned. The PO also becomes the anchor for three-way matching: the goods received and the supplier invoice are both checked against it before payment.

Purchase requisition Purchase order
Direction Internal — staff to organization External — organization to supplier
Purpose Request permission to buy Commit to a purchase
Binding? No — an internal ask Yes — a contract once accepted
Comes first? Yes No — follows an approved requisition
Key content Need, justification, budget, estimate Items, quantities, agreed price, terms
Control it enables Approval before commitment Three-way matching before payment

Why the sequence is the whole point

Skip the requisition and you get the most common procurement failure in small and mid-sized organizations: staff phoning suppliers directly, goods arriving, and finance discovering a commitment that no budget holder ever approved. By the time the invoice lands, the money is already owed. The requisition-then-PO sequence closes that gap — it forces the approval to happen while saying no is still free, before the organization is contractually on the hook.

A healthy buying flow, in order

  • Requisition raised — the need, justification, and estimated cost captured.
  • Approval routed by threshold — bigger spend climbs higher up the chain.
  • PO issued to the supplier only after approval — the commitment.
  • Goods received and checked against the PO — the GRN.
  • Invoice matched to PO and GRN before payment — three-way matching.
Illustration of procurement and vendor management
When requisition, approval, and PO live in one system, commitment can never run ahead of authorization.

On paper or email, the sequence relies on people remembering to follow it — and under deadline pressure they do not. A governed procure-to-pay flow enforces it structurally: a PO simply cannot be issued until the requisition behind it is approved, so the control is built into the process rather than left to discipline. That is the difference between a policy that exists and a policy that actually holds.

Enforce approval before commitment

See requisitions routed by threshold and POs that cannot be issued until the spend is approved — the control built in, not remembered.

Explore procurement

Frequently asked questions

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

A requisition is an internal request for permission to buy something; a purchase order is an external, binding commitment to a supplier. The requisition comes first and is not binding; the PO follows only after the requisition is approved, and once accepted it is a contract.

Do we always need both documents?

For any spend beyond the trivial, yes — the requisition is where approval happens and the PO is where commitment happens, and separating them is what stops staff from binding the organization before anyone authorizes the money. Very small, pre-approved purchases can sometimes skip the formal requisition, but the threshold for that should be a deliberate policy, not an accident.

What goes wrong if you issue a PO without a requisition?

You commit the organization to spend that was never internally approved. Because a PO is binding once accepted, finance often discovers the obligation only when the invoice arrives — too late to say no. The requisition-first sequence exists precisely to prevent that.

How does a system enforce the correct order?

In a governed procure-to-pay system, a purchase order cannot be created until its requisition has been approved through the required threshold. The rule is structural rather than a matter of staff remembering the policy, so commitment can never run ahead of authorization.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center