Purchase Requisition: Definition, Process & Best Practices

What a Purchase Requisition Is

A purchase requisition is an internal request to buy something — submitted by an employee and approved inside the organization before any order is placed with a supplier. It is the document that says, in effect, “we need this, here is why, and here is the budget,” and it triggers the approval and purchasing process. Crucially, a requisition is an internal control, not a commitment to a vendor; no supplier sees it and no money is owed because of it.

That internal-versus-external distinction is the whole point of the requisition. It gives finance and procurement a checkpoint to confirm the need is legitimate, budgeted, and routed to the right supplier before a binding purchase order goes out. Skip it, and you lose the only moment where spend can be questioned before it is committed. In a mature operation the requisition is also the birthplace of clean spend data: the category, supplier, and cost-center codes captured here flow through every downstream report. This guide explains what a requisition contains, how the requisition process works step by step, how it differs from a purchase order, where it fits across different types of spend, and how automation is changing it. It sits upstream of the wider procure-to-pay process and feeds directly into purchase order automation.

Purchase Requisition vs. Purchase Order

The requisition and the purchase order are sequential documents that are constantly mixed up. The requisition comes first and is internal: an employee requests authorization to spend. The purchase order comes second and is external: once the requisition is approved, procurement converts it into a PO, which is a legally binding offer sent to the supplier. One asks permission inside the organization; the other places the order outside it.

The practical consequence is about control and liability. Because the requisition is internal, it can be challenged, amended, or rejected with no consequence to any supplier. Once it becomes a PO and the supplier accepts, you have a contract and a financial commitment. That is why mature organizations require an approved requisition before a PO can be issued — it forces the spend question to be answered before commitment, not after the invoice arrives. It also creates a clean audit trail: every order can be traced back to an approved request, an approver, and a budget line. For a side-by-side breakdown, see our purchase requisition vs purchase order comparison.

What a Purchase Requisition Contains

A good requisition carries enough information for an approver to make a decision and for procurement to convert it into a clean PO without chasing the requester. The fields below are the standard set; intake forms increasingly capture them through guided questions rather than a blank template.

The single most valuable field is the preferred supplier, because it is where guided buying can intervene: if the requester names an off-contract vendor, the system can redirect them to a contracted equivalent before the spend is locked in. That one nudge is among the highest-leverage controls in the whole source-to-pay process. The business-justification field is a close second — it is the only place demand itself gets challenged before money moves.

The Purchase Requisition Process, Step by Step

The requisition process is short but consequential. Each step is a control point, and the design goal is to make the compliant path fast enough that nobody is tempted to bypass it.

1. Create the requisition

The requester captures the need on an intake form or in the procurement system, ideally selecting from a catalog or contracted supplier list rather than free-typing. The cleaner the input here, the less rework downstream. Good intake tools validate the request in real time — flagging missing fields, duplicate requests, or items already under contract — so problems are caught before approval rather than after a PO has gone out.

2. Approve (or reject)

The requisition routes to the right approvers based on amount, category, and budget. This is where most requisitions stall, because approval chains are often longer and slower than the risk justifies. The goal is risk-based routing: auto-approve low-value, catalog-based requests, and reserve human review for genuine exceptions. A clear procurement approval workflow is what separates a one-hour approval from a two-week one, and it is the single biggest determinant of whether requesters trust the system or route around it.

3. Convert to a purchase order

Once approved, procurement converts the requisition into a purchase order and issues it to the supplier. In an automated environment this is near-instant and touchless for catalog items; for complex or strategic buys, a buyer reviews and may consolidate multiple requisitions into a single PO or fold them into a sourcing event to capture volume leverage.

4. Fulfill and receive

The supplier delivers, and the goods or services are received and recorded against the PO. The receipt becomes one leg of the eventual three-way match against the invoice, closing the loop between what was requested, ordered, received, and paid.

5. Close the requisition

When the order is fully received and invoiced, the requisition is closed. Clean closure matters for reporting: open requisitions that never convert, or convert and never close, are exactly the noise that corrupts spend analysis and commitment accounting. A disciplined close keeps the organization's view of committed-but-unspent budget accurate.

Approval Workflows and Thresholds

Approval is the stage that makes or breaks the requisition experience. Too loose, and spend escapes control; too tight, and frustrated requesters route around the system entirely, which is how off-contract spend is born. The answer is tiered, risk-based approval: define thresholds where low-value, pre-approved catalog purchases clear automatically, mid-value requests need a manager, and high-value or off-contract requests escalate to procurement and finance.

Well-designed thresholds also reflect category risk, not just dollar amount. A modest purchase of a SaaS tool that will hold customer data may warrant more scrutiny than a larger order of standard office supplies. Encoding that logic into the workflow — rather than relying on approvers to remember it — is what turns a policy document into an enforced control. This is precisely the kind of routing that intake-to-procure AI platforms are built to automate, and it is where most of the cycle-time savings in modern requisition tooling come from.

Requisitions Across Different Types of Spend

One requisition template rarely fits every kind of purchase. A catalog buy for known goods needs almost no review and should flow through automatically. A services engagement — consulting, contract labor, marketing — carries scope and statement-of-work risk that a goods template does not capture, so it needs justification, deliverables, and often legal review. Capital expenditure adds a further layer of approval because of its size and balance-sheet treatment.

The implication for process design is to vary the requisition path by spend type rather than forcing everything through one heavy form. Catalog and low-risk indirect spend take the light path; services and capex take a deeper one with the right approvers and supporting documents attached. Getting this segmentation right is what keeps the routine fast without letting the risky slip through unexamined — the same tiering principle that governs supplier onboarding and the broader procure-to-pay process.

Common Requisition Problems

The complaints are predictable: approvals take too long, requesters do not know what to enter, and the same thing gets requested twice. Each traces back to either a bloated approval chain or a poor intake experience. When the official path is slow or confusing, people buy on a corporate card or call a familiar supplier directly — and the requisition control is bypassed exactly when it was supposed to bite.

The other quiet failure is data quality. Free-text item descriptions, missing GL codes, and inconsistent supplier names make downstream spend analysis unreliable, which weakens the next sourcing cycle. Because the requisition is where spend data is born, errors here propagate through the entire source-to-pay process. Fixing intake is therefore one of the highest-return improvements a procurement team can make, and tools such as Zip have built their entire proposition around a better front door for requests.

How AI and Automation Are Changing Requisitions

The requisition is being reinvented as a conversational, guided intake experience rather than a form. Modern intake and guided-buying tools let a requester describe what they need in plain language, then handle the rest: matching the request to a catalog item or contracted supplier, pre-filling fields, checking budget, and routing approvals automatically based on encoded policy. The effect is a dramatically shorter cycle time and far less maverick spend, because the easy path and the compliant path become the same path.

The strategic prize is not just speed. Because AI intake captures clean, structured data at the source, it improves everything downstream — PO accuracy, matching rates, and the spend visibility that feeds sourcing. If you are weighing where to invest first, our procurement AI buyer's guide covers how intake and guided buying compare to other automation, and the wider procurement blog goes deeper on purchase orders, approvals, and matching. For sizing the payback, the source-to-pay AI market analysis maps the vendors targeting the front of the process.

Frequently Asked Questions

What is a purchase requisition?

A purchase requisition is an internal request to buy goods or services, submitted by an employee and approved inside the organization before any order is placed with a supplier. It confirms that a need is legitimate, budgeted, and routed to the right supplier, and it triggers the approval and purchasing process. No supplier sees the requisition and no money is committed by it.

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

A purchase requisition is an internal document that authorizes a purchase inside the company; a purchase order is the external, legally binding document sent to the supplier to place the order. The requisition comes first and asks for permission to spend; once approved, procurement converts it into a purchase order, which creates a commitment to the vendor.

What information is on a purchase requisition?

A standard purchase requisition includes the requester and department, an item or service description with specifications, quantity and estimated cost, the preferred supplier, a business justification, the GL or cost center code, and the date required. This is enough for an approver to make a decision and for procurement to convert it into an accurate purchase order.

What are the steps in the purchase requisition process?

The purchase requisition process has five steps: create the requisition, route it for approval (or rejection), convert the approved requisition into a purchase order, fulfill and receive the goods or services, and close the requisition once it is fully received and invoiced. Approval is the step where requisitions most often stall.

How is AI used in the requisition process?

AI-powered intake and guided-buying tools let requesters describe a need in plain language, then match it to a catalog item or contracted supplier, pre-fill fields, check budget, and route approvals automatically based on encoded policy. This shortens cycle time, reduces off-contract spend, and captures clean spend data at the source.