Ask a finance leader where the time goes in any given process and the answer is almost never the work itself. It is the waiting. An invoice is captured in nine seconds and then sits for six days waiting for someone to click approve. A purchase requisition moves through four approvers in a week, three of whom add nothing beyond a signature. A hiring requisition dies in a director's inbox because the notification arrived on a Friday afternoon.
Approval workflow automation is not primarily about removing approvers. It is about making the approval step deterministic — a known number of hops, a known time budget, a known escalation path, and a record of what happened. Done well, it compresses cycle time by half or better without weakening a single control. Done badly, it takes a slow human process and makes it a slow automated process with worse visibility.
This guide is deliberately narrow. It covers how to design the chain, set thresholds, handle absence and escalation, define service levels, and avoid the specific failure modes that show up in production three months after go-live.
Start by Counting Your Hops
Before configuring anything, map the current chain for each request type and count the approvers. Then, for each one, ask a single question: in the last twelve months, how many times did this person reject or modify a request?
The answer is frequently zero. Approvers who have never rejected anything are not controls; they are notification recipients who have been given a button. They add days of latency and no risk reduction. In most organizations, at least one layer of the chain can be converted from an approval to a notification without any change to the actual control environment.
A defensible chain has a reason for every hop:
- Budget authority. Someone who owns the money being spent.
- Policy check. Someone verifying the request complies with a rule a system cannot evaluate.
- Technical or legal review. Someone with domain knowledge the requester lacks.
- Segregation of duties. Someone who is structurally not the requester, for fraud control.
If a hop does not map to one of these, it is either a notification or a habit. Removing it is the single highest-leverage change available, and it costs nothing.
Threshold Design
Thresholds determine how many hops a given request actually takes. The common mistake is setting one company-wide number, usually a round figure chosen in a meeting years ago and never revisited. The result is either an approval queue clogged with $80 software renewals or a $40,000 commitment that one manager approved alone.
Better threshold design works from the distribution of actual transactions. Pull twelve months of history, plot the amounts, and set bands so that the large majority of volume clears with minimal approval and the large majority of value receives real scrutiny. In most spend datasets, something close to 80% of transactions account for well under 20% of value — which means the bulk of approval labor is being spent on the amounts that matter least.
A workable pattern for spend approvals:
| Band | Approval requirement | Typical share of volume |
|---|---|---|
| Below the noise floor | Auto-approve if in policy and matched | 50-65% |
| Routine | Single approver: cost center owner | 25-35% |
| Material | Cost center owner plus finance | 5-15% |
| Strategic | Adds executive or committee | Under 3% |
Two refinements make this considerably stronger. First, make thresholds conditional rather than absolute — a $5,000 invoice against an approved purchase order with a clean three-way match carries less risk than a $900 unbudgeted expense with no receipt, and the routing should reflect that. Second, make the auto-approve band contingent on validation, not just on amount. Automatic approval should mean "every check passed and the amount is small," never "the amount is small."
The same logic applies to non-financial approvals. A time-off request that leaves adequate coverage, falls within accrued balance, and is submitted with notice does not need a human decision at all. One that creates a coverage gap during a blackout period does.
Escalation and the Absence Problem
The most common cause of stalled approvals is not disagreement. It is absence. Someone is on vacation, in back-to-back meetings, on leave, or has left the company entirely and their queue is still receiving items.
Three mechanisms solve this, and a production-grade workflow needs all three.
Time-based escalation. If an item is not actioned within its service level, it moves — either up to the approver's manager or across to a designated peer. This should be automatic and unconditional. The one design choice that matters is whether escalation transfers authority or merely adds a second recipient; for cycle-time purposes, transfer is almost always correct.
Planned delegation. Approvers set an out-of-office delegate with a date range, and the workflow honors it without anyone re-routing manually. Critically, delegated approvals must be logged as delegated. An audit trail showing the vacationing director approved an invoice from a beach is a finding waiting to happen.
Orphan detection. When someone leaves, their pending queue needs an owner within hours, not at the next quarterly review. Tie the workflow's approver directory to the HR system of record so that a termination event triggers reassignment automatically. This is one of the underrated benefits of running approvals on the same platform as HR management rather than in a standalone tool with a manually maintained user list.
Setting Service Levels That Mean Something
An SLA is only useful if it is differentiated, measured, and enforced.
Differentiated. A uniform 48-hour SLA across all request types is a signal that no one thought about it. A payment run cutoff and a training request have different urgency profiles. Set the clock against the business consequence: early payment discount deadlines, statutory filing dates, candidate offer windows, project start dates.
Measured on the right statistic. Average approval time hides everything that matters. Track the median and the 90th percentile. Averages look fine while a tail of items sits for three weeks; the 90th percentile is where the pain actually is, and it is the number that correlates with the complaints you hear.
Enforced through visibility. Publish approval performance by approver and by department. This is uncomfortable for exactly one review cycle and then it works. The combination of a visible dashboard and automatic escalation resolves the majority of chronic bottlenecks without a single difficult conversation.
Instrument the workflow to capture four timestamps per hop: created, assigned, first viewed, actioned. The gap between assigned and first viewed tells you whether notifications are working. The gap between first viewed and actioned tells you whether the approver has enough context to decide. These two numbers diagnose almost every approval problem, and they are why real-time reporting on process metrics is more useful than a monthly summary.
Failure Modes to Design Against
Rubber-stamping. When approval requires no thought, approvers stop thinking. Bulk-approve buttons and mobile one-tap approvals make this worse. The countermeasure is not to remove convenience but to reserve it for low-risk items and force a deliberate interaction — a required justification field, a comparison against prior spend — for anything material.
Notification fatigue. An approver receiving thirty emails a day from the workflow will start filtering them. Consolidate into a digest for routine items, reserve real-time alerts for items with a live deadline, and let approvers act from wherever they already work.
Circular and self-approval. Under reorganizations, chains occasionally route an item back to its own requester, or to someone who reports to the requester. Validate the chain at configuration time and again at runtime, and block any path where requester and approver are the same person or in a direct reporting line.
Missing context at the decision point. An approver looking at a line item with no vendor history, no budget position, and no prior comparable is guessing. Every approval screen should carry the three or four facts a reasonable person needs: what it is, what it costs relative to budget and to history, what happens if it is rejected, and who has already reviewed it.
Silent rule drift. Thresholds and routing rules get edited over time, often informally. Version every rule change, record who made it, and review the full rule set on a fixed cadence — the same discipline described in the approach to HR audit readiness applies equally to financial approval logic.
Rolling It Out
Pick one request type with high volume and low political weight — expense reports and time-off requests are the usual choices. Model the existing chain, remove the hops that have never rejected anything, set thresholds from actual transaction data rather than from opinion, and run it in parallel for two weeks so you have a real baseline to compare against.
Then measure. If median cycle time has not dropped by at least half, the problem is almost certainly chain length or notification design rather than the technology. Fix that before adding the second process. Teams that get this sequence right find that workflow automation compounds quickly, because every subsequent process reuses the same escalation, delegation, and SLA infrastructure rather than rebuilding it.
