What Happens to Approvals When the Approver Is on Leave? Designing Delegation and Fallback

Chirashree Dan Marketing Team
| | 22 min read
Finance and operations team reviewing a delegated approval queue on screen while the assigned approver is away

TL;DR: Approval queues in multi-entity utility and infrastructure groups stall the moment an approver is unavailable, and the highest-value transactions stall first because delegation is overwhelmingly requested by executives. A complete design needs four distinct mechanisms — user-level time-boxed delegation, standing fallback approvers, timeout-based auto-escalation and a dual-controlled administrator override — plus a hierarchy rule that blocks downward delegation. Teams that implement all four typically cut stalled-item counts by 60-80% and recover 2-5 days of month-end close time, while eliminating the credential-sharing workaround that quietly destroys the audit trail.

Introduction

In a multi-entity energy or utilities group, an approval queue is a single point of failure with a human name attached to it. A regional finance director signs off cash advances for six generation sites. An assistant vice president approves every travel request above a threshold across three business units. When either of them boards a plane, goes into a two-day regulatory hearing, or takes emergency leave, the queue stops — and it stops at exactly the transactions that matter most, because delegation requests come overwhelmingly from executives whose approval limits cover the largest amounts.

Finance teams in asset-heavy, multi-entity groups consistently report the same pattern. The legacy expense portal supports a form of delegation: before going on planned leave, a user nominates someone to act for them. That model handles the predictable half of the problem and breaks completely on the other half. Emergency leave, an unplanned site incident, or a medical absence means the approver is already gone and never set the delegation. Nobody can act, the administrator has no clean way to intervene, and the queue simply accumulates until the person returns.

Governance expectations for delegated authority are covered in AICPA audit and assurance guidance, Deloitte’s audit services and PwC’s audit and assurance practice.

What Is Approval Delegation, and How Does It Differ From Fallback, Escalation and Policy Reconfiguration?

Approval delegation is a per-user, time-boxed transfer of approval authority from one named approver to one named delegate. Every transaction routed to the delegator inside the effective window goes to the delegate instead, and authority reverts automatically when the window closes. It changes nothing for any other user and nothing about the policy itself.

Why the Distinction Is Not Academic

Delegation is an act. Policy is a design. Systems that expose the two through the same screen guarantee the mistake will be made.

The four mechanisms are distinguished as follows.

MechanismTriggerScopeDurationWho sets it
DelegationApprover declares an absence windowOne named delegator to one named delegateFixed start and end, auto-revertsThe approver, self-service
Fallback approverPrimary is flagged unavailable or no delegation existsStanding alternate per role or per policy nodePermanent configuration, conditional useProcess owner
Auto-escalationItem untouched beyond a timeoutNext approver up the chainPer item, on breachProcess owner, per document type
Policy reconfigurationChange to the control design itselfEvery user and transaction on that policyPermanentGovernance body, with change control

What Does a Stalled Approval Actually Cost When an Approver Goes on Leave?

A stalled approval costs far more than the delay itself, because approval queues sit on the critical path of cash movement, month-end close and employee goodwill. In multi-entity groups, a single unavailable executive approver typically adds 3-7 business days to affected transactions, and the affected transactions are disproportionately high-value.

The direct costs are measurable. A travel request that misses a fare window costs 15-40% more when rebooked. A cash advance that clears three days late means a field crew arrives at a remote site without funds. An expense reimbursement delayed past payroll cutoff pushes an employee’s out-of-pocket recovery into the following month.

The Control Cost Nobody Reports

The table below quantifies the typical impact profile for a mid-sized multi-entity group processing 3,000-6,000 expense and advance transactions per month.

Consequence of a stalled queueTypical magnitudeWhere it shows up
Added cycle time per affected item3-7 business daysApproval SLA reporting
Travel rebooking premium15-40% of fareTravel spend variance
Month-end close slippage1-3 daysClose calendar
Delayed employee reimbursement2-6 weeks out of pocketEngagement surveys, helpdesk tickets
Forfeited early-payment discounts0.5-2% of eligible spendAP discount capture rate
Credential sharing incidents5-15% of approvers during peak leaveRarely reported until audit

How Should You Design Differently for Planned Absence Versus Unplanned Absence?

Planned and unplanned absence are two different design problems and need two different mechanisms. Planned absence is solved by user-level self-service delegation with explicit start and end dates. Unplanned absence cannot be solved by delegation at all, because the person who would have set it is already gone — it requires an administrator override and a timeout-based escalation net.

Treating both with the same tool is why legacy portals fail. They implement the planned case well and leave the unplanned case to email chains and ad-hoc IT tickets.

The Unplanned Path

The unplanned-absence path requires a different set of system behaviours, summarised here.

Design dimensionPlanned absenceUnplanned absence
Primary mechanismSelf-service delegationAdministrator override plus auto-escalation
Who initiatesThe approverSystem administrator or the timeout rule
Applies to in-flight itemsItems routed after start datetimeMust apply retroactively to items already queued
Notification priorityAdvance notice to delegateImmediate alert to delegate, delegator and requester
Typical coverage achieved70-85% of absence daysThe remaining 15-30%
Audit sensitivityModerateHigh — every override needs justification

What Fields Belong in a Well-Designed Delegation Object?

A delegation object needs nine attributes to be both usable and auditable: delegator, one named delegate, scope, effective start, effective end, auto-revert flag, reason code, creator, and creation timestamp. Anything less produces either a blunt instrument or an unauditable one.

Scope is the field most often omitted and the one that matters most in multi-entity environments. An approver in a group with dozens of legal entities rarely wants to hand over everything. Scope should be expressible along three axes: document type (expense report, cash advance, travel request, payment release), entity or business unit, and amount band.

delegation_id      : DLG-2026-004417
delegator          : approver_id 8842 (grade: AVP)
delegate           : approver_id 8811 (grade: AVP)   # equal or higher only
scope_doc_types    : [expense_report, cash_advance]
scope_entities     : [BU-North, BU-Central]
scope_amount_band  : 0 - 50000 USD
effective_start    : 2026-09-01T00:00+08:00
effective_end      : 2026-09-12T23:59+08:00
auto_revert        : true
authority_source   : delegator_limit
reason_code        : PLANNED_LEAVE
created_by         : approver_id 8842 (self-service)
created_at         : 2026-08-19T09:41+08:00

One Delegate, Not a Pool

Map delegation one-to-one. A single named delegate gives unambiguous accountability and a clean audit trail. Pooled delegation, where any member of a group may act, makes it materially harder to evidence who held authority on a given date and increases the odds that an item sits untouched because each pool member assumes another will take it.

How Do You Enforce Hierarchy Rules and Prevent Self-Approval in Delegation Chains?

The core hierarchy rule is that authority may never be delegated downward. An assistant vice president cannot delegate approval authority to a manager who sits below their grade, because doing so lets a transaction be approved by someone the delegation of authority framework never authorised for that amount. The rule must be enforced by system validation at the moment the delegation is created, not by a policy document.

Systems that rely on a written policy and a training deck will see the rule broken within a quarter. Systems that reject the delegation at creation with a clear message will not.

Closing the Self-Approval Loop

The following checks close the self-approval loop when delegation chains overlap.

Control ruleEnforced atFailure behaviour
No downward delegation by gradeDelegation creationReject with reason shown to user
Delegate must hold an active approver roleDelegation creationReject
Delegation window cannot exceed a maximum durationDelegation creationReject beyond configured cap, e.g. 90 days
Effective approver is not requester, preparer or beneficiaryApproval actionRoute to next independent approver
Chained delegation must not resolve to the originatorApproval actionBreak chain, route upward
Amount exceeds delegator’s limitApproval actionEscalate to the next authority band

How to Implement Approval Delegation and Fallback: A Step-by-Step Implementation Guide

The sequence below takes 60-90 days for a multi-entity group and can run alongside an existing travel and expense management rollout rather than after it.

  1. Map approver concentration risk. Extract twelve months of approval history and rank approvers by transaction value and volume. The top 5-10% of approvers usually gate 50-70% of value; those are the absences that will hurt.
  2. Define the delegation object. Specify the mandatory fields — delegator, single named delegate, scope by document type, entity and amount band, effective start and end, auto-revert flag, reason code, creator and timestamp.
  3. Codify hierarchy and authority-limit rules. Encode grades so downward delegation is rejected at creation, and decide explicitly whether the delegate acts under the delegator’s limit or their own. Document the decision in the delegation of authority framework.
  4. Build user-level self-service delegation. Give every approver a screen where they set a delegation in under 60 seconds without raising a ticket. Every transaction routed to them inside the window goes to the delegate.
  5. Configure automatic reversion. Authority returns to the original approver the instant the window expires, with no manual step and no residual routing.
  6. Configure administrator override with dual control. A named administrator role can add, amend or revoke a delegation at any time, including retroactive reassignment of queued items, with a second approver confirming the override and a mandatory justification.
  7. Add timeout-based auto-escalation. Set per-document-type timeouts — typically 48-72 business hours for routine expense reports, 24 hours for payment-critical or booking-window items — so untouched items move up the chain even when no delegation exists.
  8. Design the notification set. Notify the delegate on activation, the delegator on activation and expiry, the requester when the acting approver changes, and both parties on any override. Silence is what makes delegation feel unsafe.
  9. Pilot, measure and roll out. Run in one entity for 30-45 days, track the six metrics above, tune timeouts and scope defaults, then extend entity by entity. Groups running a shared multi-entity tenancy architecture can propagate the configuration centrally rather than rebuilding it per entity.

How Peakflo Handles Delegation and Fallback

Peakflo’s travel and expense module treats delegation as a time-boxed control object attached to a user, separate from the approval policy that governs everyone.

Pain point covered in this articlePeakflo capabilityWhat changes
Approvals stall the moment an approver is unavailableUser-level delegation with explicit start and end datesQueues keep moving through planned and unplanned absence
Emergency leave leaves no delegate in placeAdministrator override that reassigns in-flight itemsStranded executive approvals are resolved in minutes
Delegation implemented by editing the approval policyDelegation held separately from policy configurationThe control design stays intact for everyone else
Authority can drift downward through informal coverHierarchy rules preventing downward delegationAuthority limits are enforced by the system, not the policy PDF
No record of who approved under whose authorityFull audit trail of delegator, delegate, grantor and windowDelegated approvals are attributable and auditable

Delegation applies consistently across entities configured through Peakflo’s ERP integrations and extends to approvals in accounts payable and agentic spend management. Walk the approval model on the product tour or request a demo.


Our Verdict: Delegation Is a Control Object, Not a Convenience Feature

Treating delegation as a nice-to-have setting is what produces the credential-sharing problem, the permanently-edited approval policy, and the audit finding. Treated properly, it is a first-class control object with its own lifecycle, its own validation rules and its own audit trail — and building it that way costs very little more than building it badly. For wider operational context see Harvard Business Review’s operations coverage and AICPA internal control resources.

The decisive design choices are narrow: one named delegate rather than a pool, hierarchy enforcement in code rather than in a policy PDF, an administrator override that works retroactively, and a timeout net for the absences nobody declared. Groups that get those four right stop losing days to unavailable approvers without loosening a single control.

Best For

  • Multi-entity energy, utilities and infrastructure groups where executive approvers gate high-value transactions across many legal entities
  • Shared-services finance centres serving multiple business units from one team
  • Organisations with formal delegation of authority frameworks and regular internal audit testing
  • Teams already integrating an expense layer with Oracle, SAP or NetSuite through a governed ERP integration layer
  • Your organisation has fewer than 20 approvers and a flat hierarchy, where a single standing fallback approver per policy node is sufficient
  • Approval volume is low enough that absences are handled conversationally without material delay
  • You have not yet defined authority limits at all — fix the approval matrix first, then layer delegation on top

Conclusion

The question of what happens to approvals when the approver is on leave has a bad default answer in most enterprise finance stacks: nothing happens, and the queue grows. Legacy portals handle the planned case, ignore the unplanned one, and push finance teams toward workarounds that are worse than the delay they solve.

The fix is not more approvers and it is not a policy edit. It is a properly modelled delegation object with explicit dates and scope, hierarchy rules enforced in code, a dual-controlled administrator override that can reach in-flight items, an escalation net for the absences nobody declared, and an audit trail that shows who approved as whom. Groups that implement the full set typically cut stalled-item counts by 60-80% and recover 2-5 days of close time.

If you are designing this layer now, start with concentration risk. Find the ten approvers whose absence costs the most, and build the delegation model that covers them first. To see how this works against a live approval queue with real-time budget validation on expense requests, request a demo.

Frequently Asked Questions

What is approval delegation in a finance workflow?

Approval delegation is a per-user, time-boxed transfer of approval authority from one named approver to one named delegate for a defined window.

What is the difference between delegation and a fallback approver?

Delegation is set deliberately by the approver for a known date range. A fallback approver is a standing, pre-configured alternate who receives an item only when a trigger condition fires, such as the primary.

Why should you never solve an approver absence by editing the approval policy?

Editing the approval policy to add an extra approver is a structural change that alters the control design for every user, entity and transaction routed through that policy, permanently and retroactively in behaviour.

Can an approver delegate authority downward in the hierarchy?

No. A well-designed system blocks downward delegation, so an assistant vice president cannot delegate approval authority to a manager who sits below their grade.

Does the delegate approve under their own authority limit or the delegator’s?

The delegate should approve under the delegator’s authority limit for the delegated scope only, with the transaction recorded as approved by the delegate acting for the delegator.

What happens to approvals when someone takes emergency leave and set no delegation?

This is why systems need two safety nets beyond self-service delegation: an administrator override that can add or reassign a delegate at any time, including retroactively for items already sitting in the queue, and a timeout-based auto-escalation rule that moves any item untouched for a defined period to the next approver up.

Should delegation be one-to-one or to a pool of approvers?

One-to-one. A single named delegate produces unambiguous accountability, a clean audit trail and no diffusion of responsibility.

How do you stop delegation from creating a self-approval breach?

Validate at approval time, not just at delegation time. The system must block any action where the effective approver is also the requester, the preparer, or the beneficiary of the transaction, and it must.

What does an audit trail for a delegated approval need to record?

It needs the acting approver, the approver on whose behalf they acted, the delegation identifier, the delegation start and end dates, who created or amended the delegation and when, the authority limit applied, and the timestamp of the decision.

What is a reasonable timeout before an approval auto-escalates?

Most finance teams set 48 to 72 business hours for routine expense reports and 24 hours for payment-critical or deadline-bound items such as travel bookings and cash advance releases.

How do you measure whether delegation design is working?

Track five metrics: percentage of approvals completed within SLA, average approver dwell time, delegation coverage rate for approvers with active absences, stalled-item count older than the timeout threshold, and the number of administrator overrides.

Does credential sharing count as a delegation workaround?

Yes, and it is the most damaging one. When delegation is unavailable or cumbersome, approvers share passwords with assistants or deputies so the queue keeps moving.

Chirashree Dan

Marketing Team

Read more articles on the Peakflo Blog.