How to Design a Purchase Order Approval Workflow People Actually Follow
Approval chains get bypassed when they are slow or unclear. A practical guide to thresholds, delegation of authority, escalation and segregation of duties.
Every organisation that has ever written a purchase order approval policy has also watched somebody buy something on a personal credit card because the policy was too slow. Approval workflows do not fail because people are dishonest. They fail because the workflow is slower than the need it is supposed to serve, and the workaround is always available.
Why approval chains get bypassed
Before designing anything, it is worth being honest about the failure modes. In practice there are four:
- It is too slow. A three step chain where each approver takes two days means a week for a box of cables.
- Nobody knows who is next. The request sits with a person who does not know it is waiting for them.
- The approver has no basis to decide. Asking a director to approve a line item with no budget context turns approval into a rubber stamp.
- There is a faster path. If a company card or an expense claim clears in a day, the purchase order process is competing with it and losing.
Purchases made outside the process are called maverick spend. The cost is not only the lost negotiating leverage. It is that finance discovers the commitment when the invoice arrives, which is the worst possible moment.
A threshold based chain. The number of approvers scales with the value of the request, so small purchases are not held up behind the same queue as capital spend.
Start with delegation of authority, not with software
A delegation of authority matrix states who may commit the organisation to spend, up to what value, in which categories. It is a governance document, and the workflow is only an implementation of it. Writing the workflow first produces a chain that reflects the current org chart and breaks the moment somebody changes role.
A simple matrix looks like this:
| Value band | Approvers required | Target turnaround |
|---|
| Under 1,000 | Line manager | 1 working day |
| 1,000 to 25,000 | Line manager, then finance | 2 working days |
| 25,000 to 100,000 | Line manager, finance, CFO | 5 working days |
| Over 100,000 | As above, plus board or executive committee | Next scheduled meeting |
Two refinements are worth adding. Category overrides, so that anything touching personal data, legal commitments or headcount routes through the relevant owner regardless of value. And an aggregation rule, so that ten separate requests of 900 each cannot be used to stay under a 1,000 threshold.
Sequential or parallel
Sequential approval sends the request to one approver at a time. Parallel sends it to everyone at once. The right answer depends on whether the approvals are dependent.
- Use sequential when a later approver needs an earlier decision. Finance should not review something the requesting manager has not endorsed.
- Use parallel when approvers are assessing genuinely different things. A security review and a budget review do not need to wait for each other.
Most chains are made sequential by default and are slower than they need to be. If two approvers never reject for the same reason, they can run at the same time.
Design for absence from day one
The most common cause of a stalled purchase order is that an approver is on leave. This is not an edge case, it is a certainty, and it should be handled in the design rather than by somebody chasing on the day.
- Delegation. An approver can nominate a delegate for a date range. The audit trail records both the delegate and the original approver.
- Escalation on a timer. If a step is untouched after an agreed period, it moves up automatically. Escalation should be visible to the requester, not silent.
- Group steps rather than named individuals. Routing to "any finance approver" survives an org change. Routing to a named person does not.
Approval is a decision with a name attached to it. The audit trail should make clear who decided, on what basis, and when.
Segregation of duties
The point of an approval chain is that more than one person is involved. Three rules preserve that:
- Nobody approves their own request. If a request would route to its own requester, it must escalate instead.
- Approving and receiving should be different people where the value justifies it. One person who can order, receive and approve payment can create a purchase that never existed. Prompt, independent receipting also keeps your GRNI accrual honest.
- Changes after approval re-trigger approval. If the quantity or value increases after sign off, the previous approval no longer covers it. Silent post approval edits are the most common way a control is defeated without anyone breaking a rule.
These rules matter most when they are enforced by the system rather than the policy document. A rule that depends on somebody remembering it is not a control.
Give approvers something to decide with
An approver looking at a description and a number will approve almost everything, because there is nothing there to reject on. Useful context includes the remaining budget for the relevant cost centre or project, the supplier and whether they are already approved, what the same item cost last time, and who requested it and why.
Checking commitment against remaining budget at the point of approval is the single highest value addition, because it converts approval from an opinion into a check against a number.
Emergency purchases
Every organisation needs a path for the case where production is down at 2am. If you do not design one, people will invent one, and the invented one leaves no audit trail. A workable emergency route has a named set of people who can invoke it, a hard value ceiling, and mandatory retrospective approval within a short window. The retrospective step is what keeps it from becoming the normal route.
Measure the workflow, not just the spend
Four numbers tell you whether the design is working:
| Metric | What it tells you |
|---|
| Median approval cycle time | Whether the process competes with the workarounds |
| Time waiting per approver | Which specific step is the bottleneck |
| Rejection rate by step | A step that never rejects is not adding control, only delay |
| Share of invoices with no purchase order | The most direct measure of maverick spend, and the invoices that cannot be three-way matched |
A step with a rejection rate near zero is the one to question first. Either it is genuinely unnecessary, or the approver has no basis on which to say no.
Common questions
How many approval steps should we have?
As few as the delegation of authority allows. Each step adds delay and diffuses responsibility. Two meaningful approvals generally beat four nominal ones.
Should approvals happen on the requisition or the purchase order?
Approve the requisition, which is the request to commit, and generate the purchase order from it once approved. Approving the purchase order means you have already produced a document that looks like a commitment to the supplier before anyone agreed to it.
Can approvers act from email?
Yes, and they will adopt the process far more readily if they can. The requirement is that the email action is authenticated with a single use token tied to that specific request, so that a forwarded message cannot approve anything.
What about recurring purchases?
Approve the contract or the blanket order once, for a value and a period, then release against it without re-approving each call off. Sending the same monthly service through a full chain twelve times a year teaches everyone to stop reading it.
The short version
Write the delegation of authority first, keep the chain as short as that document permits, run independent approvals in parallel, plan for absence with delegates and timed escalation, enforce segregation of duties in the system rather than in a policy, and give approvers budget context so the decision is real. Then measure cycle time, because the workflow that gets bypassed is almost always the slow one.