What Is a Purchase Requisition? The Step That Happens Before the PO
A purchase requisition — often abbreviated 'PR' — is the internal document an employee uses to request that their company buy something. It lives entirely inside the organization: the employee tells their manager what they need, why they need it, and what they expect it to cost. The manager reviews and either approves, modifies, or rejects. Only after approval does the requisition trigger a purchase order to an outside vendor.
The requisition is the pre-commitment step. Nothing is purchased yet. No vendor has been contacted. No dollar amount has been committed. The requisition is the mechanism that lets a company verify the purchase is needed, is within budget, is authorized at the right level, and is going through the right vendor — before any of those decisions become difficult to reverse.
The two documents look similar and are often confused, but they serve different purposes and have different audiences.
Key differences between PR and PO
- Audience — requisition is internal (employee to manager); PO is external (buyer to vendor)
- Timing — requisition comes first; PO is issued after the requisition is approved
- Legal effect — requisition is a request with no legal commitment; PO is a binding commitment to buy
- Dollar amount — requisition carries an estimate; PO carries the actual contracted amount
- Approval — requisition triggers internal approval routing; PO triggers vendor acknowledgment and fulfillment
- Retention — requisition stays in internal records; PO goes out to the vendor and becomes part of the purchase file
A well-designed requisition gives the approver enough information to make a good decision without having to ask follow-up questions.
Standard fields on a purchase requisition
- Requestor information — name, department, cost center
- Date of request
- Description of goods or services needed, with specifications
- Quantity and unit of measure
- Estimated unit price and extended total
- Suggested or preferred vendor (if known)
- Requested delivery date and delivery location
- Justification / business purpose
- Budget account, job number, or cost code to charge
- Approval signatures or electronic authorization record
Most organizations route requisitions through dollar-threshold-based approval paths. A $500 request for office supplies might need only the direct manager's approval. A $50,000 request for equipment might need department VP plus CFO. A $500,000 request for specialty materials on a major project might need owner-level sign-off.
The routing hierarchy should match the approval hierarchy that governs the eventual PO. If POs over $25K need controller approval, then requisitions that will produce POs over $25K should also surface to the controller at the requisition stage. Approving the requisition and then re-approving the PO is redundant; approving only the PO after commitment leaves the pre-commitment step ungated.
The cleanest structure is requisition approval that carries through to PO approval automatically — one approval event, not two. The PR/PO distinction is about timing and commitment, not about who approves what. Duplicate approvals create process drag without adding control.
Construction has a specific relationship with requisitions because much of the purchasing happens in the field on short notice. A supervisor discovering a material shortfall can't wait for a standard three-day requisition approval cycle if the crew is ready to install the next day. The practical accommodation is tiered requisition policies:
Construction-adapted requisition policies
- Routine planned purchases — full requisition flow with standard approval routing
- Field-level urgent needs under a threshold — pre-authorized purchasing per project with cost-code enforcement, reconciled to requisition-equivalent documentation after the fact
- Standing requisitions — pre-approved recurring purchases (e.g., weekly fuel delivery) that don't need per-order approval
- Project-bound requisitions — requisitions tied to a specific job number and pre-approved within the job's budget
- Emergency procurement — explicit exception path with post-hoc approval required within a short window
Get AP insights in your inbox
Get our weekly roundup of AP automation tips and industry news. No spam, ever.
No spam. Unsubscribe anytime.
The requisition process is one of the cheapest controls in procurement, and it catches a specific set of problems before they become expensive.
Problems requisitions prevent
- Unauthorized spending — purchases made without management awareness or budget check
- Duplicate purchases — multiple employees ordering the same thing independently
- Wrong vendor selection — employees defaulting to a familiar but higher-priced vendor
- Budget surprises — spending that would exceed the department's or project's authorized budget
- Specification drift — vague purchase requests producing wrong deliveries
- Procurement workload whiplash — last-minute requests that could have been planned
For recurring or standing purchases — office supplies, fuel deliveries, subscription software — a blanket PO with pre-set terms and an approved total budget eliminates the per-purchase requisition overhead. Individual releases against the blanket PO don't need a new requisition because the initial blanket PO approval covered the aggregate commitment.
This structure is meaningfully more efficient than requisitioning each order individually, and it's appropriate for predictable recurring spend. The requisition process is still valuable for one-time or irregular purchases where each transaction warrants review.
How requisition processes break down
- Threshold too low — employees requisition every paperclip, drowning approvers in trivial reviews
- Threshold too high — large purchases sneak through without appropriate oversight
- Bypass culture — approvers rubber-stamp without reading, effectively eliminating the control
- No forecasting — requisitions happen reactively instead of being planned against budget
- Missing information — requisitions lacking vendor, specs, or job code force the approver to chase details
- No feedback loop — rejected requisitions don't teach employees what good ones look like
Modern procurement systems handle requisitions digitally. Employees submit through a web or mobile interface, the system routes to the correct approver based on type and dollar amount, approvers review and decide within the system, and approved requisitions automatically generate POs for vendor dispatch. The full cycle takes hours instead of days, the audit trail is complete by default, and the data feeds directly into budget-to-actual reporting.
Digital requisitions also surface patterns that paper processes don't reveal easily. Which departments generate the most off-policy requisitions? Which employees consistently request below threshold and above it? Which vendors are disproportionately requested? These patterns inform procurement policy and help the company catch emerging issues early.
Purchase requisitions are the pre-commitment approval gate that separates controlled procurement from ad-hoc buying. In combination with purchase orders, they create a two-step structure — request and commit — where the first step catches unnecessary or unauthorized spend before it becomes a vendor obligation. Construction operations often need adapted requisition policies because of field-level urgency, but the underlying principle remains: purchases get approved before they happen, not justified after.
Written by
Sarah Blake
Head of Product
Former AP Manager at a $200M construction firm, now leads product at Covinly. Writes about what AP teams actually need from automation — beyond the marketing promises.
View all posts