An invoice arrives on the fourth. It is coded on the fifth. On the nineteenth someone notices the vendor has called twice, and the invoice is still sitting with an approver who has been out since the eleventh.

Nobody in that story did anything wrong. The workflow did. Approvals stall for structural reasons, and the structural reasons are fixable without asking anyone to try harder.

Why approvals stall

There are four causes, and almost every stalled invoice is one of them. It is worth being precise, because the fix is different in each case.

Nobody is named

The invoice needs an approval, but the record does not say whose. It goes to a shared inbox or a channel, where it belongs to everyone and therefore to no one. The fix is a named owner on the record, visible without opening anything.

The named person is unavailable

Someone is out, and the rule for that case was never written down. A backup that exists only in people's heads is not a backup. Encode it: when the owner is away, the record should already know who signs instead, and it should switch automatically rather than waiting for someone to notice.

The approver cannot decide from what they can see

If approving means opening a PDF, checking a purchase order in another system, and asking what it was for, the invoice will wait. Approvers are not stalling. They are missing context. Put the context on the invoice.

The threshold is ambiguous

When it is unclear whether an amount needs a second signature, people default to caution, which means asking, which means waiting. Write the thresholds down and show the applicable one on the invoice itself.

Design the route before you automate it

Approval routing is mostly a policy question wearing a software costume. Before you configure anything, get three decisions on paper.

First, who can approve what. Most teams need two or three bands: a routine band that one person clears, a middle band that needs the ops owner, and a high band that needs the controller. Bands should map to real authority, not to job titles that sound senior.

Second, what happens when the named approver is out. Automatic reassignment after a fixed window beats an escalation that depends on someone complaining.

Third, what cannot be approved at all. A missing purchase order, a vendor whose banking details changed in the last thirty days, an amount that does not match the PO by more than a set tolerance. These should hold automatically and route to a person who can investigate rather than a person who can sign.

Reminders beat escalation

Escalation is a polite word for embarrassing someone into acting. It works once. Reminders work continuously, and they work better when they go to one named person rather than a group.

A daily reminder at a predictable time, listing only what that person owes, clears more invoices than a weekly summary sent to everyone. The summary gets skimmed. The list gets worked.

Escalation still has a place: after a fixed window, not as the first move. Two days of reminders, then the backup. That sequence is fair to the approver and fair to the vendor.

What belongs on the invoice

An approver should be able to decide without leaving the record. That is the whole design goal, and it comes down to a short list.

• A one-line description of what the spend is for.
• The matched purchase order or accrual, and any variance against it.
• The threshold that applies and who signs next if it is crossed.
• The effect on the cash week if it is approved today.
• The last three invoices from the same vendor, with what was approved.
• The source document, attached, so the detail is one click away rather than one email away.

Exceptions do not belong in the approval queue

A missing purchase order is not an approval decision. Neither is a duplicate, a banking detail that changed last week, or an amount that does not match by more than tolerance. Sending these to an approver asks the wrong person to do investigative work.

Give exceptions their own lane with their own owner, usually whoever knows the vendor file best. The approver's queue should contain only things that are ready to be decided. When investigation and approval share a queue, the investigation always wins and the approvals wait behind it.

The second benefit is measurement. A queue that mixes the two tells you nothing. Separated, you can see whether you have an approval problem or a data problem, and those get fixed in completely different ways.

Limits change, and the record should change with them

Approval authority is set once, usually during an implementation, and then quietly goes out of date. Someone leaves. A band is created. The business grows and the thresholds that made sense at four million stop making sense at eleven.

Put a review date on the rules themselves. Twice a year is enough. Read the bands out loud against the current org chart and check three things: that every named approver still works there, that the amounts still reflect real authority, and that the backup for each person is someone who is not also their only backup elsewhere.

The alternative is discovering the gap during an audit, or during the week your controller is on leave and it turns out nobody else can release anything over ten thousand.

Measure the queue, not the people

The useful measure is how long invoices wait, and where. Age the queue by the step it is sitting in: waiting on coding, waiting on a named approver, waiting on an exception, waiting on the payment run.

That view tells you which of the four causes you actually have. A pile waiting on coding is a capacity problem. A pile waiting on one approver is a backup problem. A pile in exceptions is a vendor file problem. Each needs a different answer, and none of them are solved by asking the team to be faster.

Where Control fits

Control keeps the routing rules, the named owners, the thresholds, and the approval history on the invoice itself, then holds anything that fails a rule instead of passing it along. Approvals and payment timing sit on the same record, so releasing an approval and scheduling the payment are one motion.

Capvolta is not a bank and does not lend. Payments run through licensed processors. What Control changes is the part before the money moves: who owes a decision, what they need to make it, and how long it has been waiting.