A purchase requisition workflow enforces pre-commitment spend control by routing every request through defined approval stages before any money is legally owed to a vendor. It works at either the header level, treating the whole document as one unit, or the line level, letting individual items move independently based on cost center or category. Once a requisition reaches Approved status, it becomes eligible for conversion into a purchase order, the point where the organization takes on external liability.
TL;DR:
- Requisitions should be routed at the line level when items are charged to different departments or require specialized approvers, while document-level routing works best for single-cost center requests.
- Approval statuses are typically populated through six core states, with approval or rejection at any stage triggering specific actions such as PO creation or cancellation.
- Workflow configuration must consider roles, assignment strategies, conditions like dollar thresholds, and testing scenarios like approver unavailability to ensure smooth operation.
- Automating integration with ERP, budget reservations, and catalog data enhances speed and accuracy, with quarterly vendor catalog audits reducing match failures.
- MPulse Software specifically supports maintenance requisitions through direct technician access, linking work orders, approvals, and purchase orders to streamline parts procurement.
Table of Contents
- How Purchase Requisition Routing Works in Practice
- What Do Purchase Requisition Statuses Mean?
- How Do You Configure a Requisition Approval Workflow?
- Designing Approval Stages: Serial, Parallel, and Thresholds
- Where Automation and Integration Fit in the Workflow
- From Approved Requisition to Purchase Order
- Rolling Out the Workflow Without Disrupting Operations
- How MPulse Supports Requisition Workflows for Maintenance Purchasing
- What to Do First If You’re Redesigning This Workflow
- A Practical Next Step for Maintenance-Driven Purchasing
- Sources
- FAQ
How Purchase Requisition Routing Works in Practice
Choosing between document-level and line-level routing is the first real design decision in any requisition approval workflow. The right choice depends less on company size and more on how consistently your spend maps to a single approver.
Document-level (full requisition) routing treats the entire requisition as one unit. Every line moves together, and one rejection sends the whole thing back. This works well when:
- A single cost center funds the entire request
- One manager has authority over everything being purchased
- The team is small enough that splitting approvals adds friction without adding control
Line-level routing separates approval by item or group of items. This becomes necessary when:
- Lines charge different departments or grant-funded projects
- Some items need a specialized approver (IT hardware, hazardous materials, capital equipment)
- Split funding sources require separate financial sign-off
In line-level setups, the header status typically reflects an aggregate of line statuses. A requisition with three lines fully approved and one still pending stays “In review” at the header until every line clears. Maintenance teams requisitioning a mixed cart, say, a pump seal from general inventory and a specialized sensor from a capital budget, are a textbook case for line-level routing.
What Do Purchase Requisition Statuses Mean?
Every requisition moves through a defined status lifecycle, and knowing who can trigger each transition prevents the ambiguity that causes stalled approvals. A purchase requisition workflow typically governs six core states, and the header status usually derives from the status of its lines rather than being set independently.
| Status | Who changes it | What happens next |
|---|---|---|
| Draft | Requester or preparer | Editable; not yet visible to approvers |
| In review | System, on submission | Routed to assigned approver(s); requester can recall |
| Rejected | Approver | Returns to requester for edits or cancellation |
| Approved | Approver (final stage) | Eligible for PO creation or demand consolidation |
| Cancelled | Requester or purchasing agent | Terminates the requisition; no PO will be created |
| Closed | Purchasing agent, after PO/receipt | Marks the requisition fully fulfilled |
A recall pulls a requisition back to Draft even after it enters review, which matters when a requester spots a coding error before an approver acts on it. Resubmission restarts the routing from the beginning unless the workflow is configured to resume at the point of rejection. Closed differs from Cancelled in one important way: Closed confirms the requisition ran its full course and generated a fulfilled PO, while Cancelled means it never will.
How Do You Configure a Requisition Approval Workflow?
Configuration comes down to four decisions: who participates, how they’re assigned, what conditions route requests to them, and how you verify it all works before go-live.
- Define the roles. At minimum, you need a requester, a preparer (if requesters don’t submit their own requisitions), a purchasing agent, an approving manager, and often an expenditure reviewer tied to the financial dimension being charged. Document who can create requisitions on behalf of someone else, and what limits that permission carries.
- Choose an assignment strategy. Options include supervisory hierarchy (routes to the requester’s manager automatically), position or job-level routing (ties approval to a role rather than a person), approval groups (a pool of eligible approvers), and expenditure reviewers, which route based on the financial account being charged rather than the org chart. Expenditure reviewer setups reduce the need to update assignments every time someone changes roles, a real advantage in matrixed organizations.
- Set conditions. Common rule triggers include dollar thresholds, procurement category, vendor type, and auto-approve criteria for pre-cleared, low-risk requests. Systems generally allow recall and resubmission at any stage, so build that expectation into your rules rather than treating every rejection as a dead end.
- Test before rollout. Run a checklist covering: routing to the correct approver by amount and category, notification delivery, recall and resubmission behavior, and what happens when a designated approver is unavailable.
Pro Tip: Test the “approver on vacation” scenario deliberately. Most workflow failures in production trace back to a missing fallback rule, not a broken condition.
Designing Approval Stages: Serial, Parallel, and Thresholds
ERP and procurement platforms commonly seed multiple approval stages, typically header preapproval, header approval, and postapproval FYI, giving you a structure to build on rather than starting from a blank rule set, according to Oracle’s implementation guidance. Preapproval catches obvious problems (missing budget, wrong vendor) before it reaches a manager’s queue. Header approval is where real spend authority sits, and Postapproval FYI notifies stakeholders, like a department head or auditor, without giving them power to block the requisition.
- Serial routing sends a requisition through approvers one at a time, each seeing it only after the prior stage clears. It’s slower but creates a clean, sequential audit trail.
- Parallel routing sends the same requisition to multiple approvers simultaneously, either requiring all of them to sign off or accepting the first response. It cuts cycle time but demands clear rules for tie-breaking.
- Financial thresholds should scale with organizational risk tolerance, not just dollar amount. A modest threshold might trigger single-approver sign-off, while higher amounts could require serial routing through multiple approval stages.
Mixing supervisory, position level, and job level participant types lets you match approval rigor to actual control policy instead of forcing every request through the same gate.
Where Automation and Integration Fit in the Workflow
The requisition workflow doesn’t operate in isolation. It needs to talk to your ERP, your inventory or CMMS system, and your accounts payable process to avoid creating a paperwork bottleneck downstream.
- ERP and AP integration ensures approved requisitions carry accurate GL coding into the PO and, eventually, into three-way match against the invoice and receipt.
- Auto-approval for low-risk requests (small dollar amounts, pre-approved vendors, standard catalog items) frees human approvers to focus on exceptions.
- Budget reservations (pre-encumbrances) lock funds against an approved requisition before the PO is even issued, preventing double-spending against the same budget line.
- Catalog and contract data quality matters more than most teams expect: a mismatched vendor price or missing GL code at the requisition stage nearly always resurfaces as a failed three-way match weeks later.
Automating the data capture that feeds PO creation removes the slowest manual work in the cycle, and it improves speed without sacrificing control as long as the underlying catalog data stays clean and current.
Pro Tip: Audit your vendor catalog quarterly. A stale price list is the single most common cause of three-way match failures, and it’s entirely preventable.
From Approved Requisition to Purchase Order
Approval is not the finish line. It’s the handoff point where procurement takes over and turns intent into a binding commitment. PO creation typically follows five concrete actions:
- Confirm the approved requisition and verify no line-level rejections are outstanding.
- Select the vendor and pricing source, pulling from a contract or catalog where one exists.
- Assign a unique PO number, the identifier that ties requisition, receipt, and invoice together for the three-way match.
- Enter line items, terms, ship-to, and bill-to details, correcting any gaps the requisition left open.
- Review and issue, sending the PO to the vendor and closing the loop on that requisition.
Demand consolidation, combining multiple approved requisition lines from different requesters into a single PO, usually happens after approval and, where budget control is active, after the budget reservation is recorded. Consolidating routine parts orders across several maintenance requests into one vendor PO cuts down on duplicate freight charges and administrative overhead.
Rolling Out the Workflow Without Disrupting Operations
A workflow that looks correct on paper still needs real-world testing before you trust it with live spend. Run these scenarios before go-live: a split-charge requisition across two departments, an unavailable approver forcing fallback routing, a recall and resubmission cycle, and an auto-approve rule firing correctly on a qualifying low-dollar request.
Training should cover four distinct audiences separately: requesters need to know how to build a clean requisition; preparers need on-behalf rules; approvers need to understand thresholds and stage sequence; and procurement needs the consolidation and PO-issuance checklist.
Track a small set of KPIs from day one:
- Approval cycle time (submission to final approval)
- Rejection rate by stage
- PO cycle time (approval to issuance)
- Exception queue size (requisitions stuck outside normal routing)
Assign a named workflow owner, typically someone in procurement or finance operations, responsible for reviewing thresholds and routing rules on a set cadence. The seven-step procurement cycle only holds together when someone owns the handoff points between each stage, not just the individual steps.
How MPulse Supports Requisition Workflows for Maintenance Purchasing
Maintenance operations generate requisitions differently than general procurement: a work order identifies a parts shortage, someone requisitions the replacement, and the clock on equipment downtime starts running the moment that request stalls. MPulse Software’s purchase requisition feature is built around that specific trigger chain.
- The inventory shopping cart lets technicians requisition parts directly from stock records, cutting the manual re-entry that causes GL coding errors.
- A calendar interface ties requisition timing to scheduled preventive maintenance, so parts orders align with planned downtime instead of trailing behind it.
- Integration capabilities connect requisition data to ERP and AP systems, supporting the same three-way match discipline covered earlier.
A typical flow looks like this: a work order flags a failing part, the technician requisitions it through the shopping cart, the request routes for approval based on cost, and an approved requisition converts into a PO for receiving.
What to Do First If You’re Redesigning This Workflow
Start by documenting your current routing and where requisitions actually stall, not where the org chart says they should. Pick one department for a pilot, set conservative thresholds, and track approval time and exception rate for thirty days. Expand once those numbers improve, not before.
— Mark
A Practical Next Step for Maintenance-Driven Purchasing
If parts requisitions are stalling because your maintenance team and your purchasing system don’t talk to each other, that’s a workflow gap, not a staffing problem. MPulse Software connects work order demand directly to requisition routing and PO creation, so a flagged part moves from shortage to purchase order without a manual handoff at every stage.
The purchase requisition feature handles line-level routing and expenditure-based approvals out of the box, and the inventory shopping cart keeps technicians from re-keying part numbers that later cause coding errors downstream. If your organization runs on preventive maintenance schedules, it’s worth seeing how requisition timing maps to planned downtime on the MPulse CMMS platform. Request a walkthrough of the requisition and PO workflow to see how it fits your current approval structure.
Sources
- Procurement stages — Stotles
- Purchase requisition workflow — Microsoft Learn
- Considerations for Setting Up Requisition Approval Task — Oracle Docs
- Purchaseorders
FAQ
What Is the Difference Between a Requisition and a Purchase Order?
A requisition is an internal request to buy something and carries no vendor obligation; a purchase order is the external, binding commitment created only after the requisition is approved.
Should I Route Requisitions at the Header or Line Level?
Route at the header level when one approver and one cost center cover the entire request; switch to line-level routing when items split across departments, funding sources, or approval authorities.
What Triggers Automatic Approval in a Requisition Workflow?
Auto-approval rules typically fire on low-dollar amounts, pre-approved vendors, or standard catalog items, letting systems skip manual review for low-risk purchases.
Can a Requisition Be Recalled After Submission?
Yes, most systems allow the requester to recall a requisition back to Draft status even after it enters review, as long as an approver hasn’t already acted on it.
Does MPulse Software Support Requisition Approval Routing?
MPulse Software’s purchase requisition feature supports line-level requisitioning tied to maintenance work orders, including inventory shopping cart integration and routing through approval before PO creation.
