An AP invoice approval process is written as a policy and experienced as a set of configuration choices. The policy says who may approve what, and it rarely changes. The configuration decides how long an invoice waits before reaching one of those people, and it accounts for almost all the difference between a process suppliers find reasonable and one they complain about.
Routing and cover
Route by cost centre and value to a named person, not a group, because a group queue produces items everybody sees and nobody actions. Then cover absence automatically, based on declared leave or a fixed period of inactivity. Manual delegation is forgotten precisely when it is needed, since unplanned absence is by definition unplanned.
Escalation and its period
After a defined interval, move the item to a named alternative rather than sending another reminder. Choose the interval by working backwards from your payment terms: on thirty-day terms, an invoice that has waited a week has already spent a quarter of the available time. Defaults nobody chose are the usual reason this is set badly.
What the approver sees
The invoice, the amount, the supplier, what it is for, and the match result. An approver shown only a reference and a total is confirming a number, and they know it. This is the choice that decides whether the process is a control or a formality, and it costs nothing to get right.
Questions people ask about ap invoice approval process
Do more approvers mean better control?
They reliably mean more delay and only sometimes better control, since shared responsibility can mean neither person looks properly.
Should matched invoices need approval at all?
Where a clean match within tolerance is treated as authorisation, no. Make it a written policy rather than a configuration default.
How do we know if the configuration is working?
Measure the elapsed time distribution and look at the tail. The average will always look acceptable.