Purchase Requisition vs Purchase Order: The Difference That Actually Matters

These two documents get used interchangeably in conversation, and the confusion is expensive. They do opposite jobs. One asks a question inside your company. The other makes a promise outside it.

The purchase requisition

A requisition is an employee saying: I need this, here is why, here is roughly what it costs, and here is the budget it should come from. It circulates internally. It commits the company to nothing. It can be rejected, reduced, deferred, or redirected to an existing contract without a supplier ever knowing it existed.

That last point is the whole value of the step. The requisition is the last moment where spend costs nothing to stop.

The purchase order

A purchase order is issued after approval and sent to the supplier. It states quantities, prices, delivery dates, and terms. Once the supplier accepts it, it is generally a binding contract. Cancelling now means a conversation, possibly a fee, and sometimes a relationship cost.

What breaks when you skip the requisition

Plenty of small companies raise purchase orders directly. It feels faster. What it actually does is move the approval to after the commitment, which means approval becomes a formality. Nobody rejects a PO the supplier has already shipped against.

The symptoms show up a quarter later: budget overruns discovered at invoice time, duplicate orders for the same item, and a finance team doing forensic work instead of forecasting. Measured over a year, this is the largest single contributor to a maverick spend rate.

A workable sequence

1. 1Requester raises a requisition with need, quantity, estimated cost, and cost centre.
2. 2Approval routes by amount and category to the right budget owner.
3. 3Procurement checks whether an existing contract or preferred supplier applies.
4. 4An approved requisition converts to one or more purchase orders.
5. 5POs go to suppliers; receipts and invoices are matched back against them.

Two documents, two jobs. Keep them separate and the rest of the process behaves.

Start with the operating case, not the feature list

Context matters in requisition and purchase-order design because the visible transaction is only the final record of several earlier decisions. Consider this operating case: A marketing manager accepts a $38,000 agency proposal by email, then asks finance to raise a PO so the invoice can be paid. The PO looks compliant, but it records a decision that can no longer be changed. The useful question is not whether a form was completed. It is whether the evidence available at that moment was sufficient for a named owner to make a reversible, explainable decision. That distinction keeps the process practical: control is attached to consequence, not paperwork.

Trace one ordinary case and one awkward case from the first request to the final accounting entry. Record who knew what, which system held it, and what happened when the expected path failed. This exposes handoffs that a workshop diagram misses: the spreadsheet used to repair supplier names, the inbox where an approver asks for context, or the monthly reconciliation that makes reports believable after the fact.

Evidence to assemble before changing the process

Do not begin configuration with a blank workflow canvas. Build a small evidence pack first. It should be compact enough for the working team to challenge line by line, and representative enough that a successful pilot means something. The minimum useful pack contains the following inputs.

• The business need, quantity, expected value, category, and required date
• The budget and cost centre that will absorb the commitment
• Quotes, scope, security review, or legal terms required by policy
• Supplier identity, delivery address, commercial terms, and tax treatment

The decisions the workflow must make explicit

A dependable requisition and purchase-order design process does not ask everyone to approve everything. It identifies a small set of decisions, assigns each to the person with the authority and information to make it, and records enough context to explain the result later. If two reviewers are checking the same fact, remove one. If nobody can state what would cause rejection, the step is probably ceremonial.

• Whether the need should be approved, reduced, deferred, or rejected
• Whether an existing contract or inventory item already satisfies it
• Whether competitive sourcing is proportionate to value and risk
• When an approved requisition becomes an external commitment

Write these decisions as testable statements. For example: approve when the budget is available and the need is valid; route to security only when company data enters the service; reject when the supplier identity cannot be verified. Testable rules make demos, implementation workshops, and post-launch audits materially more useful than labels such as finance review or procurement check.

A practical implementation sequence

Sequence matters because teams otherwise automate the cleanest diagram and discover the real exceptions after launch. Keep the first release narrow, but do not make it artificially easy. Include enough volume to observe behaviour and at least one category with meaningful exceptions. A sensible sequence is:

1. 1Capture the need before a supplier is promised work
2. 2Route approval using estimated total commitment, not the first invoice
3. 3Convert approved data rather than retyping it into a PO
4. 4Track amendments against the original approval and preserve the audit trail

At each step, preserve a manual recovery path and name the person allowed to use it. Recovery is not failure; invisible recovery is. An exception handled in a private message teaches the system nothing. An exception recorded with a reason can inform the next policy or configuration change.

Failure modes worth testing before launch

Happy-path acceptance testing proves very little. Build tests from the cases that cause delay, uncontrolled commitment, duplicate work, or misleading reporting. The following failures are common enough to deserve an explicit owner and expected response before rollout.

• Backdating requisitions after an invoice arrives
• Using a PO number as evidence that approval happened first
• Splitting an annual commitment into monthly requests below threshold
• Letting buyers alter price or scope after approval without rerouting

Run these as tabletop exercises with the requester, approver, finance operator, and system administrator in the same room. If the answer depends on somebody remembering an unwritten convention, document it or redesign the path. If the answer requires administrator intervention for an ordinary exception, calculate that support load before declaring the workflow scalable.

Measure the control without gaming it

A metric needs a stable denominator, a reproducible source, and an owner who can change the result. Publish the definition beside the number. Show medians with a tail percentile where time is involved, and split rates by material populations rather than averaging unlike work together.

• Requisitions created before supplier commitment
• POs generated directly from approved requests
• PO amendments by reason and value
• Invoices with no valid PO at first receipt

Review the underlying records monthly during rollout, then quarterly once behaviour stabilises. A rising exception rate can mean the process is deteriorating, but it can also mean the system has started recording exceptions that were previously invisible. Interpret the movement before rewarding or correcting anyone.

Limits and cases that need a different tool

No requisition and purchase-order design design is universal. State exclusions before estimating benefits. That protects the business case from inflated addressable volume and tells operators where a different control, specialist system, or human judgement remains necessary.

• Low-value emergency purchases may need a documented exception path
• Blanket orders need release controls rather than one approval forever
• A requisition is not a substitute for a contract where terms matter
• A PO cannot repair a weak specification or an unverified supplier

Keep a decision record that survives the project

For each material choice, record the date, owner, evidence considered, option selected, rejected alternatives, and the condition that would trigger review. This is not meeting minutes. It is a compact explanation of why the company accepted a particular cost or risk. Six months later, a new operator should be able to distinguish an intentional compromise from an accidental omission without locating the original project team.

Use the record during monthly operations reviews. Compare the assumptions made at approval with actual volume, cycle time, exceptions, and supplier behaviour. When an assumption fails, change the rule or reopen the decision; do not quietly build manual work around it. That feedback loop is what turns a configured workflow into an operating system rather than a frozen implementation project.

The final design should be easier to explain than the process it replaces. If a requester cannot predict what information will be required and who will decide, complexity has merely moved behind the screen. Keep the common path short, make consequential exceptions visible, and revisit the rules when transaction patterns or organisational ownership change.