A supervisor approves the material request, and the requester assumes the supplier is working on it. Purchasing has not issued an order yet. The useful distinction in purchase requisition vs purchase order is the job each document does: a requisition records an internal request and its approval; a purchase order communicates the purchase to a supplier.
Use a requisition when your process requires someone to approve the need before purchasing acts. Use a purchase order to record the supplier, quantities, agreed details, and delivery requirements for the order. Keep an existing purchasing system if it already handles those steps well. A missing status link may call for a clearer report rather than a replacement system.
The request and the order answer different questions
The requester needs to know whether the business has approved the purchase. The buyer needs to know whether an order has been prepared and sent. Receiving needs to know which supplier order a delivery belongs to. Combining these questions into one field called approved leaves people guessing about what happened next.
| Decision | Purchase requisition | Purchase order |
|---|---|---|
| What does it record? | An internal need for goods or services | The goods or services being ordered from a supplier |
| Who acts on it? | Requester, reviewers, and purchasing under company policy | Buyer and supplier, with receiving using the order reference |
| What should approval tell you? | The request passed the required internal review | Check the order’s own approval and transmission status |
| What needs a separate check? | Whether approved lines have been converted into orders | Whether the supplier received the order and confirmed delivery |
| How are they related? | One request can lead to several orders | Each order should retain its source request references where applicable |
SAP’s Ariba purchase-order lesson describes a requisition as an approvable request and a purchase order as a separate supplier document. Its example creates multiple orders from a requisition with multiple suppliers. The precise approval and routing behavior depends on configuration; those examples are not universal rules for every purchasing system.
Kartik Deshpande prepared this article from official documentation checked October 26, 2026. The workflow and quantities below are a proposed example, not a tested implementation or customer result. The focus is operational tracking, not a legal conclusion about when a purchase becomes binding.
The requester supplies enough detail to approve the need
Capture the item or service description, quantity, unit of measure, needed-by date, destination, and business reason. Include the requester and the team or project using it. Where the price is an estimate, label it as an estimate and retain the quote or assumption behind it. A reviewer should not have to infer whether a quantity means individual units or cases.
Give the request and each line stable identifiers. An email subject or product description is a weak match because it can change or appear on several requests. If purchasing consolidates similar needs, the original requester should still be able to see which portion of an order covers their request.
The reviewer approves within the company’s purchasing policy
Microsoft’s Dynamics 365 requisition workflow documentation supports review of a whole document or individual lines. It also describes configuring review steps and automatic approval. Decide which expenditures need review, who has authority, and who substitutes for an absent reviewer before configuring the workflow.
Record the version and amount that the reviewer approved. If the quantity, destination, or price changes afterward, apply your policy for further review. Do not copy an old approval onto a materially different request just because the request number stayed the same. A status history should explain the change and identify the person responsible for the next action.
When requests arrive from job sites, include the project and delivery location in that review. The construction purchase-order software comparison covers the separate choice of purchasing tools for field and office teams.
The buyer turns approved demand into supplier orders
After approval, the buyer selects the supplier and confirms order details under the company’s process. Keep an approved-but-unordered queue with the request line, unallocated quantity, buyer, and next action. This gives purchasing a place to explain a missing quote or unavailable material without marking the request as ordered prematurely.
For a hypothetical example, a maintenance team requests 100 identical replacement parts. The buyer orders 60 from supplier A and 40 from supplier B. Preserve both order-line references against the original request. The allocation check is 60 plus 40 equals 100 requested units. The original request is demand; adding its 100 units to the two orders would incorrectly report 200 units to buy.
Oracle’s Procurement 26D split-line documentation describes splitting a requisition line when more than one supplier must fulfill it. In another system, verify how its native line references work before building a similar view. A copied description alone does not prove that an order fulfills a particular request.
Check that the supplier received the order
Creating an order is not evidence of successful delivery to the supplier. SAP’s Ariba lesson describes both electronic routing and manual processing, depending on the supplier and setup. Store the transmission status and any failure alongside the order. Have the buyer resolve a failed send before telling the requester the material is on its way.
A supplier acknowledgment and a shipment are also different events. Record the confirmed quantity and date, then let receiving record what arrives. In the example, if supplier A delivers 50 of its 60 units, that leaves ten on A’s order and 40 on B’s order. The purchase-order tracking process covers partial receipts and unresolved supply obligations in more detail.
Where Permute fits between request and order records
Permute sells connected business data and custom applications. For a team whose requests and supplier orders live in different sources, a scoped project could bring permitted records together and preserve the original request, line, and order identifiers. Confirm the available source access before choosing the workflow.
Agree how request lines match order lines and what counts as approved, allocated, sent, and received. Those definitions let an application distinguish an approved request waiting for a buyer from an order waiting for a supplier. Conflicting quantities or missing references should stay visible for review rather than being joined by guesswork.
A requester could then inspect the permitted status of their own request, while the buyer sees the order references and unresolved allocation behind it. Include the source record and last refresh so someone can check the answer before contacting the supplier. Keep access aligned with the information each role is allowed to see.
Explore one request-to-order handoff
Start with permitted request and order records whose relationship your team needs to explain.
Keep purchasing authority and source updates explicit
Permute does not decide who may commit the company to a purchase or choose professional accounting treatments. A reporting application does not itself approve a requisition, send an order, or cancel a supplier commitment. Any external action requires a supported implementation, explicit authorization, and the appropriate permissions.
Test open requests before replacing a tracker
Use the split-order example as an acceptance test in a sandbox or permitted test environment. Import the request, both order references, and the partial receipt. Check that the request remains 100 units, allocation remains 100, and the outstanding receipt quantity is 50. Repeat the import and verify that the same source IDs do not create duplicate demand.
Include an approved request with no order, a failed transmission, and a changed request requiring review. Preserve the old approval evidence and reconnect any source feeds before retiring the spreadsheet. The ERP migration checklist addresses the broader transfer of master data, history, and integrations.
A requisition explains what the business wants and whether it has been approved. A purchase order records the supplier purchase that follows. Keep their line references connected, and track transmission and receipt separately. That gives each person a status they can act on without confusing approval with material already on order.
Review a purchasing status gap
Bring one approved request and the order records that should explain what happened next.
Questions about requests and supplier orders
Does every purchase need a requisition?
Follow your company’s purchasing policy and system configuration. Some spending may use an approved catalog, purchasing card, or another process. Do not add a separate approval step without deciding who owns it and what decision it controls.
Should the requester send the requisition to the supplier?
Use the document and communication channel your purchasing process authorizes. An internal request can contain estimates or approval details that are not the final order. Ask the buyer which supplier-facing document records the intended purchase.
What if the requester changes the quantity after ordering?
Keep the earlier approval and order history, and route the change through the required review. The buyer must resolve any supplier commitment through the supported change process. Editing an internal request does not prove the supplier received a cancellation or revised order.
Can a dashboard show one status for the whole request?
It can provide a summary if readers can inspect the underlying lines. A split request may have one supplier delivering while another has not acknowledged the order. Show unresolved work rather than letting one completed line make the entire request appear finished.