Purchase Requisition and Approval Automation That Holds Up

When someone asks me to "automate purchase requisitions," they usually mean "make approvals faster." That framing quietly assumes the flow is right and only slow. It rarely is. The requisition-to-PO journey is a routing problem before it is a speed problem, and if you automate the wrong route you just deliver bad decisions faster. This is how I design the flow from need identification through to PO release, where the real cycle-time wins hide, and how to keep the whole thing defensible when audit comes knocking.

Shape the flow before you automate it

A requisition passes through five roles no matter what tool you buy: the requester who has a need, the budget holder who owns the money, a technical approver who confirms the request is specified correctly, procurement who converts it into a compliant order, and finance who commits the funds. Automation does not change who these people are. It changes how a requisition finds its way between them.

The mistake I see most often is a single linear chain: requester, then line manager, then department head, then procurement, then finance, in that fixed order, for every line regardless of value or type. That design is easy to draw and miserable to live in. A stationery order for 200 dirhams should not touch four approvers. A 400,000 dirham electrical panel should touch more than four. The flow has to branch on the properties of the requisition itself, which is why I start every design by listing those properties, not by drawing boxes.

Catalogue versus free-text requisitions

The single most important split in the entire flow is catalogue versus free-text. A catalogue line is a pre-approved item from a pre-approved supplier at a pre-negotiated price. The specification, the vendor, and the rate have already been signed off, so there is nothing left for a technical approver to review. A free-text line is a description someone typed. Nobody has confirmed the item is correct, the supplier is appropriate, or the price is sane, so every free-text line drags a technical review step behind it.

That is why catalogue coverage, not workflow speed, is usually the biggest cycle-time win available to you. Every line you move from free-text into the catalogue is a line that skips technical review entirely and can, below a threshold, auto-convert to a PO. Teams spend months tuning approval timers and reminder emails to shave hours off a chain that free-text requisitions are forcing through an extra human step. Widen the catalogue and that step disappears for most of your volume.

Check budget at submission, not at PO

Here is a design decision that quietly determines whether the whole system works: when does the budget check happen? The lazy answer is "at PO," because that is where the money legally commits and where the ERP naturally enforces it. The correct answer is "at submission," because that is where the requester and budget holder can still do something about it.

If the budget check fires only at PO, a requisition can travel through three approvals, sit in a procurement sourcing queue for a week, and then bounce because the cost centre ran dry days ago. Everyone in the chain wasted their time. Worse, the requester learns nothing until the end, so they keep raising requisitions the budget cannot support. Checking available budget at the moment of submission, and showing the requester the remaining balance before they hit submit, turns a late rejection into an early conversation. The commitment still lands at PO. The visibility lands at the start.

In practice this means the requisition form calls your finance system for the live committed-and-actual balance on the cost centre and category, then either passes, warns, or blocks. A soft warning with a budget-holder override is usually the right posture; a hard block frustrates legitimate reprioritisation and pushes people toward off-system workarounds.

Enforce contracts and preferred suppliers

A requisition system that lets anyone name any supplier is a maverick-spend generator. If you have negotiated a contract, the flow should make using it the path of least resistance and make bypassing it visible. I enforce this at two points. First, catalogue items are locked to their contracted supplier and rate, so a catalogue line simply cannot go to the wrong vendor. Second, free-text lines in a category that has a preferred or contracted supplier trigger a rule: either steer the line onto the contract, or force a documented reason and an extra procurement approval for going off-contract.

The goal is not to make off-contract buying impossible, because genuine exceptions exist. The goal is to make it a deliberate, recorded decision rather than an accident. Every off-contract line that slips through silently is a line your category managers negotiated a rate for and then failed to capture. The workflow is where you capture it.

The four dimensions that route a requisition

Once you stop thinking in a single linear chain, a requisition's path is decided by four dimensions working together. Value alone is not enough; a low-value item in a sensitive category still needs scrutiny, and a routine item from a risky supplier still needs a second look. These are the four I build routing rules around.

Any serious low-code or workflow engine can evaluate these four inputs and compute a path. If you are weighing which engine, my platform scoring framework walks through the trade-offs. Tools such as Microsoft Power Automate approvals handle the routing and sign-off mechanics well, while procurement-specific suites like Coupa bundle catalogue, contract, and budget controls into one place. The engine matters less than getting these four dimensions and their thresholds right first.

The delegation matrix

The value dimension is governed by a delegation of authority matrix: who can approve up to what amount. This is the document finance and audit care about most, so it belongs in one authoritative table that the workflow reads, not scattered across form rules nobody can reconstruct. A workable matrix looks like this, with amounts in local currency and each tier stacking on the ones before it.

Value bands are the spine, but categories override them. An IT purchase of any value routes through the IT approver so shadow systems do not creep in. Capex routes through the capex committee regardless of amount. Chemicals route through HSE. These category overrides sit on top of the value matrix: the requisition takes the union of both, so a mid-value IT capex item collects the value-band approvers and the IT approver and the capex approver. Encode the overrides as their own small ruleset so you can change a category policy without rewriting the value bands.

The approval path, end to end

Putting it together, here is the flow across all five roles for a typical requisition. Catalogue lines take the express lane and skip technical review; free-text lines carry the extra step. The budget check sits at submission, before any approver spends time on the request.

The green dashed path is the express lane: a catalogue line that passes budget goes straight from the budget holder to procurement, bypassing technical review, and below the auto-PO threshold it can convert to an order with no procurement touch at all.

Emergency and breakdown requisitions

Every flow above assumes there is time to approve before the money is spent. Maintenance and operations do not always have that time. A pump fails at midnight, a contractor needs a part now, and the standard chain of four approvers is not going to happen before the line goes down. If you design the flow as if emergencies do not exist, you do not eliminate them. You just push them off-system.

The honest design is a sanctioned emergency path with a shortened approval and stronger after-the-fact controls. One or two senior approvers can authorise an emergency requisition on the spot, often from a phone, with a mandatory reason code and a category cap. In exchange, every emergency requisition is flagged, reported weekly, and reviewed after the fact by procurement and finance. You accept a faster front door in return for tighter back-end scrutiny. This is a compensating control, and it is exactly the kind of trade audit will accept when you can show the review actually happens. I go deeper on approval-path design patterns in my approval workflows design guide.

The related lever is your first approval threshold: the value below which a requisition needs only a single sign-off. Raising it is the second-biggest cycle-time win after catalogue coverage, because it removes a whole tier from the majority of low-value requisitions. Finance almost always resists, and their instinct is reasonable, because a higher threshold means more spend approved by fewer eyes. Audit, in my experience, accepts a higher threshold when you pair it with compensating controls: post-approval sampling, spend analytics by requester, and the contract enforcement described above. Frame the threshold conversation as a controls trade, not a speed demand, and it usually lands. For where this sits in the wider procure-to-pay chain, see my walkthrough of the PR to PO to GRN workflow.

KPIs that prove it works

You cannot tell whether the redesign worked from the number of emails the system sent. Three measures tell the real story, and I track them from day one so improvements are visible and regressions are caught.

• Requisition-to-PO days. Elapsed time from submission to PO release, measured as a median and a ninetieth percentile. The median tells you the common case; the tail tells you where requisitions get stuck. Segment it by catalogue versus free-text and the catalogue coverage argument makes itself.
• Percentage retrospective. The share of POs created after the invoice or delivery already existed. This is your control-health number. If it is high, your emergency path is missing or too hard to use, and no amount of front-end elegance is saving you.
• Approval touches per requisition. The average number of human sign-offs a requisition collects. If it is climbing, your routing is too conservative and you are burning approver time; if a value band routinely collects more touches than the matrix intends, a rule is misfiring.

Watch these three together. Cutting requisition-to-PO days while retrospective POs climb means you sped up the compliant flow and pushed the urgent work off-system, which is not a win. The target is faster cycle time, a falling retrospective rate, and approval touches that match the delegation matrix rather than exceeding it.

Where automation actually pays off

Automating requisitions is not about making a bad chain run faster. It is about routing each requisition to exactly the approvers its value, category, budget status, and supplier risk demand, checking budget where the requester can still act on it, enforcing the contracts you negotiated, and giving urgent work a sanctioned door so it never becomes a retrospective PO. Do that, and the automation is worth building. Skip it, and you have digitised a bottleneck.

A note on independence: I am not affiliated with, resold by, or compensated by any of the vendors mentioned here. Products are named as illustrations of a category, and the design principles apply whichever engine you choose.