Key Takeaways
|
Introduction
A purchase requisition is the last practical moment to ask “should we buy this, from whom, and with whose money?” Once a supplier has the order, those questions get awkward. The need usually shows up on the floor: a maintenance tech needs a bearing before second shift, a logistics manager needs spot carrier capacity because a contracted lane fell through, an energy site needs a contractor on site Monday for a scheduled outage. All three are legitimate, and all three can become unapproved spend if someone just picks up the phone.
The teams that struggle are rarely acting in bad faith. They run approvals through email, a shared inbox, and a verbal “go ahead,” and three months later finance asks who approved the spend and whether there was budget. Nobody can answer without digging through old threads. This guide covers what a requisition is, how the process works, who approves it, and what a template should include.
What Is a Purchase Requisition?
A purchase requisition is an internal document or digital request that asks authorized stakeholders to approve a planned purchase before a purchase order is created and sent to a supplier. The CIPS glossary, as quoted by Designing Buildings, describes it in similar terms: a paper or electronic document stating a need for procurement to supply a product or service. Three parties are usually involved:
- Requestor: The person who identifies the need and documents it, such as a maintenance planner, site supervisor, or project engineer.
- Approver: The budget owner, department leader, or procurement reviewer who confirms the need is real, funded, and within policy.
- Buyer or procurement team: The people who turn an approved request into a sourcing action, a purchase order, or a catalog order against an existing contract.
Take a simple manufacturing case. A maintenance planner needs two replacement motors for a shutdown six weeks out. She raises a requisition with the asset numbers, specifications, quantity, required-by date, and cost center. It routes to the plant budget owner, then to procurement. Nothing has been ordered, but everyone who needs to weigh in now can. Requisitions typically cover three kinds of buying:
- Catalog purchases: Standard, pre-approved items with known pricing, such as PPE, MRO consumables, and IT hardware. These should move fast.
- Non-catalog purchases: Items or services that need a quote, a sourcing event, or a contract check before anything is ordered.
- Service requests: Contractor labor, freight services, equipment rental, and engineering support. These often carry the most risk and the least structured documentation.
Purchase Requisition vs. Purchase Order
A purchase requisition is internal authorization to buy. A purchase order is the external commercial document that tells a supplier what you are ordering and on what terms. One faces inward; the other faces outward and usually creates a binding obligation.
Purchase requisition vs. purchase order
| Point of comparison | Purchase requisition | Purchase order |
|---|---|---|
| Primary purpose | Requests approval to buy | Places an approved order with a supplier |
| Audience | Internal stakeholders | Supplier and internal stakeholders |
| Created by | Requestor, manager, or department user | Buyer, procurement team, or approved workflow |
| Timing | Before supplier commitment | After approval and supplier selection |
| Commercial commitment | No | Usually yes, subject to PO terms |
The confusion usually starts in smaller organizations, where one person raises the request and cuts the purchase order. It can feel like paperwork theater, but the two records answer different questions. The requisition records why the organization agreed to spend the money. The PO records what it committed to buy and from whom. When a supplier dispute or an audit comes up, you need both. If your policy uses both “purchase request” and “purchase requisition,” write down the difference so requestors do not have to guess which form to use.
How the Purchase Requisition Process Works
Most requisition workflows follow seven stages, from identifying the need to payment. The stages stay fairly constant; the approval route inside them should change with spend level, category, risk, and urgency.
1. Identify the Need and Check Coverage
Someone recognizes a need and checks whether an approved catalog, contract, or existing supplier arrangement already covers it. That is the step people skip, and a yes shortens everything after it.
2. Create the Purchase Requisition
The requestor enters the details, attaches supporting documents, and either selects a supplier or flags the request for sourcing. Describe the need, not just the brand: “Replacement bearing, SKF 6205-2RS, for conveyor drive on Line 3” tells a buyer what to order and why. Name a specific brand only when compatibility, warranty, or a contract requires it, and say so.
3. Check Policy, Budget, and Required Information
Before routing, the system should check mandatory fields, duplicate requests, budget availability, preferred-supplier rules, and spend thresholds. Automated checks surface problems earlier but do not remove them. They depend on current cost centers, live contract records, and an approval matrix that reflects who holds authority today, not two reorganizations ago.
4. Route to the Right Approvers
Approvers can include the budget owner, department head, project manager, procurement, finance, legal, EHS, or IT. Route on purchase type and risk, not just dollar value. For example, a hypothetical $4,000 contractor request for confined-space work carries more risk than a $40,000 steel order against a standing contract, and value-only routing gets the first one wrong.
5. Procurement Reviews, Sources, or Validates the Supplier
What happens next depends on the request. A catalog or contracted item needs a light check or automatic PO creation. A non-catalog item goes to a buyer who collects quotes through an RFQ and negotiates terms, with supplier management records showing who is already approved. A strategic or high-risk buy feeds a formal sourcing event with evaluation criteria and contract review. This is where a good requisition pays for itself: a complete scope of work lets a buyer go to market quickly, while three lines of description force them to reverse-engineer the requirement.
6. Issue the Purchase Order
Once approval and supplier selection are complete, procurement or the system creates the PO with the final supplier, price, quantity, and delivery terms. Until it is issued, you have an internal agreement to spend, not an order.
7. Receive, Match, and Pay
The receiving team confirms delivery, and accounts payable matches the invoice against the PO and the receipt before releasing payment. This three-way match compares what you ordered, received, and were invoiced. If the three disagree, you find the exception before the money leaves.
Not every request should travel at the same speed. A catalog item can go from approved requisition to PO in minutes, while a six-figure capital request should trigger quotes and contract review. Emergencies deserve their own lane, since a turbine trip should not wait on a three-step approval chain, but faster is not invisible. Document the trigger, create the record at the time of the buy, and review repeat “emergencies” afterward so they get solved with a contract instead of a workaround.
What Information a Purchase Requisition Template Should Include
A requisition should give an approver enough to decide and a buyer enough to act without a follow-up email. If an approver has to ask for a cost code or delivery date, the request was not ready to route. A template should capture seven blocks of information:
Purchase requisition template sections
| Template section | Fields to include | Why it matters |
|---|---|---|
| Request details | Requisition number, date, requestor, department, site | Identifies who needs the purchase and where |
| Item or service details | Description, specification, quantity, unit of measure | Lets approvers and buyers understand the requirement |
| Delivery requirements | Required-by date, delivery location, receiving contact | Helps avoid late or misrouted deliveries |
| Financial details | Estimated price, currency, cost center, GL or project code | Supports budget review and accounting |
| Supplier details | Preferred supplier, quote reference, contract number, or “sourcing required” | Connects the request to supplier controls |
| Business justification | Reason, operational impact, urgency | Gives approvers the decision context |
| Approval record | Approver, role, decision, date, comments | Creates a clear authorization record |
Required fields should vary by purchase type. Manufacturing requests need an asset ID and maintenance window, energy and utilities requests need a work order reference and contractor safety requirements, and freight requests need lane, service period, and volume assumptions. Asking for an asset number on a standard laptop is friction with no control value, and friction pushes people toward the P-card.
On justification, specific beats are thorough. “Needed for production” tells an approver nothing. “Replace failed conveyor motor MTR-204 before the 14 June production run; continued operation risks unplanned line downtime” can be approved in thirty seconds. If you use a manual template, assign a unique number to every request and store the approved version in an access-controlled location. An email thread is not an approval record.
Who Creates and Approves Purchase Requisitions
Requestors create purchase requisitions. Budget owners, procurement, finance, and subject-matter reviewers approve them, depending on what is being bought. Ownership is shared, so the roles have to be explicit.
Roles in the requisition process
| Role | Main responsibility |
|---|---|
| Requestor | Defines the need and supplies accurate information |
| Budget owner | Confirms the spend is necessary and funded |
| Procurement | Applies sourcing, supplier, and policy controls |
| Finance | Oversees budget, accounting, and authorization rules |
| Subject-matter reviewer | Reviews technical, safety, legal, IT, or project requirements |
| Accounts payable / receiving | Confirms receipt and matches invoices after the PO is issued |
Underneath the table sits segregation of duties. The person who requests a purchase should not also approve every stage, select an unvetted supplier, and release the payment. Each is reasonable alone. Doing all four alone is how fraud and error go unnoticed.
Benefits of Purchase Requisitions
The main benefit is that the decision point moves earlier, before a commitment exists and while changing your mind is still cheap.
- Earlier spend visibility: Finance and procurement see committed demand before invoices arrive.
- Better budget control: Budget owners review expected spend while they can still say no.
- Fewer unauthorized purchases: Clear rules cut down on “we already ordered it, we just need a PO number.”
- Stronger supplier compliance: Requestors are directed to approved suppliers, contracts, and catalogs.
- Cleaner audit trail: Every decision, attachment, and approval sits on one record, not across five inboxes.
One caveat: a process that demands four approvals for a $90 box of gloves creates workarounds, not control. People return to email, P-cards, and off-contract buying, and visibility drops. Controls should scale with risk, with low-value contracted purchases nearly frictionless.
Problems With Manual Requisition Workflows
Manual workflows break down in predictable ways: shared inboxes, unsigned PDFs, spreadsheet trackers only one person maintains, and approvals that stall when a manager is on site visits.
- Missing details: Buyers chase cost codes, specifications, and delivery dates that should have been captured at submission.
- Approval bottlenecks: A request sits in an inbox with no reminder, no escalation, and no visibility that it is stuck.
- Inconsistent controls: Maintenance uses a form, engineering uses email, and a third site runs an undocumented process.
- Fragmented records: The quote lives in one inbox, the approval in another, and the PO in the ERP, with nothing linking them.
- Weak reporting: Nobody can say how much spend was requested last quarter, how long approvals took, or how much went off-contract.
To be fair, a small team with one site and forty requisitions a month can run a sound process on a controlled form and a documented approval matrix. Complexity rises fast with multiple sites, dozens of cost centers, and tiered thresholds, and the manual version turns into tribal knowledge. Cloud-based procurement platforms replace email-based approval chains with configurable workflows and an audit trail. We built ProcureClix so purchase requisitions, approvals, and RFx events sit in one audit-ready workflow, with approval rules configured to your process instead of living in someone’s head.
How to Improve Your Purchase Requisition Process
Fix the decision rules first, then fix the form. Most teams already have a template somewhere. What they lack is consistency about who approves what, how fast, and with what information.
- Map your current approval paths. Write down who actually approves which categories, spend levels, and sites, not who the policy says. The gap between the two is usually where cycle time goes.
- Separate routine from exceptional buying. Catalog and contracted purchases should move with minimal review, and non-standard or high-risk requests get more scrutiny.
- Standardize required fields by purchase type. A maintenance spare, a consulting engagement, and a spot freight booking need different information.
- Set approval service levels. Define an expected turnaround and an escalation rule when nobody responds, so “waiting on approval” has an end point.
- Measure workflow health. Track requisition-to-PO cycle time, approval turnaround by approver, rejection reasons, non-PO invoices, and off-contract spend, which spend analysis can help surface.
- Review exceptions monthly. Look for repeat emergency buys, recurring non-catalog demand that belongs under a contract, and approver queues causing most delays.
One caution: do not automate a broken approval chain. If seven people approve a $500 request today, automation just notifies them faster. Agree on decision rights and thresholds first, then configure software around them. The compliant path has to be easier than the workaround, because when the approved route is slower than the shortcut, people take the shortcut.
Conclusion: A Purchase Requisition Is the Checkpoint Before a Commitment
A purchase requisition gives your organization a structured way to validate a need, confirm authority and budget, and route the request to the right reviewers before a supplier sees an order. The point is not paperwork. It is preventing the unrecognized invoice in month three while letting urgent, legitimate work move at the speed operations needs. Start with your top three requisition categories by volume to see where a consistent workflow helps most, then book a ProcureClix demo to see the workflow on your own approval rules.
Frequently Asked Questions About Purchase Requisitions
What is the meaning of purchase requisition?
A purchase requisition is an internal request asking authorized stakeholders to approve the purchase of goods or services. It captures the business need, expected cost, accounting details, and required approvals before a purchase order is issued. It stays inside the organization and does not commit any supplier to deliver anything.
Is a purchase requisition the same as a purchase order?
No. A requisition asks for internal approval to buy, while a purchase order is sent to a supplier to place the order and usually creates a commercial commitment. Low-value catalog purchases can move from approved requisition to PO in minutes, but the two documents still answer different questions.
Who approves a purchase requisition?
Whoever holds spending authority for that budget, category, and value under company policy. Typical approvers include the budget owner, department leader, procurement, finance, and reviewers such as IT, legal, or EHS. The route should reflect risk as well as value, and urgent requests need a documented exception path with an after-the-fact review.
Can a purchase requisition be created without a supplier?
Yes. A requestor can define the need and leave the supplier blank when procurement needs to source it. For new, high-value, or non-standard purchases that is usually better, because it leaves room for competitive quotes and contract review. The request still needs enough technical detail for a buyer to run a credible sourcing process.
