The approver's path: approve, reject, delegate
The approver is the person who decides whether your customer keeps using the shop. They are usually busy, usually not the person who chose the article, and almost always deciding from a phone. Everything below is shaped by that.
order_approval_limit. Set both before
you test anything — see Buyer spend limits.The queue
Every purchase request waiting on this person is one open decision in their queue. What matters is what it shows without opening anything:
- Who asked, and what for — the requester and the line summary.
- Value, and against which cost centre — the two numbers the decision turns on.
- What is left on that cost centre — the reason they can decide without phoning the controller.
- How long it has been waiting — the column that gets an approver to act today rather than Thursday.
A queue that forces the approver to open each request to learn the value is a queue that gets processed once a week.
Notification
The approver is emailed when a decision opens on them. Two things to get right with the customer before go-live, because both cause abandoned queues:
- The address. Approvals go to the person, not to a shared
einkauf@mailbox. A decision that lands in a group inbox is nobody's. - The frequency. An approver on a busy cost centre gets several a day. If that becomes noise they stop reading, and the control is gone. That is a signal the threshold is too low, not that the emails are wrong.
sendEmail rules are separate from this: they notify somebody who is not being
asked to decide — a controller who wants to know about overruns without being on
the critical path.
The decision
Three outcomes, and the difference between them matters.
Approve
The decision is settled. If it was the last one outstanding, the order is created from the request and the held budget becomes real consumption. If other decisions are still open — a second band, or a parallel approver — nothing else happens yet.
Nobody sees an order before the last signature. An approver who asks "has it been ordered?" after approving a €12,000 request that also needs the Geschäftsführung is asking a fair question, and the answer is no. Their queue should say so.
Reject
The request closes. The held budget is released immediately. The buyer is told.
Insist on a reason. A rejection without one produces an identical request within the hour and then a phone call to your Innendienst. In B2B a rejection is almost never "no" — it is "not this quantity", "not this quarter", "not from this supplier". The reason is what turns a rejection into a corrected order rather than a lost one.
A rejection by any approver ends the request, including a parallel one. There is no point asking the second person about something the first has refused.
Approve with changes
An approver who wants three of something rather than five changes the request rather than rejecting it.
Be precise with customers about what follows: a change re-runs the evaluation. The value moves, the budget reservation is adjusted, and the rules are applied again. A reduction may drop the request under a threshold and clear it outright. An increase may pull in a band that was not previously involved, and decisions already given do not carry over to a materially larger request — somebody who signed for €900 has not signed for €9,000.
Practical guidance for the customer's approvers: reductions, yes; increases, no. If it needs to grow, reject it with the reason and let the buyer raise the correct request.
Delegate
Two mechanisms, and they are not interchangeable.
| Deputy | Escalation | |
|---|---|---|
| Set up | On the cost centre, in advance | A waiting period on the rule |
| Triggered by | The deputy acting | Elapsed time |
| Decision recorded as | The deputy's own name | The person it moved to |
| Use it for | Holidays, illness, permanent workload split | The backstop when nobody acted |
Both record the actual decider. Neither is a shared login, and that is the entire audit case for having them.
Comments
An approver's comment is part of the record. Encourage the customer to use it for the thing that is not in the numbers: approved against the November budget, not December, only because the machine is down, last time at this price.
A year later, when their auditor asks about one specific approval, this is what answers the question.
What to check
- Approve a two-band request as the first approver only. No order should exist yet, and the second approver's queue should now show it.
- Reject one and watch the budget. The held amount should return immediately, and the ledger should show both the hold and its release.
- Have a deputy decide on the owner's behalf. The record should carry the deputy's name.
Next
- Reading the budget ledger — what the decision did to the money.
- Approvals that get stuck — when nobody decides.