Purchase requisition vs purchase order: what is the difference?

What is the difference between a purchase requisition and a purchase order?

The difference between a purchase requisition and a purchase order is who it is for and what it commits. The requisition is an internal request to buy, approved by managers and budget holders; it binds no one outside. The purchase order is sent to a supplier and, once accepted, commits the organisation to pay.

In one line each: a purchase requisition is the request an employee raises to ask for something to be bought, with an estimated cost and the budget to charge. A purchase order is the numbered document the buyer sends to one supplier, with the quantity, price, delivery date and terms. Each has its own guide; this page is about the difference.

A simple case. A marketing manager needs 20 laptops for new staff. She raises a requisition: model, quantity, estimated price, cost centre, reason. Her director approves it, and finance confirms the budget. Nothing has been ordered yet, and the supplier knows nothing. Purchasing then checks the IT contract, confirms the price and sends a purchase order to the contracted reseller. From that moment the supplier has an order it can accept, deliver and invoice.

Purchase requisition vs purchase order: side-by-side comparison

The two documents describe the same purchase at two moments. The table compares them point by point.

Is a requisition the same as a purchase order?

No. A requisition is not the same as a purchase order, even when both are created in the same system and look alike on screen. Microsoft’s training for Dynamics 365 puts it plainly: requisitions are internal documents, while purchase orders are the external documents that purchasing sends to vendors. SAP’s training describes the requisition as an internal request to purchasing to procure a material or a service.

The confusion has a few sources. Small organisations often skip the requisition and let a manager approve the purchase order itself. Some teams say “purchase order requisition” or “PO request” for a requisition, because its aim is to obtain a PO. And in some systems a requisition can lead to something other than a purchase order: in Dynamics 365, a requisition raised to replenish stock can result in a purchase order, a transfer order between warehouses or a production order.

There is also a scope difference that matters in groups with several companies. In Dynamics 365, a requisition can be raised for any legal entity of the organisation, while a purchase order always belongs to one company. A requester in a shared service centre can ask for equipment for two subsidiaries on one requisition; each subsidiary then receives its own order.

What does each document commit, legally and in the budget?

A requisition commits the organisation internally at most: it can reserve budget, but the supplier has no claim on it. A purchase order is an offer to the supplier. Under US commercial law (UCC § 2-206), for example, an order for goods for prompt shipment invites acceptance by a prompt promise to ship or by shipping. Once accepted, the order and its terms bind both sides.

Budget control follows the same two steps in systems that use encumbrance accounting, common in the public sector and universities. The principle is general; the names and the exact moment each reservation is booked depend on the system. Microsoft’s archived documentation for Dynamics AX 2012 describes one version: a pre-encumbrance is a request to reserve funds for planned spending, recorded on the requisition; when the purchase order is confirmed, an encumbrance is created and the pre-encumbrance is relieved automatically, so the same money is not counted twice. Its example: a 12,000 requisition for office furniture becomes a 12,000 encumbrance on the purchase order.

The US federal terms come from the Government Accountability Office’s glossary of the budget process and apply to US federal agencies only. State and local governments, and public bodies in other countries, have their own rules and terms. Check the rules that apply to your own organisation.

How does a requisition become a purchase order?

An approved requisition becomes a purchase order when a buyer, or the system, confirms the supplier and the price and creates the order. The requisition then closes. When the item, supplier and price are already set, for example a catalogue item under a contract, the system can create the order with no buyer action. How the conversion works in practice is described in what is a purchase requisition.

The link between the two is not always one to one. Three patterns are common.

One requisition, one order

The simplest case: one need, one supplier. The order carries the requisition’s lines and approval.

Several requisitions, one order

Purchasing groups approved requisitions for the same supplier into one order, often called consolidation. Five departments each ask for printer paper; the supplier receives one order with five delivery lines.

One requisition, several orders

A requisition with lines for different suppliers is split. A new starter’s requisition for a laptop, a desk and a phone contract becomes three orders to three suppliers.

A worked example. A project team raises one requisition with three lines: 10 monitors at an estimated 180 each (1,800), 10 docking stations at 120 each (1,200) and installation at 600. Total requested: 3,600. The monitors and docks are in the IT reseller’s catalogue at contract prices of 172 and 115, so one order of 2,870 goes to the reseller. Installation is a free-text line; the buyer asks two framework suppliers for a quote and orders from the cheaper at 540. The requisition for 3,600 has become two orders totalling 3,410, both under the approved amount, so no new approval is needed. If a final price had been higher than the approved line, the order would have gone back for approval.

This is why later steps use the PO number, not the requisition number. The supplier quotes the PO number on its delivery note and invoice, and accounts payable matches the invoice against the order and the goods receipt in the three-way match.

When can a purchase order exist without a requisition?

Systems do not always require a requisition: Microsoft’s guidance for Dynamics 365, for example, says requisitions are not mandatory for every organisation and that a purchase order can be created directly. Whether to require one is a policy choice. Common cases where an order has no requisition of its own:

• Releases against an agreement. A blanket or contract agreement sets prices and terms for a period; each call-off, or release, orders a quantity without a new requisition. Oracle Purchasing, for example, distinguishes standard orders, planned orders with scheduled releases and blanket agreements with blanket releases.
• Orders raised by purchasing for stock. A buyer, or a planning run, orders stock items to keep inventory at the right level. In SAP, planning runs often create requisitions that buyers convert, so the requisition is still there, created by the system rather than a person.
• Small purchases on a procurement card. A P-card purchase has neither a requisition nor a purchase order; card limits and monthly checks replace both.
• Organisations that approve the order itself. In a small company, a manager may approve the purchase order directly, so the order plays both roles. This works while one person can see the budget and the need.

One case is not legitimate: the order raised after the invoice has arrived, often called an after-the-fact PO. Someone bought directly from the supplier, the invoice arrived with no order, and an order is created to let it be paid. The requisition and the order then control nothing. Count these orders; a rising share shows that people are buying around the process.

Which mistakes come from mixing up the two documents?

• Calling the supplier once the requisition is approved. The requester treats approval as permission to order directly. The supplier then delivers with no PO number, and the invoice cannot be matched.
• Sending the requisition to the supplier. The supplier receives a document with estimated prices and no terms, and may treat it as an order. Only the purchase order should leave the organisation.
• Changing the order without going back to approval. The buyer increases a quantity on the PO beyond what was approved on the requisition. Set a rule: an order above the approved amount, or above a tolerance, returns for approval.
• Quoting the requisition number on the invoice. Accounts payable cannot find an order with that number and the invoice waits. Tell suppliers which number to quote, and print only the PO number on what they receive.
• Counting the budget twice. A report adds open requisitions and open orders for the same purchase. Relieve the requisition when the order is created.

Most of these mistakes disappear when requisitions and orders live in one system that carries the approval from one to the other. What to look for in such a tool is covered in purchase requisition software and purchase order software. The whole cycle, from need to payment, is described in what is procure-to-pay.