Approvals that get stuck
A stuck approval is not a cosmetic problem. It holds the customer's budget, stops a machine, and — the part that costs you — teaches their buyer to phone your Innendienst instead of using the shop.
Symptom to cause
| The customer says | Usually |
|---|---|
| "Nobody has looked at it for a week" | The approver is away and the cost centre has no deputy |
| "It went to the wrong person" | A cost centre's owner left and was never replaced |
| "I approved it and there is still no order" | A second band or a parallel approver is still open. Correct behaviour |
| "It says I have no budget, we have plenty" | Reservations. Open requests are holding money that is not spent |
| "It won't submit at all" | A prevent rule fired, or a line has no usable cost centre |
| "It keeps coming back to me" | The buyer is editing the request, which re-runs the evaluation each time |
| "The big one is stuck forever" | Every approver in the chain has a limit below the value. There is nowhere for it to go |
Requests with nowhere to go
The last row is the one that produces a request that can never be settled, and it is worth checking for deliberately rather than waiting for it.
It happens when every approver in the chain has an order_approval_limit below
the request's value. Each of them can see it and none of them may sign it. The
request sits, the budget stays held, and nothing in the system is technically
wrong.
Somebody must be unlimited. Leave the top approver's approval limit empty. Check this on every customer at go-live and again whenever the customer's management changes — it is a five-second check that prevents an unfixable queue.
The related case: a rule whose approver is the requester. Self-approval is not a routing failure, it is a segregation-of-duties failure, and it will be found by an auditor rather than by you. Check that no cost centre's owner is also its only buyer.
Budget exhausted
The commonest false alarm. The customer sees budget in their own figures and the shop says there is none.
Check in this order:
- Open reservations. Requests awaiting a decision hold budget. Settle or withdraw them and the money returns immediately.
- The period. A budget for the 2027 financial year has nothing to do with an order dated after it ends. Check the new period opened.
- The sequence. Where a cost centre has several budgets, the first is drained before the second. A report that reads only one of them is wrong.
- What they are comparing. Their number is booked invoices; this one is committed orders. See Reading the budget ledger.
If it really is exhausted, the fix is the customer's, not yours: they top the budget up, and the adjustment is recorded with their name on it.
Escalation and override
Escalation is the automatic path — a reminder after the configured wait, then the open decision moving to the next band's approver. It runs on time elapsed, so it handles the case where nobody is watching.
There is no override that turns a request into an order without a decision, and there should not be. Everything this area produces — the audit trail, the segregation of duties — depends on every order having a named decider behind it. What looks like an override is always one of three legitimate actions:
| Situation | Do this |
|---|---|
| Approver away, deputy exists | The deputy decides. Recorded under their name |
| Approver away, no deputy | Add a deputy on the cost centre. They can then decide |
| Approver has left the company | Change the cost centre's owner. Open decisions follow the role |
| The request is genuinely wrong | Withdraw it. The budget is released and the buyer raises a corrected one |
Reassign an approver
For a permanent change — somebody left, a department moved:
- Change the owner on the affected cost centres. Rules scoped to a cost centre route to its owner, so this moves everything at once.
- Where a rule names a person directly rather than the cost centre's owner, update the rule. This is why naming the owner is the better pattern.
- Add a deputy for the new owner immediately. A new owner with no deputy is the next stuck queue.
- Set the new owner's
order_approval_limitto match the authority they actually have. Inheriting a role does not inherit a signature. - Check what was already open. Decisions follow the cost centre's owner, so they should now be in the new person's queue — confirm rather than assume.
Prevention
Four checks, none of which take longer than a few minutes:
- Every cost centre has an owner and at least one deputy. The single highest value check in this area.
- Somebody at the top has no approval ceiling.
- The escalation wait is set, and short enough to matter. Five working days is too long for a customer whose machines stop.
- Fewer than about one order in five needs approval. Above that, the thresholds are too low and the approvers will stop reading — see Approval models.
What to check
- Submit a request against a cost centre whose owner is away and confirm the deputy sees it.
- Look at the oldest open decision across the customer's queue. If anything is older than the escalation wait, escalation is not configured.
- Withdraw one open request and confirm the budget returns in the ledger.
Next
- Procurement data hygiene — the routine that prevents most of this.
- The approver's path — deputies and escalation in use.