Every AP team has lived this one. An invoice is captured cleanly, coded correctly, and routed to the right approver — who is on vacation for two weeks. Nothing is wrong with the invoice. Nothing is wrong with the workflow. But the payment is now quietly aging in someone's queue, and no one knows until the supplier calls asking where their money is.
This is one of the most common, least-discussed sources of late payments in accounts payable. It isn't an extraction problem or a matching problem. It's a people-are-human problem — and the systems that handle it well planned for the approver being unavailable, rather than assuming everyone is always at their desk.
Why "approver is away" stalls the whole queue
In most approval workflows, an invoice sits with a single named approver until that person acts on it. That's correct — accountability requires a specific owner. But it has a failure mode: if the owner is out, the invoice has nowhere to go.
The usual workarounds are all bad:
- Wait it out. The invoice ages. Early-payment discounts are lost, and late fees or strained supplier relationships follow.
- Have an admin reassign manually. Someone has to notice the stall first, then track down who should cover, then move each invoice by hand — which rarely happens until a supplier complains.
- Skip the approval. The worst option — it breaks segregation of duties and leaves an audit gap.
None of these scale. On a team processing thousands of invoices a month, even a handful of approvers on leave at any time produces a steady drip of stalled payments AP has to chase reactively.
Out-of-office delegation, done as a first-class feature
The clean fix is to treat approver unavailability as a normal, expected state the workflow handles automatically — not an exception someone discovers later.
The pattern works like this. An approver who's going to be away sets an out-of-office period and names a delegate — another authorized user who will cover their queue. While that period is active, invoices that would route to the absent approver are reassigned to the delegate instead, and the delegate is notified that something is now waiting on them. When the period ends, routing reverts automatically. No admin intervention, no manual reassignment, no stalled queue.
Two details make this trustworthy rather than risky:
- It's fully audited. The record shows the original approver, the delegate who acted, and that the action happened under an out-of-office delegation. Delegation that hides the substitution is a control gap; delegation that records it is a control feature.
- The delegate must be authorized. The delegate has to be a valid approver in their own right, so the amount and authority rules that govern your hierarchy still hold.
This is the same principle behind routing invoices by supplier relationship rather than dollar amount — the system should encode how the organization actually delegates authority, so the knowledge isn't living in one person's head and walking out the door when they're on leave.
Send-back-to-initiator: the other direction the queue can stall
Delegation handles the approver being unavailable. But there's a second, opposite stall: the approver is available, looks at the invoice, and realizes it shouldn't be approved as-is. Maybe the coding is wrong, the wrong cost center was applied, or supporting documentation is missing.
If the only buttons are approve and reject, the approver is stuck choosing between waving through something they're not comfortable with or hard-rejecting an invoice that just needs a fix. Neither is right.
The answer is a send-back-to-initiator action. The approver returns the invoice to the person who submitted it, with a note about what needs to change. The initiator fixes it and resubmits, and it flows back through the approval path. This keeps the invoice alive and moving instead of dying in a rejection pile, and it keeps the correction with the person best placed to make it — the original submitter — rather than turning the approver into a data-entry clerk.
Close the loop so the submitter stops chasing
The last piece is small and easy to overlook, but it removes an enormous amount of low-value back-and-forth: a final notification when the invoice is approved.
Without it, the submitter has no idea whether the invoice they sent up the chain three days ago is approved, still pending, or sent back to someone else. So they check in, they email, they ping AP — chasing that is pure overhead, and it's worse the larger and more distributed the organization is.
A simple "this invoice has been approved" notification to the submitter closes the loop. They know it's done, they stop checking, and AP isn't fielding status questions about invoices that already cleared. Pair it with auto-completion of any pending tasks once an invoice is approved or rejected, and the whole picture stays clean — no one is staring at to-dos for invoices that are already resolved.
Where EZ Cloud fits
These three behaviors — out-of-office delegation to a named, authorized delegate; send-back-to-initiator; and a final approval notification with task auto-completion — are exactly the kind of operational detail that separates AP automation that looks finished from AP automation that actually keeps payments moving. We've built all three into the approval workflow, and they run in production for teams on Oracle EBS and Oracle Fusion alike, with K-12 and public-sector approval flows where attestation and audit trail matter as much as speed.
If your AP team is still discovering stalled invoices only when a supplier complains, the missing piece usually isn't faster capture — it's a workflow that assumes approvers are human and keeps the queue moving anyway.