Purchase Requisition vs Purchase Order: What Changes?

A purchase requisition is an internal request for approval to spend. A purchase order is the supplier-facing order created after that request is approved. The requisition records the need, budget, estimated cost, and authorization; the PO confirms what the organization is committing to buy and on what terms.

That is the central distinction in purchase requisition vs purchase order: the PR asks, “May we buy this?” The PO tells a supplier, “We are ordering this.” A requisition normally remains inside the organization. The purchase order leaves the organization and can become binding when the supplier accepts it or performs against it, subject to the order’s terms and applicable law.

The documents also sit on opposite sides of an important control boundary. A requisition captures the request before commitment, when a budget owner can still approve, reject, or change it. The PO records the authorized commercial instruction after details such as supplier, price, quantity, and delivery terms have been settled.

For that reason, comparing two static field lists misses much of the point. The useful questions are which data carries from the PR into the PO, which estimates become firm order terms, and which internal evidence stays behind. A requester’s business justification, for instance, may never appear on the supplier’s PO even though it remains essential to the approval record.

A separate requisition step is most valuable when several people can request purchases, budgets are delegated, approval thresholds vary, or the organization needs clear evidence that authorization preceded supplier commitment. It is not mandatory for every business. A smaller organization may reach the same control outcome through a proportionate PO-only process, provided approval is documented before the order goes out.

What a Purchase Requisition Records

A purchase requisition, often shortened to PR, is the internal record of a proposed purchase. The employee or department that needs goods or services raises it, and the person with the relevant budget or delegated authority reviews it. Because it is a request rather than an order, it is not sent to the supplier.

The fields on a requisition should let an approver answer four practical questions: what is needed, why is it needed, which budget will pay for it, and who has authority to approve it. A typical requisition therefore includes:

• Requester and department: who initiated the request and which part of the organization owns the need.
• Description and quantity: enough detail to understand the goods or services requested.
• Estimated unit and total cost: the expected spend before final commercial terms are confirmed.
• Budget, cost-centre, or project coding: where the expense will be recorded and which budget owner should review it.
• Suggested supplier: a preferred source, where the requester has one, without necessarily determining the final vendor.
• Requested delivery date: when the requester needs the goods or services, rather than a supplier-confirmed commitment.
• Business justification: why the purchase is necessary and what operational purpose it serves.
• Approval trail: who approved, rejected, returned, or amended the request, and when.

Organizations configure these fields around their own risks and accounting structure. A grant-funded project may require a funding code and supporting supplier quotation; a routine low-value office purchase may need little more than a description, estimated value, and budget owner. Not every requisition needs every field.

The distinction between estimated and final information matters. The requisition can identify a likely supplier, expected price, and desired delivery date, but those entries support a decision rather than promise terms to a vendor. Once approval and sourcing are complete, the purchase order records the supplier actually selected, the agreed or quoted price, and the order terms the supplier will receive.

How Requisition Data Changes When the PO Is Created

Approval does not simply rename a requisition as a purchase order. It changes the status and audience of the information: internal estimates and reasons become an authorized commercial instruction, while some control evidence remains internal.

Point of comparison	Purchase requisition	Purchase order
Audience	Requester, budget owner, procurement, and internal approvers	Selected supplier and relevant internal teams
Timing	Before approval and supplier commitment	After the purchase has been authorized
Purpose	Request and justify permission to spend	Place the approved order with the supplier
Monetary values	Estimated or budgetary cost	Agreed, quoted, or otherwise authorized order price
Supplier visibility	Internal; not normally sent to a supplier	Issued to the selected supplier
Approval status	Pending, rejected, returned, or approved	Released after required pre-approval; the PO may also have its own approval or release workflow
Contractual effect	Internal authorization record, not a supplier order	Can become binding through acceptance or performance, subject to its terms and applicable law

Some data carries forward with little change. The description, quantity, project or cost coding, and requested timing may be copied onto the PO or preserved in linked system records. The requisition number may also appear as a reference, allowing procurement, finance, or an auditor to trace the order back to the original request.

Other fields change because approval and sourcing resolve uncertainties. An estimated price becomes the agreed or quoted order price. A suggested supplier becomes the supplier actually selected. A requester’s need-by date becomes an ordered or supplier-confirmed delivery date. The request’s proposed quantity may be adjusted to match budget, stock, packaging, or negotiated terms.

The authorization changes too. Requisition approval permits the purchase within a defined budget and authority level. A separate PO approval or release step can then validate the final commercial terms and control when the order goes to the supplier. The PO should not be treated as evidence that every underlying decision was sound; it is the outward document produced after the relevant internal decision.

Several fields commonly stay behind. The requester’s narrative, internal budget-check detail, alternative supplier suggestions, approval comments, and the full approval history rarely belong on a supplier-facing order. They remain useful because they show why the purchase was initiated and how it was authorized.

System design affects where that lineage is visible. One platform may copy codes and the requisition reference onto the PO. Another may retain the PR and PO as linked records without reproducing internal fields on the order itself. In a manual process, the connection may depend on a shared reference number and a retained approval email. The control test is whether someone can trace the final order back to the request and authorization, not whether every field appears twice.

The Purchase Requisition Process Sets the Control Boundary

The purchase requisition process should make authorization visible before the organization commits to a supplier. The requester records the need and expected cost; the budget owner or other approver checks the coding, available funds, business case, and authority threshold; procurement or another authorized person then converts the approved request into a PO or uses it to create one.

That sequence matters more than the software or form used. An approval added after the order has already been placed may document awareness, but it does not provide the same evidence that someone with authority reviewed the spend before commitment. For the later stages of issuance, receipt, matching, and close-out, see the purchase order process from requisition through close-out.

Three roles are useful when evaluating the control:

• The requester identifies and explains the need.
• The approver or budget owner decides whether the organization should fund it and whether the request falls within policy.
• The PO issuer sends or releases the authorized order to the supplier.

Those roles do not always require three different employees. In a small team, one person may perform more than one role. What still needs to be clear is the limit of that person’s authority, which requests received independent review, and what evidence shows the review occurred before the PO was released. Higher-risk or higher-value purchases can justify additional approval even when routine spend does not.

The control value lies in the record, not in assuming that a PR eliminates misconduct. ACFE's 2024 occupational fraud findings reported that more than half of the occupational fraud cases in its study involved either a lack of internal controls or an override of existing controls. That finding explains why visible authority and review evidence matter; it does not show that requisitions prevent fraud or that every organization needs a separate PR workflow.

Where the Requisition Fits in Invoice Matching

A requisition is upstream authorization evidence, not a standard invoice-matching document. It can show why a purchase began, which budget funded it, and who approved the spend before the PO was issued. It does not prove that the supplier delivered what was ordered or invoiced the correct amount.

In three-way matching, AP compares the purchase order, receipt evidence, and supplier invoice. Standard four-way matching adds inspection or acceptance evidence, not the purchase requisition. The full distinctions among 2-way, 3-way, and 4-way invoice matching depend on which operational events the organization needs to verify before payment.

The requisition can still matter during an exception review. If an invoice has a valid PO but the purchase appears unusual, the linked PR may establish the original business reason and approval. That is an audit-trail use, separate from the price, quantity, receipt, and acceptance comparisons in matching.

After a PO is issued and the supplier bills the organization, the key document relationship shifts again. Readers working at that stage can use how purchase orders and invoices differ to distinguish the buyer’s order from the seller’s request for payment.

When Is a Separate Purchase Requisition Required?

A purchase requisition is required when legislation, funding conditions, contract terms, or the organization’s own policy requires one. Outside those cases, there is no universal rule or monetary threshold that makes a separate PR necessary for every business. The right control depends on who can initiate spend, how budgets are delegated, the risks attached to the purchase, and the administrative cost of another approval step.

A distinct requisition usually earns that cost when one or more of these conditions applies:

• Many employees or departments can request purchases.
• Different budget owners control different cost centres, projects, or grants.
• Approval authority changes at defined spending thresholds.
• Regulated, restricted, or grant-funded spending needs a clear purpose and coding record.
• Off-process buying or unexpected supplier invoices are a recurring risk.
• An audit requires evidence that authorization occurred before supplier commitment.

The threshold design should reflect delegated authority and transaction risk rather than an arbitrary industry figure. An organization might route low-value routine purchases to one budget owner, require another approval for higher amounts, and apply specialist review to sensitive categories regardless of value. The requisition provides the place to capture and route those distinctions before the PO is sent.

A small organization can use a proportionate PO-only workflow when there are few authorized buyers, purchases are straightforward, budget ownership is clear, and pre-approval is retained. That approval might sit in the purchasing system or another controlled record linked to the PO. Merely approving the PO after it has reached the supplier does not satisfy the same purpose.

The document label matters less than the control outcome. If the current process can show who requested the spend, who approved it, which budget it uses, and that approval occurred before supplier commitment, a separate PR may add little. If the process cannot answer those questions, a purchase requisition or equivalent pre-approval record fills a real control gap.