# What Is a Purchase Requisition? (vs Purchase Order) > A purchase requisition is an internal request to buy, approved before it becomes a PO. See what it contains, the approval workflow, and requisition vs PO vs RFQ. A purchase requisition is an internal request to buy goods or services, raised by an employee or department and approved before any order goes out. It is intent, not a commitment. Once approved, it becomes a purchase order, the external document sent to the supplier. Requisition comes first, then approval, then the PO. **A purchase requisition is the internal form an employee raises to ask permission to buy something, and it must clear approval before procurement turns it into a purchase order sent to a supplier.** The requisition is the control point. It is where spend gets authorized, budgets get checked, and the wrong purchase gets stopped before it reaches a vendor. Skip it and you get maverick spend, surprise invoices, and no audit trail for who approved what. The confusion most people have is between the requisition and the purchase order. They look similar and carry similar line items, but they do different jobs, and mixing them up is how unapproved spend reaches suppliers. This guide covers what a requisition contains, how it differs from a PO and an RFQ, how the approval workflow runs, and how automation kills the email-and-spreadsheet version of this process. ## What a Purchase Requisition Contains **A purchase requisition captures who wants what, why, and against which budget, so an approver has everything needed to say yes or no.** It is a structured request, not a free-text email. A complete requisition includes: - **Requester and department.** Who is asking and which cost center absorbs the spend. - **Item or service description.** What is being bought, with quantity and unit of measure. - **Estimated price.** A budgetary figure, often from a catalog or a prior quote. - **Suggested supplier.** A preferred vendor, if the requester has one in mind. - **Need-by date.** When the goods or service are required. - **Business justification.** Why the purchase is necessary, which matters most for non-catalog or high-value requests. - **Account and budget code.** The general ledger line the spend hits. The requisition does not obligate the company to anything. No supplier sees it. It exists so the right people inside your organization can approve or reject the spend before it becomes real. ## What a Purchase Requisition Looks Like **A requisition form is a short, structured document, and every field exists to give the approver enough context to decide without a follow-up email.** Here is the standard layout with a filled-in example, a maintenance department requesting fall-protection gear: | Field | Example | |---|---| | Requisition number | REQ-2026-0341 | | Requester | D. Alvarez, Maintenance | | Department / cost center | Maintenance, CC-410 | | Date needed | 2026-08-15 | | Item description | Full-body safety harness, ANSI Z359.11 compliant | | Quantity | 12 | | Estimated unit cost | $145.00 | | Estimated total | $1,740.00 | | GL / budget code | 6220 (Safety equipment) | | Suggested supplier | Northline Safety Supply | | Business justification | Annual harness replacement per fall-protection inspection cycle | | Approver | Plant manager (threshold: under $5,000) | Copy this structure into whatever tool you use, a form, a ticket template, or an ERP screen. The two fields people skip most often, the GL code and the justification, are the two that slow approval down the most, because the approver has to chase them before deciding. ## Purchase Requisition vs Purchase Order vs RFQ These three documents sit next to each other in the [procure-to-pay process](/blog/procure-to-pay-process), and they are easy to mix up. Here is the clean distinction. | Document | Direction | Purpose | Binding? | |---|---|---|---| | **Purchase requisition** | Internal | Request and authorize a purchase | No, intent only | | **Request for quote (RFQ)** | Outbound to suppliers | Ask suppliers for pricing and terms | No, an inquiry | | **Purchase order** | Outbound to one supplier | Commit to buy at agreed terms | Yes, a contract | The sequence runs requisition, then optionally RFQ, then purchase order. A requisition is raised and approved internally. If the item needs competitive pricing, buyers send an RFQ to gather quotes. Once a supplier and price are set, procurement issues the [EDI 850 purchase order](/guides/edi/850-purchase-order), the binding document that commits the company to the buy. If you trade EDI, you can validate any outbound PO file against the spec with our [free EDI Inspector](/edi-inspector) before it goes out the door. The key line to remember: **a requisition is internal intent; a purchase order is an external commitment.** The moment of approval is where one becomes the other. ## The Approval Workflow **Requisition approval routes the request through the people authorized to release that level of spend, usually along dollar thresholds and department lines.** This is where financial control actually happens. A well-designed workflow matches approval authority to spend size. A typical multi-level routing looks like this: 1. **Requester submits.** The employee completes the requisition and submits it. 2. **Manager review.** The requester's line manager confirms the need and the budget. 3. **Threshold routing.** Low-value requests may need only one approval. A request over a set limit, say $5,000, routes to a department head. Over a higher limit, it reaches finance or a director. 4. **Procurement release.** Once approved, procurement converts the requisition to a purchase order and issues it to the supplier. Thresholds and multi-level routing are standard across every major ERP. In SAP, a requisition is created in transaction ME51N, and the document type carries the requisition through release strategies before it becomes a PO ([SAP purchase requisition help](https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE)). JD Edwards handles requisitions through purchase order type "OR," a requisition order that flows into the standard PO process ([Oracle JD Edwards procurement documentation](https://docs.oracle.com/en/applications/jd-edwards/)). Microsoft Dynamics 365 provides a dedicated purchase requisition workflow with configurable approval steps ([Microsoft Learn purchase requisitions](https://learn.microsoft.com/en-us/dynamics365/supply-chain/procurement/purchase-requisitions-overview)). The mechanics differ, but the principle is identical everywhere: no requisition becomes a PO until the right person has approved it. ## How Automation Fixes the Requisition **Automated requisitioning replaces the inbox with defined rules, so requests route themselves and approved requisitions convert straight to purchase orders without retyping.** The email-and-spreadsheet version fails in predictable ways: requests sit unread for days, nobody can trace who approved what when a surprise invoice lands, and the approved request for 50 units at $10 drifts into a PO for 60 somewhere in the retyping. Automation removes each of those failure points. The requester picks items from a catalog or fills a structured form, the system checks the budget, applies the threshold rules, and pushes the request to the correct approver. Once approved, the requisition flows into the PO with no rekeying, which removes the drift that breaks downstream matching. The audit trail is automatic: every PO ties back to an approved requisition and a named approver. For the buying side to run cleanly, the outbound POs also need to reach suppliers without manual handoffs. That is where [purchase order automation](/blog/purchase-order-automation) takes over, issuing the 850 electronically and capturing the supplier's acknowledgment. Connect requisition, PO, and receipt in one flow through [ERP integration](/erp-integration) and the whole cycle stops leaking time and money. ## Frequently Asked Questions ### What is the difference between a purchase requisition and a purchase order? A purchase requisition is the internal request that authorizes spend before anything is ordered; a purchase order is the external, binding document the supplier actually receives. In most ERPs the two carry separate document numbers, and the PO record references the requisition number behind it. That reference is the thread auditors follow to confirm every order traces back to a named approval. ### Who raises a purchase requisition? Any employee or department that needs to buy goods or services can raise one. It typically starts with the person closest to the need, then routes to a manager and, depending on the dollar amount, to a department head or finance for approval before procurement issues the actual purchase order. ### Is a purchase requisition legally binding? No. A requisition is an internal document that authorizes a purchase within your organization. It does not create any obligation to a supplier. Only the purchase order, sent to and accepted by the supplier, is legally binding. ### What is the difference between a requisition and an RFQ? A purchase requisition is an internal request to authorize a purchase. A request for quote (RFQ) goes outbound to one or more suppliers asking for pricing and terms. The requisition comes first and stays inside the company. The RFQ is a sourcing step that can follow it when the item needs competitive pricing. ### Can a requisition be changed after it is approved? Usually only by going back through approval. A change to the amount, quantity, or supplier invalidates the original sign-off, so most policies route the edited requisition through the approval chain again, or at minimum to the approver whose threshold the new amount crosses. Minor edits, like a corrected ship-to address or an adjusted delivery date, are typically allowed without re-approval, but the policy should say so explicitly.