Why invoice approvals stall before anyone can approve them

At one UK client, utility bills were entering the general invoice route. They needed no purchase order and required line-level extraction, yet the process was treating them like any other invoice.

At another point in our UK client work, invoices were falsely held because gross totals were being compared with net purchase order budgets. Invoices for the full order value plus VAT were particularly affected. They looked over budget to the system, even when they were not.

Both issues appeared as approval delays. Chasing the approver would have achieved very little. The invoices had stalled before anyone had a fair chance to approve them.

The approval queue only shows where the invoice ended up

An invoice goes through several decisions before it reaches an approver. The process identifies what kind of invoice it is, selects a route, looks for required matches and runs its checks.

A mistake at any of those points can leave a valid invoice sitting in a queue. The status might say it is held or waiting, but that does not tell you whether the approval itself is the issue.

This matters when Finance Directors review approval performance. Reminder timings and escalation routes are easy to see. Classification, matching logic and failed-check behaviour tend to sit further back, despite having already decided whether the invoice can move.

No reminder email can correct a gross-to-net comparison. It simply reminds someone about an invoice they still cannot approve.

Give each invoice type the route it needs

PO, non-PO and utility invoices do not arrive with the same information. Their routes should reflect that.

At one UK client, the intended validation requirements were:

• A PO invoice needed a matched supplier and purchase order.

• A non-PO invoice needed a matched supplier, property, fund and heading.

• A utility invoice needed to be handled without a purchase order and extracted at line level.

Those distinctions are practical. A non-PO invoice cannot provide a purchase order that was never raised. A utility bill loses its intended treatment when it enters the general route.

The utility example also shows why classification is more than a label. It determines what information is extracted and which checks are applied afterwards. Getting the invoice type wrong at the start sends the rest of the process in the wrong direction.

A useful route definition should answer three questions plainly:

1. What kind of invoice is this?

2. Which fields and matches are required for that invoice type?

3. Which checks should apply before it reaches an approver?

If the answers are the same for every invoice, the route deserves another look.

Check what the matching rule is actually comparing

Gross and net amounts are both valid figures. They are not interchangeable.

The false holds we saw came from comparing a gross invoice total with a net purchase order budget. For an invoice covering the full order value plus VAT, the result was predictable. The invoice total appeared higher because it included VAT and the budget did not.

The check was meant to identify an invoice exceeding its purchase order. Instead, it identified the presence of VAT.

The names used in a system can make this harder to spot. Labels such as “invoice total” and “PO value” sound clear until one includes VAT and the other excludes it. The rule needs to define the basis of each amount, rather than relying on a broad field name.

For every budget check, confirm:

• Whether the purchase order budget is stored net or gross.

• Whether the invoice value being tested includes VAT.

• Whether both sides of the comparison use the same basis.

• How an invoice for the full order value plus VAT behaves.

That final test is worth running with a real example. It exposes the mismatch quickly and gives the team something more useful than a rule description on a configuration screen.

Decide how much authority each check should have

Some checks need to stop an invoice. Others need to make an issue visible while allowing the invoice to continue.

A UK client made that choice explicitly for utility bills. When a bill failed the reduced-rate VAT or Climate Change Levy checks, it continued through the process with a warning. The check remained visible, but it did not hold up the invoice.

That is the level at which these rules should be agreed. The presence of a check does not automatically mean failure should block processing.

For each failed check, decide whether it:

• Prevents the invoice from continuing.

• Adds a warning while allowing it to continue.

This should follow the intended finance process, rather than a blanket setting applied to every exception. A hard stop is useful when the invoice genuinely cannot proceed. Used too freely, it fills the queue with invoices that the team has already decided may continue.

A checklist for reviewing approval routes

Take one recent example of each invoice type your team handles. For a mixed AP team, that is likely to include PO, non-PO and utility invoices. Trace each one from receipt to the point where an approver can act.

Invoice type and route

• Is the invoice type identified before its validation rules run?

• Do utility bills enter a utility route rather than the general invoice route?

• Does the route reflect whether a purchase order should exist?

• Are utility bills extracted at line level where required?

Required matches

• Does a PO invoice require a matched supplier and purchase order?

• Does a non-PO invoice require the relevant supplier, property, fund and heading?

• Is any invoice being asked for a match that does not belong to its type?

• Do route-specific requirements remain distinct from general invoice rules?

Amount comparisons

• Are the invoice and purchase order amounts both net or both gross?

• Does the invoice amount under review include VAT?

• What happens when an invoice covers the full net order value plus VAT?

• Can the team see which values caused the invoice to be held?

Warning or block

• Which failed checks genuinely require processing to stop?

• Which checks only require a visible warning?

• Are reduced-rate VAT and Climate Change Levy failures treated as intended for utility bills?

• Has the response to each failed check been chosen deliberately?

Record the route, required matches and failed-check response for each example. This gives you a useful map of what the process actually does, rather than what everyone assumes it does.

Review the rules before chasing the approver

When invoice approvals stall, start with the route. Check how the invoice was classified, what it was required to match and which rule stopped it. Then confirm that any amount comparison uses like-for-like values.

Put the current PO, non-PO and utility routes against the checklist above. If that review finds rules that need rebuilding, our invoice processing work covers this part of the process.

First, get the rules onto one page. A false hold is much easier to challenge when everyone can see exactly what caused it.