Blog · Approvals and authority
Sequential vs parallel approvals
Sequential approval sends a purchase request to one approver after another, in a fixed order. Parallel approval sends it to several people at the same time and waits for all of them. Use a sequence when the question is “who has the authority to spend this much?” and parallel sign-offs when different functions each need to check something different. Most small teams need neither in its pure form: they need a chain that stops at the first approver whose limit covers the total.
The two models, drawn in words
Picture sequential approval as a single line of boxes running left to right. The request starts with the requester, moves to the first approver, and only when that person approves does it move to the next box. A rejection anywhere stops it. At any moment exactly one person is holding the request.
Picture parallel approval as a fan. The request leaves the requester and splits into several arrows at once, one to each approver. The arrows meet again at a single point, and the request only passes that point when every arrow has come back approved. Several people hold the request at the same time, and none of them waits for another.
Both models answer the question “may we spend this?”, but they share the work out differently. A sequence asks the same question at rising levels of authority. A fan asks different questions of different people.
Where each one fits
Sequential approval fits authority chains. A team lead can sign off small purchases, a department head larger ones, and a director anything above that. Each step is a more senior person with a bigger limit, so it makes sense for the request to climb the ladder in order and for each rung to see what the rung below decided.
Parallel approval fits sign-offs from different functions. A new piece of lifting equipment may need the safety officer to confirm it meets the site’s rules and the budget holder to confirm the money. A software subscription may need IT to check how it handles data while finance checks the cost. Those checks don’t depend on each other, so there is no reason to queue them.
- A request that only needs someone senior enough to approve the amount: sequential.
- A request that needs two or more specialists to each confirm their own part: parallel.
- A request that needs both: a short parallel review by the specialists, then the authority chain for the money.
What each one costs
A sequence is slower per step. If three people are on the chain and each takes a day, the request takes three days. Its strength is context: each approver sees the previous decision and any note left with it, so the director knows the department head has already looked at the quote. Responsibility is plain too, because the last person to approve is the one whose authority covered the amount.
Parallel approval is faster, because the slowest approver sets the pace rather than the sum of all of them. The cost is that nobody sees anyone else’s reasoning while deciding, and it becomes easy to approve past a limit nobody intended. If two managers can each sign off up to 5,000 and a 12,000 request goes to both at once, two approvals come back, yet nobody with authority for 12,000 ever looked at it. Some set-ups make it worse by treating the first approval in a fan as enough.
The rule of thumb: parallel sign-offs are for checks, not for authority. Authority for an amount should rest with one named person whose limit covers it. See approval limits and the delegation of authority for how to write those limits down.
The hybrid most small teams need
A pure sequence has a flaw of its own. If every request climbs the whole chain, a 200 purchase waits for the director as well as the team lead, and senior people spend their day approving stationery. The fix is a sequence that stops early.
Give each person on the chain a limit. The request goes to the first approver; if the total is within their limit, their approval is final and the order can go out. If not, it moves to the next approver, and so on, stopping at the first one whose limit covers the total. Small purchases are decided close to the requester, large ones still reach the people who should see them, and each request names exactly one person who approved the amount.
Two details make this work in practice. Compare limits against the total excluding tax, so the same purchase routes the same way whatever its tax treatment. And decide in advance what happens when the total is above every limit on the chain, so those requests go to a named person rather than nowhere. How to set approval limits walks through choosing the numbers.
When an approver is away
Absence is where approval set-ups usually fail, so plan for it in whichever model you use.
In a sequence, an absent approver blocks everything behind them. The usual answers are to skip them, so the request goes on to the next person on the chain, or to name a colleague to cover who decides with the absent person’s limit. The cover should never get a higher limit than the person they replace, and should never be the requester.
In a parallel set-up, one absent approver holds up the whole fan, because the request waits for every arrow. Name a deputy for each function, for example a second person who can give the safety sign-off. Don’t quietly drop the absent check, or the fan stops checking what it was set up to check.
Either way, record who decided and on whose behalf. That record matters for the controls described in segregation of duties in purchasing.
Side by side
The three approaches compared for a small purchasing team.
| Sequential | Parallel | Chain that stops at a covering limit | |
|---|---|---|---|
| Suits | Authority by amount | Checks from different functions | Authority by amount, without needless steps |
| Speed | Sum of every step | The slowest approver | Only the steps the amount needs |
| Context | Each approver sees earlier decisions | Approvers decide alone | Each approver sees earlier decisions |
| Main risk | Senior people approve small purchases | Approval past a limit nobody intended | Totals above every limit need a named fallback |
| When someone is away | Skip them or name a cover | Name a deputy for each function | Skip them or name a cover with the same limit |
Questions
What is the difference between sequential and parallel approval?
Sequential approval sends a request to approvers one after another, in a set order, and each sees the previous decision. Parallel approval sends it to several approvers at once and waits until all of them approve.
Is parallel approval faster?
Usually, because the request waits only for the slowest approver rather than for every approver in turn. It suits amounts less well, since nobody in the fan may have the authority for the whole total.
How many approvers should a purchase request need?
For most small teams, one: the first person whose limit covers the total. Add a second step only where a different function genuinely needs to check something, such as safety or IT.
What happens if the total is above every approver’s limit?
Decide that in advance. The common answer is a named fallback, such as a director or owner, who decides anything the chain can’t cover, so the request is never left waiting for nobody.