Requisition vs Purchase Order Made Clear

A department needs new laptops. Someone messages a familiar supplier, the supplier ships the equipment, and Finance receives an invoice with no purchase order number. The budget owner says the purchase was necessary. Accounts Payable says the commitment wasn't authorized. Procurement is left reconstructing who asked for the equipment, who approved it, what the supplier agreed to deliver, and whether the invoice reflects the actual order.

That situation isn't caused by a vocabulary mistake alone. It happens when an organization places the wrong control at the wrong point in the buying process. In a practical requisition vs purchase order policy, the requisition controls internal demand and authorization, while the purchase order controls the external supplier commitment. The strongest processes preserve both records and connect them to receipt and invoice evidence.

Table of Contents

• Why the Two Documents Are Often Confused

  • The operational confusion

• Understanding the Core Purposes

  • The requisition is the internal ask

  • The PO is the external promise

• Comparing Requisitions and Purchase Orders

  • Requisition vs Purchase Order Key Differences

• Following the Requisition-to-Payment Workflow

  • Evidence at each handoff

• Applying Both Documents in Real Scenarios

  • Emergency buying

  • One need, multiple POs

• Handling Exceptions and Document Conflicts

• Strengthening Controls and Auditability

  • What an auditor should be able to reconstruct

• Choosing the Right Procurement Policy

Why the Two Documents Are Often Confused

The laptop example becomes harder to resolve when different teams use “ordered” to mean different things. The requester may say they placed the order after submitting an internal request. Procurement may mean that a buyer issued a purchase order. The supplier may treat an email, portal submission, or signed quote as the buyer's commitment. Finance sees only the invoice and the missing evidence behind it.

The documents often contain overlapping information, including descriptions, quantities, delivery requirements, cost centers, and supplier details. The same ERP menu may place requisitions and purchase orders beside each other, and supplier paperwork can arrive before internal approvals are complete. Those similarities make the records look interchangeable even though they govern different decisions.

The operational confusion

A requisition asks whether the organization should spend. It gives a department a way to describe a need, identify funding, and obtain authorization before a supplier-facing obligation exists. Oracle's procurement guidance describes the requisition as “your request for the good or service,” while an order is “formal authorization to purchase the good or service.” The purchase order is created only if the requisition is approved, as documented in Oracle's procurement guidance.

A purchase order answers a different question: what exactly has the organization authorized the supplier to provide, under which commercial terms? It communicates the accepted quantity, price, delivery requirements, and payment conditions. A requisition can be rejected or revised without creating a supplier obligation. A PO can create an external commitment once the relevant acceptance mechanics and terms are in place.

Practical rule: “Requested” and “ordered” should never be treated as synonyms in an approval, audit, or invoice conversation.

The control failure appears when a team skips the requisition but assumes the PO will repair the gap. It won't. A PO can document what was sent to the supplier, but it can't recreate the original budget decision, business justification, or approval trail with the same evidentiary value. Conversely, an approved requisition doesn't prove what the supplier ultimately accepted if the PO changed the price, quantity, or delivery terms.

Understanding the Core Purposes

A purchase requisition is an internal request for goods or services. Its audience is the people who decide whether the organization should proceed, including the requester, budget owner, Finance, Compliance, and Procurement. The requisition should make the need understandable enough for those reviewers to test business purpose, budget coding, supplier policy, and any required sourcing route.

The requisition is therefore a control document before spending occurs. In Microsoft Dynamics 365 workflows, a requisition moves through formal states such as Draft and Approved, with PO generation following approval, as described in Microsoft's purchase requisitions workflow. That sequence lets the organization challenge an incomplete specification, unsuitable supplier, unsupported price, or incorrect cost allocation before a vendor-facing commitment is created.

The requisition is the internal ask

A useful requisition normally records:

• Business need: What the team requires and why.

• Specification: The functional or technical requirements that define an acceptable result.

• Estimated commercial exposure: The expected cost and relevant budget coding.

• Ownership: The requester, department, cost center, and accountable budget holder.

• Approval evidence: Decisions, comments, timestamps, and any required exception rationale.

The exact fields depend on the organization's policy, but the principle is stable. The requisition exists to establish controlled intent.

The PO is the external promise

A purchase order is the supplier-facing commitment. It translates approved demand into commercial instructions covering what the supplier should provide, at what price, in what quantity, to which location, and under which delivery and payment terms. It becomes especially important for receiving, supplier disputes, invoice review, and contract administration.

The PO doesn't replace the requisition. It completes a different handoff in the procure-to-pay sequence. The requisition speaks primarily to internal authority. The PO speaks to the supplier and creates the reference point for downstream fulfillment.

Some organizations permit requisition-only routes for low-risk, routine, or catalog purchases. That doesn't mean the control disappears. It means the organization has decided that a lighter approval and commitment path is proportionate to the risk. The policy should define what qualifies, who can use the route, and what evidence remains mandatory.

Comparing Requisitions and Purchase Orders

The distinction becomes clearer when the records are compared by control purpose rather than appearance.

Requisition vs Purchase Order Key Differences

The requisition proves the internal decision. It shows who identified the need, how the request was coded, and who authorized it. The PO proves the commercial instruction. It shows what the organization told the supplier to deliver and the terms attached to that instruction.

That distinction matters when one approved requisition becomes multiple POs. The requisition can preserve the single internal authorization, while each PO records the separate supplier commitment. Enterprise workflows commonly track requisitions and POs independently, and Oracle and PeopleSoft documentation recognizes that procurement statistics can be generated for requisitions, purchase orders, and receipts, reflecting separate control points in the process.

The risk of a missing requisition is highest when the organization needs to prove that demand was authorized before commitment. The risk of a missing PO is highest when Finance must determine what the supplier was instructed to provide. Teams working with competitive tenders can also use procurement manager tender tools to keep sourcing evidence aligned with the eventual commercial record. For automation boundaries, purchase order automation guidance can help teams separate repeatable processing from decisions that still need human review.

Following the Requisition-to-Payment Workflow

A controlled purchase should leave a verifiable trail from the first business need through payment. The requester defines the outcome, prepares the requisition, applies the correct budget and accounting codes, and submits it for review. Each step places a control before the organization takes the next financial or commercial action.

The budget owner confirms funding and business need. Procurement or an authorized buyer checks the purchasing route, supplier, specification, and proposed terms before issuing the PO. Approval controls internal demand, while the PO creates the supplier-facing instruction. If those records conflict, the organization needs a defined rule for which approved document governs and who resolves the discrepancy.

Evidence at each handoff

A supplier acknowledgment or order confirmation connects the PO with fulfillment. Receiving staff record the goods delivered or service accepted. Accounts Payable then compares the PO, receipt, and invoice through a three-way match before releasing payment.

A usable audit file should let someone reconstruct the transaction without relying on informal explanations:

1. Need identification: The business purpose and expected outcome.

2. Requisition drafting: The specification, estimate, coding, and requester.

3. Budget check: Funding validation and any required policy review.

4. Requisition approval: The decision, approver, timestamp, and conditions.

5. PO issuance: The supplier-facing terms and authorized quantities.

6. Goods or service receipt: What the organization received.

7. Three-way match: How the invoice was tested against the PO and receipt.

Cycle time and processing cost also show where control design affects operations. APQC benchmark data cited in procurement automation research places the fully loaded cost per requisition at $11 to $16 for best-in-class organizations, $24 to $32 at the median, and $45 to $60 in the bottom quartile (benchmarking context). The figures support examining approval routing, rework, and manual data entry rather than removing evidence from the process.

Organizations seeking to streamline purchase order approvals can automate routing, reminders, and data transfer while retaining approval history and change logs. Teams can also review where procure-to-pay processes break down to test whether missing evidence, receiving delays, or invoice exceptions are weakening downstream payment control.

Applying Both Documents in Real Scenarios

A planned office equipment purchase should normally begin with a detailed requisition. The department describes the required capabilities, quantity, delivery location, and business justification. The budget owner approves the need, Procurement validates the route and supplier terms, and the buyer issues the PO. The PO, not the requisition, carries the commercial instruction sent to the equipment supplier.

A low-risk catalog purchase can follow a lighter route if policy allows it. For example, an employee might choose an approved item from a controlled catalog, with the system applying the relevant cost center and approval route. The organization may treat the approved requisition as sufficient internal authorization for that category, but it still needs a transaction record, supplier identity, receipt evidence, and invoice controls. “Low risk” should describe the policy category, not become a reason to approve any informal purchase.

Emergency buying

An urgent field repair tests whether the policy is designed for real operations. If waiting for the normal sequence would create a safety, service, or operational risk, an authorized emergency buyer may engage the supplier first. The business should then record the reason for the emergency, the person who authorized the exception, the supplier terms, the amount committed, and the subsequent review.

The compensating control is not a retroactive form created without explanation. It's a time-stamped exception record that makes clear what happened, why the normal route couldn't be used, and whether the purchase should be approved, challenged, or escalated.

One need, multiple POs

A single approved requisition can support several POs when demand is split across suppliers, locations, delivery schedules, or categories. The requisition should retain the overall business rationale and budget reservation. Each PO should separately identify the supplier, quantities, prices, delivery obligations, and acceptance evidence.

A split order is controlled when it reflects a documented buying decision. It is risky when it hides a purchase that would otherwise require different approval or sourcing treatment.

The policy should let the scenario determine the document set. It shouldn't force every low-risk catalog release, emergency repair, and complex multi-supplier award into an identical workflow, but every exception needs a visible owner and an evidence trail.

Handling Exceptions and Document Conflicts

The standard sequence is valuable because it separates authorization from commitment. Exceptions aren't automatically wrong, but they move risk into a different control point and require stronger evidence.

The difficult question is often whether the PO, contract, invoice, or supplier terms control when records disagree. The answer depends on the acceptance mechanics and the exact terms incorporated into the transaction, not on calling one document “legally binding.” A contract may govern the relationship while the PO provides release-specific details. An invoice usually requests payment, but it shouldn't rewrite accepted price, quantity, delivery, or payment terms.

Three-way matching failures need a decision, not an automatic override. A receiver should confirm whether the shipment was partial or defective. Procurement should determine whether a price change was approved. Finance should retain the reason for releasing, reducing, or rejecting the invoice.

Early warning signals include repeated after-the-fact requisitions, frequent emergency codes, split orders involving the same supplier, invoices without PO references, and manual match overrides. These signals point to control placement problems that policy owners should investigate before they become routine.

Strengthening Controls and Auditability

Good procurement governance turns document separation into evidence that people can test. The requisition should capture the origin of demand, business justification, cost center, GL coding, supplier rationale, contract reference where relevant, and the approval record. The PO should preserve the supplier identity, ordered quantities, agreed prices, delivery requirements, payment conditions, version history, and supplier communication.

Approval design matters as much as document design. A requester shouldn't be able to approve their own demand, receive the goods, and release the invoice without independent checks. The organization should separate the roles of requester, budget approver, buyer, receiver, and Accounts Payable where the risk justifies it. Thresholds, categories, locations, and emergency routes should determine which approvals are required.

What an auditor should be able to reconstruct

An auditor shouldn't need to interview five people to understand a purchase. The system should show:

• Demand origin: Who requested the purchase and what need was recorded.

• Authorization: Which budget owner approved it, when, and under what conditions.

• Commitment: Which PO was issued and what terms the supplier received.

• Performance: What goods or services were received and accepted.

• Settlement: How the invoice was matched, adjusted, or approved for payment.

Oracle and PeopleSoft procurement documentation treats requisition, PO, and receipt activity as separately reportable records. That separation supports audit testing because reviewers can examine whether each control operated at its intended stage rather than treating the final invoice as the only source of truth.

Track leading indicators that reveal friction or leakage. Requisition-to-PO cycle time shows whether internal approval is slowing legitimate demand. Unmatched invoices expose weak PO, receipt, or supplier data. Policy exceptions reveal where the workflow doesn't fit operations. Retrospective requisitions indicate that internal authorization is arriving after the commitment.

Choosing the Right Procurement Policy

A practical policy should standardize the points where risk changes. Require pre-approval before supplier commitment for spend categories and thresholds that need budget, sourcing, compliance, or contract review. Require a PO before a supplier starts work or ships goods unless the transaction falls within a documented exception. Keep supplier master data, contract references, coding, and approval ownership centralized enough that teams can't create conflicting records in local spreadsheets or email chains.

Permit controlled exceptions, but define them narrowly. Petty cash, approved catalogs, and emergency purchases may use lighter routes when the organization records the reason, authority, supplier, receipt, and subsequent review. A requisition-only workflow can work for low-risk spend when the policy identifies the category, spending boundary, approved supplier conditions, and evidence needed for invoice settlement. The boundary should be based on risk, not convenience.

Monitor behavior rather than relying only on policy statements. Review split orders that appear to divide one need across several transactions. Investigate repeated after-the-fact requests. Analyze unmatched invoices and manual overrides by department, requester, supplier, and category. Procurement teams can use a procurement policy template and control checklist to organize these requirements before configuring workflows.

Non-negotiable: Don't bypass approval authority, alter PO terms after supplier acceptance without a formal amendment, or settle a transaction when the document sequence can't be reconstructed.

For complex sourcing, an evidence-focused platform such as Procright can support specification development, supplier comparisons, source citations, structured scoring, and drift detection across quotes, manuals, and terms. Those capabilities help preserve the decision record that sits upstream of the requisition and PO, especially when Finance and Compliance need to understand why a supplier or commercial option was selected.

The right policy doesn't force every purchase through the same number of screens. It places the strongest control before the highest-risk commitment, keeps exceptions visible, and preserves enough evidence to connect the request, approval, PO, receipt, and invoice.

Procright helps procurement teams build evidence-backed specifications, compare suppliers, flag requirement and commercial drift, and export an audit-ready decision record that supports stronger requisition and PO controls. Visit Procright to test how a structured sourcing workflow can improve traceability before your next complex purchase.