Invoice approval workflow, thresholds, delegation, and evidence

Approval is the accounts payable (AP) control everybody has and almost nobody tests. It exists to prove that a person with authority agreed to commit the money, and to make that provable later. The matrix looks correct in the policy document. The interesting questions start when the approver is on leave, or when the thing that cleared the invoice was not a person.

What an invoice approval workflow is for

Everything attached to approvals is logistics. The hierarchy, the mobile app, the reminders, and the audit log exist to produce one piece of evidence. Design the workflow as a routing problem rather than an authorization problem and you get speed with no record.

The pressure is real. Ardent Partners published its State of ePayables 2025 benchmarks in January 2026, covering 2025. Average invoice cycle time was 8.2 days, and AP staff spent 21.9 percent of their time on supplier inquiries. Many of those inquiries are suppliers asking where their payment is. The honest answer is often that a manager has held the invoice in an approval queue since the twelfth, and nobody in AP can move it.

Teams respond in two ways. They raise auto-approval thresholds, and they lean harder on delegation so nothing stalls when somebody travels. Both relieve the bottleneck, and both are exactly where approval controls fail. Neither shows up in a cycle time report, because a control that fails open looks like performance rather than exposure. The number improves, the queue shortens, and the evidence quietly thins out.

How to think about invoice approval workflow design

Authority comes first, then routing, then automation. Most teams take that order backwards. Somebody configures routing rules in the enterprise resource planning (ERP) system, and the result gets written up afterwards as a delegation of authority (DoA) policy.

Amount is a proxy for risk and a weak one. Take a $900 invoice from a supplier added last week, paid to a bank account changed yesterday. It is riskier than a $90,000 invoice against an open purchase order (PO) from a supplier of twelve years. A pure amount ladder routes the second to a vice president and the first to nobody.

The second principle is that an approver must know something the system does not. Asking a cost center owner to confirm a service was delivered is a real control, because they were there. Asking them to confirm arithmetic is theater, and they click through it at a rate that makes the ladder worthless.

The third is that every design choice trades cycle time against control depth. Adding a level adds days, and removing one removes evidence. Make that trade deliberately, per risk band, rather than accidentally during a backlog project.

Build the matrix on more than amount

A workable approval matrix has several independent dimensions. An invoice is evaluated against all of them rather than routed down one ladder.

Amount. Over $50,000 adds a second approver. This protects against large unauthorized commitments, and it is the only dimension most matrices have.

Cost center. The invoice routes to the budget owner, which protects against spend charged to another budget.

Spend category. Legal and agency invoices route to a category owner, which protects against off-contract specialist rates.

Risk signal. A new vendor, or changed bank details, adds review. This protects against payment redirection and ghost vendors, and it is the dimension most often missing.

PO status. Non-PO-backed invoices go to a named approver, which protects against commitments with no order behind them.

State which rule wins when two apply. Highest authority is the simplest resolution, and it needs writing down before month-end.

Segregation of duties is a design constraint

One person must not hold all four of these roles. The requester asks for the purchase and the approver authorizes it. The vendor master maintainer creates and edits supplier records, including bank details. The payment releaser sends the file to the bank.

Combine the vendor master with payment release and you have built the ghost vendor path. One person creates a supplier, approves a modest invoice from it, and releases the payment, every step logged and legitimate.

Small teams cannot separate all four, and pretending otherwise produces a policy nobody follows. Compensating controls are the honest answer. Use dual release above a threshold. Have somebody outside AP review the monthly vendor master change report. Verify bank changes against a number held on file rather than one supplied in the email. Write down which control compensates for which gap, because auditors ask that first.

Delegation is where approval controls actually fail

Delegation of authority is configured by the person leaving, not by the person who owns the control. That fact explains most of what goes wrong.

The failure modes are consistent. A delegation with no end date stays live for years. A delegation passes the delegator's limit to somebody two grades below, so a coordinator ends up holding a $250,000 authority. With chained delegation, A delegates to B and B delegates to C, and nobody intended C to hold it. A manager who delegates to somebody reporting to the requester collapses segregation of duties. Bulk delegation to a shared mailbox leaves no approver of record.

The audit trail usually makes it worse. Many systems record the approval under the delegator's name, so the log shows somebody approving invoices from a beach in Portugal. Others record the delegate with no reference to the authority used. Neither lets an auditor reconstruct who was entitled to approve what.

Four rules fix most of it. Require an end date on every delegation. Cap the delegated limit at the lower of the two authorities, and allow a chain depth of one. Report active delegations monthly to the control owner. Then record approvals as the delegate acting for the delegator, with both names and the limit that applied.

Escalation, reminders, and stuck approvals

A reminder at day two and an escalation at day five will clear most queues. Escalation means the next approver up gets the invoice, and it should never approve on a timer.

Time-based auto-approval is a control that fails open, so it fails silently and in the direction that costs money. It also removes the pressure that would fix the real problem, one approver with 300 items queued.

When an agent approves an invoice, who approved it?

If an AI agent clears invoices inside a threshold, the control still needs an owner and an evidence chain. Five questions decide whether it is auditable.

• Who is the approver of record? Name a human owner accountable for the agent's authority, and record the agent identity beside that owner.
• What evidence does an auditor receive? An auditor needs the inputs read, the policy version applied, the decision, and the threshold that governed it, in a form somebody can re-examine later.
• What are the agent's limits? The matrix dimensions still apply, so set an amount cap, a category allowlist, and an exclusion for first invoices from new suppliers.
• How is a change treated? A change to the model or policy behind an automated approval changes a control. It needs change control, a tested sample, and a documented before and after.
• What is the rollback path? Know how to revert to human approval, how to find everything approved under the changed behavior, and who pulls the switch.

Nobody has settled these questions, and auditors are still forming a position. Designing for them now beats retrofitting evidence during fieldwork.

What an invoice approval does not prove

An approval is a control over authorization. It says a person with authority said yes on a date.

It does not prove the service was delivered, or that the invoice was not paid last month through another channel. Those are matching and duplicate controls, covered in our guides to invoice matching and tolerances and three-way PO matching automation.

It also does not prove attention. The ACFE Report to the Nations 2026 found that tips were the most common detection method, at 43 percent of cases. Approvers are not the detection layer.

Where current approaches fall short

Most approval configurations are amount ladders with a delegation feature bolted on. Risk signals live in a different system from routing rules, so a bank change last Tuesday cannot influence today's approval path. The invoice that most deserves a second look gets the fewest approvers.

Delegation is treated as a convenience feature rather than a control surface. Few teams can produce a list of active delegations on request, and fewer can show the limit that applied to a past approval.

Evidence is the third gap. A log that records an approver name and a timestamp answers a question nobody is asking. The real question is what the approver saw, what authority they held at that moment, and what rule sent the invoice to them. That gap is uncomfortable with human approvers, and untenable once software approves anything on its own.

How we approach approvals

We route on context rather than on amount alone. Our AI reads the invoice, the PO, and the supporting records, then applies your policy to decide where it goes. That runs in the same AP automation and approval routing flow that captures and codes the invoice, so the platform can apply risk signals to the routing decision.

For the agent question, we build the evidence chain first. Agents created in AI Agent Studio follow a documented standard operating procedure (SOP), operate inside limits you set, and record what they read and why they acted. A human owner stays accountable for each Agent's authority, and every decision stays inspectable.

That governance is what lets you automate more than low-value invoices. Our customers reach automation rates of 80 percent or more because the approval evidence holds up under inspection.

The bottom line

Run one report this week, a list of every active delegation with its start date, end date, and limit. Any delegation with no end date, or a limit above the delegator's own, is your weakest approval control. Our team can walk the matrix with you.

Frequently asked questions

What should an invoice approval matrix include?

It should include amount, cost center, spend category, and risk signals such as a new vendor or a recent bank change. Route on all four rather than one ladder, and define which rule wins when two apply.

How should delegation of authority be controlled?

Require an end date on every delegation, cap the delegate at the lower of the two limits, and allow one level of chaining. Review active delegations monthly, and record approvals as the delegate acting for the delegator.

Can an AI agent approve invoices?

It can, within defined limits, provided a named human owns the agent's authority and every decision leaves an evidence record. Treat a change to the model or policy as a change to a control. The unresolved part is what auditors will standardize on.

What does invoice approval not catch?

It confirms authorization, nothing more. A valid approval says nothing about whether the goods arrived, whether the rate was contracted, or whether the invoice was already paid elsewhere.