Purchase order approval workflow: thresholds, delegation and procurement handoff
Thresholds decide how deep the chain runs, delegation keeps it moving when an approver is away, and the handoff determines whether the resulting purchase order is usable by procurement and finance. The exceptions matter more here than in most approval processes, because a request blocked at approval blocks the work behind it.
Approval before the commitment
The distinction that shapes everything on this page is timing. An invoice approval reviews a commitment that already exists — the goods were ordered and probably delivered. A purchase order approval happens before anyone has promised a supplier anything, which means it is the only point in the cycle where a purchase can be declined without a conversation about a cancellation.
That is also why a well-run purchase order process reduces work downstream. A purchase order that was properly approved carries its authorisation with it, so the matching invoice can often clear without a second human approval. The value of tightening PO approval shows up in the accounts payable queue.
An approval given before the order is a control. The same approval given after the invoice arrives is a formality, because declining it means unwinding a commitment somebody has already made.
The terms that matter
Procurement vocabulary varies between organisations. These are the terms as used on this page.
Requisition
The internal request to buy something, raised before any supplier is contacted. What the approval chain actually acts on.
Purchase order
The numbered commitment issued to the supplier once the requisition is approved. Becomes the reference an invoice is matched against.
Approval threshold
An amount boundary that changes how many approvals a requisition needs, or whose approval is required.
Approval chain
The ordered set of stages a requisition must clear from raise to authorisation.
Glossary: approval chainApproval routing
The logic that decides which approver receives a requisition at each stage, and in what order.
Glossary: approval routingDelegation
Standing authority for one person to approve on another's behalf during an absence, recorded as acting for them.
Commitment
The budget reserved by an open purchase order — spend promised but not yet invoiced.
For the wider category, see approval workflow software and the approval workflow definition.
How purchase order thresholds set the chain
A threshold is an amount boundary that changes what a requisition has to clear. Because the chain is selected from the request's own data when it is raised, purchase order approval is conditional rather than fixed. The bands below are a common shape; the specific numbers matter far less than the rules for setting them.
| Amount band | Approvals required | Why the band exists |
|---|---|---|
| Under 500 | Cost centre owner | Low enough that a single budget holder's judgement is proportionate to the risk. |
| 500 – 5,000 | Cost centre owner, then procurement | Procurement checks whether a contract or preferred supplier already covers the purchase. |
| 5,000 – 25,000 | Cost centre owner, procurement, then finance | Finance reviews budget availability and cash timing at a level where the commitment is material. |
| Above 25,000 | The above, then any 2 of 3 signatories | Authority is held collectively, and a quorum stops the final stage depending on one person's calendar. |
| Capital expenditure | Separate chain regardless of amount | Capital spend is assessed against a different plan and often a different approval calendar. |
Bands must be contiguous and closed
A requisition for exactly 5,000 has to land in one row and only one row, and a gap between bands is a request with no chain. This sounds obvious and is the most common configuration error, because bands are usually written as "up to" and "over" by different people at different times.
Split requisitions are the failure mode to design against
Where a threshold adds a stage, there is an incentive to raise two requisitions just below the boundary instead of one above it. This is rarely deliberate misconduct and usually just someone avoiding a slow chain, which makes it a process problem rather than a compliance one. Detect it by looking for multiple requisitions to the same supplier from the same cost centre within a short window, and treat a slow upper band as the underlying cause worth fixing.
Amount is not the only useful basis
Supplier status, spend category and contract coverage all change how much scrutiny a requisition warrants. A 900 purchase from a new, unvetted supplier deserves more attention than a 9,000 purchase against an existing framework agreement. Routing on category also puts the right specialist in the chain — IT for software, facilities for premises work — without lengthening every chain to include them.
Keep the number of bands small
Each additional band multiplies the routing paths that need testing and maintaining. Three or four covers most organisations, with capital expenditure handled as a separate chain rather than as another band.
Delegation and keeping the chain moving
Purchase order approval is unusually sensitive to a single unavailable approver, because the work waiting on the purchase is blocked too. A requisition that stalls for a week does not just age — it delays a project, a repair, or a hire. Delegation, timeouts and escalation are the three mechanisms that keep that from happening, and they do different jobs.
Someone acts on their behalf
A named delegate holds standing authority to approve for an approver during a defined absence. The decision is recorded as the delegate acting for the original approver, so the audit trail shows both. Delegation is planned — it is set before the absence, not triggered by a delay.
- Set in advance, with a start and end date
- Both parties recorded on the decision
- Delegate's own authority limit still applies
The stage stops waiting
A timeout defines how long a stage waits before it does something else. It is the safety net for absences nobody planned for. Decide what the timeout does rather than accepting a default: escalating is almost always right, and auto-approving removes exactly the control the stage was added to provide.
- Measured in working days, not calendar days
- Logged as an event in its own right
- Never auto-approve above the lowest band
Authority moves up
On timeout the request moves to the approver's manager, who holds at least equivalent authority. This keeps the control intact while removing the blockage. Escalation should notify the original approver too, so the bypass is visible rather than silent.
- Target resolved from the directory, not named
- Original approver notified of the bypass
- Repeated escalations are a signal worth reporting
Delegation limits are part of the design
A delegate does not automatically inherit the full authority of the person they cover. Deciding this explicitly matters most at the top band: if a signatory's delegate can approve at the same ceiling, the quorum that band was built around can be satisfied by substitutes. Cap delegated authority, or exclude the top band from delegation and rely on the quorum instead.
Separation of duties survives delegation
The requester must not appear in their own chain, and that has to hold when a delegate is substituted in. Delegation loops — where an approver's delegate is the person who raised the requisition — are the common version of this and need catching at routing time rather than in review.
The mechanics of ordering, quorum and conditional routing are the same across approval processes, so the depth lives on the multi-level approval workflow page, with the concepts in the multi-level approval, sequential approval and parallel approval definitions.
What happens when the requisition is approved
Approval is the point at which an internal request becomes an external commitment. Everything the rest of the organisation needs from the purchase order has to be created here, because after this the supplier is involved and changes cost time.
Issue a numbered order the supplier can quote back
The purchase order number is the reference that ties the requisition, the supplier's invoice and the goods receipt together. Issuing it automatically on final approval — rather than someone creating it afterwards — is what makes later matching possible. If the number is generated by hand, invoices arrive quoting numbers that do not exist yet.
Commit the budget, don't just record the approval
An approved purchase order reserves money that has not been spent. Without a commitment posted against the budget, the next requisition is assessed against a balance that looks healthier than it is, and two purchases can each be approved against the same unencumbered funds. Committing at PO issue and releasing on invoice keeps the available balance honest.
Make the order available for matching
Accounts payable needs the purchase order in the accounting system before the invoice arrives, with line items, quantities, prices and the tolerance the match should allow. This is the handoff that lets a matched invoice clear without a second approval, which is where most of the downstream saving comes from. See invoice approval workflow for the receiving end.
Track receipt against the order
An open purchase order stays open until what was ordered has arrived. Recording receipt against the order — fully or partially — is what enables three-way matching and what makes purchase order tracking meaningful rather than a list of orders with no known state. Partial receipts are normal and need to be representable, not treated as an error.
Close orders deliberately
Orders that are received and invoiced should close, and orders that were never fulfilled should be cancelled rather than left open. Stale open orders hold commitments against budgets indefinitely, which slowly makes the available balance meaningless — the same problem as not committing at all, arrived at from the other direction.
The cases that stall purchase order approval
Straightforward requisitions inside budget clear quickly. These are the ones that consume procurement's time, and the ones worth designing for rather than handling ad hoc.
The purchase was already made without a PO
Route retrospective requests through a distinct chain that requires the approver above the normal band, and report the volume rather than hiding it. After-the-fact purchase orders defeat the control entirely, because the commitment exists before the approval. Refusing them outright pushes the spend off-system instead of eliminating it. Making them visible and slightly harder to obtain is what reduces them, and a rising count usually indicates the standard chain is too slow rather than that people are careless.
The approver is on leave and the work is blocked
Set a delegate in advance, and a timeout with escalation for the absences nobody planned. Delegation handles the known absence; escalation handles the unknown one. Both should notify the original approver so a bypass is visible. Measure how often escalation fires — a stage that escalates regularly has an authority assigned to someone who is not available often enough to hold it.
The delivered goods do not match the order
Set a tolerance by value and by proportion, auto-clear inside it, and route anything outside it to whoever raised the requisition. The requester knows whether a partial delivery or substitution was expected, and finance does not. Partial receipt should be a normal recorded state rather than an exception, since orders arriving in stages is ordinary in most categories.
The requisition needs changing after approval
Define which fields are material, and re-approve when one of them changes — particularly if the change crosses a threshold. An increase in quantity or price means the approvals already given no longer cover what is being committed, and if the new total crosses a band the chain itself has changed. Immaterial edits such as a corrected description should not reset anything. Without this rule a requisition can be approved at one value and ordered at another.
The requester is also an approver in the chain
Detect the collision at routing time and substitute the next authority up. Cost centre owners raise their own purchases routinely, so this is normal traffic rather than a rare edge case. Dropping the stage silently reduces the number of approvals on exactly the requisitions where separation of duties matters most. The same check should catch delegation loops.
The budget will not carry the purchase
Check available budget net of existing commitments at raise, and show the approver the position rather than only the amount. Checking the balance without deducting open purchase orders is how two requisitions get approved against the same funds. An approver deciding on a 12,000 request should see what remains after commitments, not the headline budget figure.
What to look for in purchase approval software
The category spans procurement suites, spend management platforms, ERP purchasing modules and general workflow tools. Rather than comparing feature lists, these are the questions that tend to separate them once an implementation is underway.
Conditional routing depth
Can the chain be selected from amount, category, supplier status and contract coverage together, or only amount?
Delegation with limits
Can a delegate be set in advance with dates, a capped authority, and both parties recorded on the decision?
Budget commitment
Does an approved order commit against budget, so the next requisition sees the true available balance?
Receipt and matching
Can partial receipts be recorded, and does the order reach AP with tolerances for two- and three-way matching?
Accounting write-back
Does the approved order write into your accounting system, or export a file someone re-keys?
Audit trail completeness
Are delegated decisions, timeout escalations, overrides and post-approval changes all logged as events?
The pricing model deserves the same scrutiny as the features. Per-transaction and per-workflow-run pricing is common in this category, which means the cost of the process rises with the number of purchase orders — the opposite of what automating it is meant to achieve. Model the bill at two or three times your current volume before committing.
Where manual purchase order approval comes apart
Purchase order approval usually starts as a request form, an email to a manager and a spreadsheet of numbers issued. It holds while volume is low and one person keeps the sheet.
Teams graduating from brittle scripts and shared sheets recognise all three of these. None announce themselves — each surfaces as a purchase that went ahead without anyone deciding it should.
Commitments are invisible
The budget report shows what has been invoiced, not what has been ordered. Two requisitions get approved against the same remaining funds, and the overspend appears weeks later when both invoices land.
The chain stops at one inbox
An approver on leave blocks every requisition routed to them, and the work waiting behind those purchases stops too. The workaround becomes buying first and raising the order afterwards.
Invoices arrive with no order to match
Numbers are issued by hand, so suppliers quote references that do not exist or none at all. Every invoice then needs a full approval, and the saving the purchase order was meant to create never materialises.
Purchase order approvals for teams working in Google Workspace
The criteria above apply to any tool in this category, including our own. Four things distinguish how Zenphi handles purchase order approval.
We build Zenphi natively for Google Workspace, so the process runs where the team already works — requisitions raised in Google Forms, approvals answered in Gmail or Google Chat, threshold and delegation tables maintained in Google Sheets by the finance and procurement owners themselves, and supporting documents in Drive. Approvers and delegates resolve from the Google Directory at run time, so the chain survives a reorganisation.
Native to the Google tools in use
Docs, Sheets, Forms, Gmail, Drive and Chat are first-class rather than reached through a generic connector. Procurement can maintain the approval matrix and delegation table in a Sheet the workflow reads directly.
No per-run or per-transaction pricing
Cost does not scale with the number of purchase orders or with how often a workflow runs, so raising more requisitions does not raise the bill for the process itself.
AI agents inside the platform
Zenphi lets teams choose AI agents across three providers — Gemini, OpenAI, and Claude — and use them within the workflow to extract data from quotes and supplier documents, summarise supporting material for approvers, and classify requisitions for routing.
First-class accounting actions
QuickBooks, Xero and other accounting and finance tools are supported as first-class actions, so an approved order writes back without a custom integration project.
Related approval processes
Thresholds, delegation and routing work the same way across finance and procurement. What changes is the document and what the chain commits to.
Approval workflow software
The category overview: evaluation criteria, routing mechanics and how approval tools differ from one another.
Read more →Invoice approval workflow
The receiving end of the purchase order: three-way matching, tolerances, and why a matched invoice can clear without a second approval.
Read more →Multi-level approval workflow
Sequential, parallel and conditional routing in depth, with quorum rules and the hard cases.
Read more →Expense approval workflow
Shallow chains at high volume, where policy checks and auto-approval rules matter more than approval depth.
Read more →Document approval workflow
Drive-native routing with automatic locking during review and approval bound to a specific revision.
Read more →Google Forms approval workflow
Form submissions as the entry point to a chain — the usual intake route for a requisition.
Read more →Purchase order approval — common questions
Settle your bands and delegation rules first
Approval bands, delegation limits and what happens on timeout are the decisions worth making before anything is built. Talk to our automation experts to get an advice on purchase approval workflows best practices. Or compare notes with procurement and finance teams running on Google Workspace and using Zenphi to automate their processes.