Purchase Requisition vs Purchase Order: The Difference

A purchase requisition is an internal document asking for permission to buy something. A purchase order is an external document that commits your company to buying it. The requisition travels inside your organization and stops at an approver's desk. The purchase order leaves the building, goes to the vendor, and becomes a binding offer the moment the vendor accepts it. One is a request, the other is a contract.

That distinction sounds academic until an invoice arrives for something nobody remembers ordering. Companies that skip the requisition step lose the audit trail that shows who wanted the purchase and who approved it. Companies that skip the purchase order lose the document their accounts payable team needs to verify the invoice. Both steps exist because both problems are expensive.

Purchase requisition vs purchase order at a glance

The two documents look similar on paper. They carry item descriptions, quantities, and prices. What separates them is direction, audience, and legal weight.

What is a purchase requisition?

A purchase requisition is a formal internal request from an employee or department asking the company to buy goods or services. It names what is needed, how much, roughly what it should cost, and why. The requisition goes to a manager or budget owner, who approves or rejects it. Nothing is ordered and no money is committed until that approval lands.

The requisition exists to answer one question before any money moves: should we be buying this at all? It puts the spending decision in front of the person accountable for the budget, not the person who wants the item. In a well-run process, the requisition also checks the request against remaining budget, so an approver sees not just the cost but what is left in the department's line for the quarter.

Requisitions matter most where spend is decentralized. When forty people across six departments can each order supplies, the requisition is the only control standing between a budget and an unpleasant surprise at month end.

What is a purchase order?

A purchase order, or PO, is the document your company sends a vendor to formally order goods or services. It specifies the items, quantities, agreed unit prices, delivery date, shipping address, and payment terms, and it carries a unique PO number. When the vendor accepts it, the purchase order becomes a legally binding contract between the two parties.

That PO number is what makes the rest of accounts payable work. When the goods arrive, the receiving team records a goods receipt against the PO. When the invoice arrives, AP matches the invoice to the PO and the receipt. If all three agree within tolerance, the invoice clears for payment without anyone chasing an approval. That process is three-way matching, and it is impossible without a purchase order. Companies running high PO volume typically manage the whole lifecycle in dedicated purchase order management software rather than a spreadsheet.

Does a purchase requisition come before a purchase order?

Yes. The requisition always comes first. An employee raises a requisition, an approver signs off, and only then does purchasing convert the approved requisition into a purchase order and send it to the vendor. The sequence is deliberate: approval precedes commitment, so the company never contractually owes a vendor for something it never agreed to buy internally.

Not every purchase follows this path. Low-value, routine spend often runs on a blanket PO or a purchasing card, and some invoices arrive with no purchase order at all. Those are non-PO invoices, and they need a different approval workflow because there is no PO to match against.

Is a purchase requisition legally binding?

No. A purchase requisition creates no obligation to anyone outside your company. It is an internal request, and an approver can reject it without any legal consequence. The purchase order is the binding instrument. Once you issue a PO and the vendor accepts it, you have a contract covering the items, prices, and terms on that document.

This is exactly why the two documents are separate. If a requisition were binding, every employee who wanted a new laptop would be committing company funds. Splitting the request from the order keeps the authority to spend with the people who hold the budget.

Who approves a purchase requisition?

Usually the requester's department manager or the budget owner for the cost center being charged. Larger purchases climb an approval ladder: a manager might approve anything under $5,000, a director up to $25,000, and the CFO above that. Many organizations add a procurement review to confirm the vendor is approved and the item is not already under contract elsewhere, and a finance check to confirm budget remains.

Approval thresholds are one of the more useful accounts payable internal controls a company can implement, because they scale scrutiny to risk without slowing down routine spend.

What is a PR in procurement?

PR stands for purchase requisition. You will also see PO for purchase order, GR for goods receipt, and PR to PO as shorthand for the conversion step where an approved requisition becomes an order. In ERP systems like SAP, NetSuite, and Oracle, these are distinct record types with their own numbering and their own approval workflows.

How the two documents fit into procure to pay

Requisition and purchase order are the first two steps of the procure to pay process. The full chain runs: a need is identified, a requisition is raised and approved, a purchase order is issued to the vendor, goods or services are received and recorded, the vendor sends an invoice, AP matches the invoice against the PO and the receipt, and payment goes out.

Every link in that chain produces a document that the next link depends on. Break the requisition and you lose the record of who authorized the spend. Break the purchase order and AP has nothing to match the invoice against, which is how duplicate and inflated invoices slip through. When goods are received but the invoice has not arrived, the gap shows up as goods received not invoiced on the balance sheet, a number that only reconciles cleanly if the PO exists.

Common mistakes worth avoiding

The first is treating the requisition as a formality. If approvers rubber-stamp every request without checking budget, the control provides an audit trail and nothing else. The second is issuing purchase orders after the fact, backdating a PO once the invoice arrives to make matching work. That defeats the entire purpose, because the PO is supposed to be the record of what you agreed to before you owed anything.

The third is inconsistent PO numbering. Duplicate or reused numbers break matching and make it far harder to find duplicate invoices later, since two invoices referencing the same PO number look identical to most systems.

Automating the requisition to purchase order flow

Manual requisitions live in email and spreadsheets, which is why approvals stall and POs get issued late. Software fixes the sequencing: a requisition routes automatically to the right approver based on amount and cost center, converts to a purchase order on approval, and pushes that PO into the ERP so accounts payable can match against it when the invoice lands.

On the AP side, accounts payable software reads the incoming invoice, pulls the PO number, and matches line items against the order and the receipt automatically. Invoices that agree within tolerance post without human review. Exceptions route to a person. That combination, a disciplined requisition process feeding clean purchase orders into automated matching, is what lets a small AP team handle a large invoice volume without losing control of spend.