A purchase requisition is an internal request to buy something. A purchase order is an external commitment to buy it. The two documents look similar, contain many of the same fields, and are routinely confused, but the difference between them is where the entire control model of procurement sits.
Put simply: a requisition asks, a purchase order promises. One is a conversation inside the organisation. The other is a legal instrument sent outside it.
The purchase requisition
A requisition originates with whoever has the need. A chef needs a replacement mixer, a facilities manager needs filters, a project lead needs licences. They raise a requisition stating what is needed, how much, when, and against which cost centre or budget.
At this point nothing has been committed. No supplier has been told anything. The organisation has an internal record that someone wants to spend money, and that record is about to be tested against policy.
The testing is the point. The requisition is what passes through approval: the budget holder confirms the money exists, the category manager confirms the item and supplier are appropriate, and any spend-threshold rules apply. If the request fails at this stage, it fails cheaply, because nothing external has happened.
A requisition typically carries the requester, the cost centre or general-ledger coding, the item description or catalogue reference, quantity, unit of measure, required delivery date, the suggested supplier, and an estimated price.
Two of those fields deserve attention. The suggested supplier is a suggestion. A requisition may be routed to a different supplier by the buyer, consolidated with other requisitions, or converted into a sourcing event if the value is high enough. And the estimated price is an estimate, unless the line came from a catalogue, in which case it is the contract price and is not an estimate at all. That distinction is why catalogue coverage matters so much, as covered in what is a procurement catalog.
The purchase order
Once a requisition is approved and a supplier is settled, it becomes a purchase order. The PO is sent to the supplier and, in most jurisdictions and under most terms, constitutes a binding offer. When the supplier accepts it, whether by acknowledgement or by performance, there is a contract.
The PO carries much of the same data as the requisition, plus the things the supplier needs and the requester did not have to know: the legal entity placing the order, agreed payment terms, delivery address and incoterms, tax treatment, the contract reference the pricing derives from, and a purchase order number.
That number is the important part. It is the key that connects everything afterwards. The goods receipt references it. The supplier’s invoice references it. The three-way match reconciles against it. Reporting aggregates by it. An organisation that lets purchases happen without PO numbers has, in practice, given up the ability to reconcile anything automatically, which is why “no PO, no pay” is such a common policy.
The lifecycle in order
The full sequence, with the state change at each step:
- Need identified. Nothing recorded yet.
- Requisition raised. Internal record exists. No commitment.
- Approval. Policy applied. Still no commitment.
- Sourcing, if required. For values above threshold or items without a contract.
- Purchase order issued. Commitment created. Supplier notified.
- Order confirmation. Supplier accepts, rejects, or proposes changes to quantity, price, or date.
- Goods receipt. Delivery confirmed against the PO.
- Invoice received. Supplier bills against the PO.
- Matching. Invoice reconciled against PO and receipt. See what is three-way matching.
- Payment.
The financial consequence of step five is worth stating plainly. Issuing a PO creates a commitment, and in properly configured systems it encumbers the budget immediately, before any invoice arrives. That is what lets a budget holder see what they have actually spent rather than what has so far been billed. Organisations that skip the PO step lose commitment visibility entirely and discover overspend at month end.
Variants worth knowing
Blanket purchase orders, sometimes called standing orders or framework orders, cover repeated purchases against agreed terms over a period. Rather than a PO per delivery, there is one PO with a total value or quantity, released against over time. Common for consumables and recurring services. They reduce administrative volume substantially, at the cost of weaker per-transaction control.
Contract releases work similarly, drawing down against a negotiated agreement.
PO flip is the practice of letting a supplier generate their invoice directly from the purchase order they received, rather than producing one independently. Because the invoice inherits the PO’s line items, quantities, and prices, it matches by construction, and the exception rate collapses. It is one of the highest-return interventions available in accounts payable, and it depends entirely on the PO having been transmitted to the supplier as a structured document in the first place.
Where the distinction breaks down in practice
Three patterns account for most of the damage.
Retrospective POs. Someone buys first and the PO is raised afterwards to satisfy accounts payable. The document exists, so the reporting looks clean, but the approval it represents happened after the money was committed. The control is theatre.
Free-text requisitions. The requisition carries a typed description rather than a catalogue item, so the price, part number, and unit of measure are all guesses. The resulting PO inherits those guesses, and the invoice will not match. This is the single largest source of accounts payable exceptions in most estates.
Requisition and PO treated as one step. Systems configured to auto-convert every approved requisition into a PO without a buyer’s involvement remove the consolidation and supplier-selection opportunity entirely. For low-value catalogue items that is correct and efficient. For everything else it forfeits leverage.
The common thread is that the quality of the PO is bounded by the quality of the requisition, and the quality of the requisition is bounded by whether the requester had accurate content to choose from. Which is why the leverage in this process sits further upstream than most improvement programmes look: in catalogue coverage and supplier connectivity rather than in approval workflow.
That upstream layer is what BoreaTech builds. SupplierForge focuses on getting accurate supplier content in front of the person raising the requisition, so the fields that flow into the PO, the receipt, and the invoice are right at the point they are first entered rather than corrected three documents later.