Purchase Requisition vs Purchase Order: The Difference

A purchase requisition is an internal request for permission to buy something; a purchase order is the external, legally binding order sent to the supplier once that permission is granted. The requisition never leaves the company. The purchase order does. One is the ask, the other is the commitment, and the approval step between them is where a company controls its spend.

Last updated July 2026.

Once a requisition becomes a PO and that PO goes out to a supplier, the document usually comes back to you as a PDF acknowledgment or an invoice attachment. Upload one above and every field, from the PO number to the last line item, comes back as structured data in about ten seconds, so nobody is retyping the order you just approved.

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

The purchase requisition is internal and requests approval to spend. The purchase order is external and commits the company to buy. A requisition is raised by whoever needs the item and reviewed by a budget holder. A purchase order is raised by procurement after that review, given a PO number, and sent to the supplier, at which point it becomes a binding offer to purchase on the stated terms.

What is a purchase requisition?

A purchase requisition is a form an employee submits to request that the company buy something. It names the item or service, the quantity, an estimated cost, the cost center or project the spend belongs to, a preferred supplier if there is one, and a short justification. It exists so that the decision to spend is made by someone accountable for the budget, before any money is committed and before a supplier has been told anything.

The requisition is also where policy gets applied. A request for a laptop routes to IT for a standards check. A request over a spend threshold routes to a director. A request for a supplier nobody has vetted routes to procurement for onboarding. None of that is visible on the purchase order that eventually results, which is precisely the point: by the time the PO is issued, the arguments are over.

Is a purchase request the same as a purchase requisition?

In most organizations, yes. Purchase request and purchase requisition describe the same internal document, and the terms are used interchangeably. Where companies do draw a line, purchase request means an informal ask, often an email or a ticket, while purchase requisition means the formal record raised in the procurement system with a cost center and an approval chain attached. Check what your own system calls it before assuming.

What is the purchase request workflow?

The purchase request workflow is the approval path a requisition follows from submission to conversion into a purchase order. Four stages, in order:

1. Intake. The requester completes a structured form: item or service, quantity, estimated unit cost, spend category, cost center or project, preferred supplier, business justification, and needed-by date. A structured form matters more than it sounds, because free-text requests cannot be routed automatically.
2. Validation. The system or a buyer checks the request against budget availability, existing contracts, and the approved supplier list. If a blanket agreement already covers the item, the request should draw against that rather than start a new negotiation.
3. Approval routing. The requisition goes to the approvers the policy demands, based on spend threshold, category, and department. Small purchases might need one manager. A capital item might need the department head, finance, and legal. Tiered thresholds are the norm.
4. Conversion. Once approved, procurement converts the requisition into a purchase order, assigns a PO number, confirms pricing and terms with the supplier, and issues it. The requisition is closed and referenced on the PO for audit.

The stages after that belong to the purchase order, not the requisition: the supplier acknowledges, goods arrive and are receipted, the invoice is matched, and payment goes out. The full sequence is laid out in the purchase order process steps and workflow guide.

Who approves a purchase requisition?

The budget holder for the cost center being charged, at minimum. Above defined spend thresholds, additional approvers join: a department head, then finance, and for certain categories legal, IT security, or facilities. Most US companies set two or three tiers, for example anything under a few thousand dollars needs one manager, larger amounts add finance, and capital expenditure goes to an executive.

The approval matrix is a control, not a formality. It is what auditors test when they ask whether spend was authorized before it was committed, and it is the reason a requisition exists as a separate document from the PO at all.

Does a purchase requisition go to the supplier?

No. The requisition stays inside the company. Sending one to a supplier would communicate an internal estimate as though it were an order, which creates confusion about what has actually been committed. The supplier's first sight of the transaction is the purchase order, which carries a PO number, the agreed prices, and the terms and conditions that make it enforceable.

How does a purchase requisition become a purchase order?

Procurement takes the approved requisition, confirms the supplier and current pricing, applies any contract or blanket agreement rates, assigns a sequential PO number, adds the standard terms and conditions, and issues the document. In an ERP this is usually one action that copies the requisition lines onto a new PO record and links the two, so the audit trail runs from the original request through the approvals to the order.

One requisition does not always become one purchase order. Requests for the same supplier can be consolidated onto a single PO to reduce paperwork and hit volume pricing. A single large requisition can split into several POs when the items come from different vendors. What must be preserved is the link, so that any line on any PO traces back to an approved request.

Where the requisition process actually breaks

Rarely in the policy. Almost always in one of these four places.

• Requests arrive as email. An untracked request cannot be routed, aged, or audited, and it starts the shadow purchasing that policy exists to prevent.
• Approvers are a bottleneck. A single director approving every requisition means requests sit for days, and the requester learns to buy on a card instead.
• Nobody checks existing contracts. The item was already on a blanket agreement at a negotiated rate, and the new order pays list price. That is the whole saving from the agreement, lost quietly.
• The PO never becomes data. The order is issued as a PDF and lives in an inbox, so receiving and accounts payable have nothing to match against. The requisition was controlled and the commitment is invisible.

Do small businesses need purchase requisitions?

Not always. Below a handful of people, the person spending the money and the person accountable for the budget are frequently the same, and a requisition step adds paperwork without adding control. The threshold worth watching is not headcount but delegation: the moment someone can commit company money without the budget holder seeing it first, you need a requisition step, even if it is a shared form and a two-line approval rule.

Where automation actually helps

Requisition intake and approval routing are workflow problems, and they belong in a procurement system or ERP that holds the budgets and the approval matrix. There is no shortcut there, and any tool claiming to automate the approval decision itself should be treated with suspicion.

The step that is genuinely mechanical is document capture on either side of the workflow: reading the supplier quote that informs the requisition, and reading the acknowledgment or invoice that comes back against the issued PO. PurchaseOrders handles the purchase order side of that, turning PDFs into structured records so the commitment is visible and matchable. It does not raise requisitions, hold budgets, or route approvals. When the supplier invoice eventually lands against the order, teams typically pair it with accounts payable automation so both documents reach the match as data rather than attachments. To follow the order through to payment, see the purchase order to invoice process, and to keep the resulting commitments visible, AI purchase order tracking covers the open-order side. If you are drafting the PO itself, how to create a purchase order and purchase order fields cover what belongs on the document.