Based on AP recovery data from large global organisations
In a typical large organisation, roughly one in five invoices fails first-time matching. At that volume, exception handling can only work one way: resolve the item, close it, move to the next. Every metric attached to the work, queue size, ageing, items cleared per day, rewards exactly that.
For most of the queue, this is the right treatment. A keying error is a keying error. Fix it and nothing more needs to happen.
Some exceptions, though, are symptoms. The item in the queue is real and needs handling, but behind it sits a flaw in process design, master data, or organisational structure, and that flaw keeps producing new exceptions regardless of how quickly the old ones get resolved. Clearing these has a side effect that goes unmeasured: each closed item removes the visible evidence that the deeper problem exists.
In our recovery work across large global organisations, we see that specific types of exceptions point to these deeper P2P problems. These are the ones that come up most often.
Mismatches resolved by manual override
An override is an employee pushing an invoice through after the system said it did not match. Occasionally that is the right call. When it becomes the standard route for a whole category of invoices, the control has effectively been switched off for that category, and the reports do not show it, because overridden invoices still count as matched.
The clearest version is the retrospective purchase order. The invoice arrives, no order exists, and someone creates one to fit what has already happened. The three-way match then succeeds and verifies nothing, because the order was built from the invoice it was supposed to validate. The override log is the only place any of this is recorded, and few organisations review that log with any regularity.
Credit notes that never get applied
Unapplied credits appear in nearly every audit we run, sometimes years old. A credit note is money the supplier owes back, and no category produces higher recovery amounts in our audits. Each of these credits once passed through a workflow and was closed as complete, because applying a credit is rarely anyone’s KPI, and chasing one is rarely anyone’s job.
What this reveals is an ownership gap. AP handles documents one at a time, and each document can be correct on its own while the supplier balance as a whole drifts. The money already belongs to the organisation. It sits on the suppliers’ books, invisible to a process that never looks across transactions, until someone asks for it. In our recovery work, the combined value of these credits regularly surprises the organisation that owns them. The credits are recoverable at any point. The gap stays open until someone is given ownership of supplier balances, and in most organisations, that job belongs to no one.
Aged open items nobody can explain
Growing GR/IR balances, invoices parked past 90 days, payments on hold whose original reason has left the company. The workflow defines how an invoice enters each of these states. Nobody is responsible for moving it out, so it stops moving, and the pile grows even in teams that clear their daily queue on time.
These items attract little attention because they no longer sit in anyone’s active queue. That is the signal. The volume of stuck items is a reasonable measure of how much of the process operates outside its own design, and it tends to be largest in exactly the organisations where complexity has outpaced the original workflow.
Duplicates that passed the matching controls
The duplicates that matter here are the ones found in paid data, months after the fact. They went through because the invoice came in under a second vendor record, with a slightly altered reference, or through a different entity or system. To the system, it never looked like a duplicate at all.
We have written separately about the six distinct types of duplicate payments our recovery data identifies. The point here is narrower. When a duplicate surfaces in a recovery audit, the recovered amount is the smallest part of the finding. The duplicate is proof that the same supplier exists under multiple identities, or that two systems pay invoices with no visibility of each other. Every control built on that data carries the same blind spot, and it will keep producing duplicates until the data itself is addressed.
The same suppliers, month after month
In most exception data we examine, a small share of suppliers generates a large share of the exceptions, and the list barely changes from one quarter to the next. Consolidated invoices the workflow cannot split. Unit-of-measure mismatches. Reference formats that never align with the PO.
A random failure is noise. A repeating one is a design problem with no feedback loop attached. The exception gets resolved in AP while its cause sits in supplier onboarding or in the supplier’s own invoicing setup, and no information travels between the two. The same problem gets handled twelve times a year because nobody has fixed it once.
Exceptions that cross an entity or system boundary
Intercompany invoices, transactions split between a shared service centre and a local entity, payments touching two ERP systems after an acquisition: these exceptions take the longest to resolve because no single person can see the whole transaction.
They reveal a mismatch between the process map and the system map. The workflow was designed around one system of record, and the organisation now runs three. Each system’s internal controls work correctly within their own walls, and the gap sits between them, where no control was ever placed. Every handler sees half the picture, and no standard report counts these items as a group, so each one looks like an isolated annoyance while the pattern stays invisible. This is the same structural condition that produces cross-division and cross-ERP duplicate payments, and it explains why these exceptions outlast improvement projects that stay inside a single system.
What separates these from the rest
Four traits mark an exception as worth a closer look before it is cleared.
- It recurs, with the same supplier or the same failure type appearing across months.
- It was resolved by a human overruling the system.
- It crosses a boundary between entities, departments, or systems.
- Or it accumulates without resolution, ageing in a state the workflow cannot close.
An exception with none of these traits is operational noise, and clearing it quickly is the right decision. An exception with one or more of them is evidence of where the process design no longer matches the organisation it serves.
Five questions to put to your own data
Each pattern above leaves a trace in standard exports. These questions surface it, and in every case, struggling to produce the answer is itself a finding.
- Which ten suppliers generated the most exceptions over the past 12 months, and were they the same ten the year before?
- Which invoice categories get manually overridden more often than they match cleanly?
- What is the current total value of unapplied credit notes across the supplier base?
- For each state an invoice can get stuck in, who is responsible for getting it out?
- How many open exceptions involve more than one entity or system, and how much working time do they consume?
An AP manager who can answer all five is in a small minority, and that is no personal failing. Nothing in the standard exception workflow asks these questions, and no metric rewards answering them.
The cost of treating them all the same
Most of the queue deserves exactly the treatment it gets, and an AP team that stopped to investigate every item would drown within a week. The loss happens in the small share that carries information. Each resolved exception of the types above contained a root-cause analysis someone performed and then discarded. Across a year and thousands of items, that is a substantial body of evidence about where controls, data, and structure are failing, assembled daily and recorded nowhere.
The five questions are a way of recovering that evidence from data the team already has. Some of it can only be read from outside any single system, which is part of what a structured recovery audit does: it looks across entities, systems, and years of payment history at once, exactly where several of these exception types live. The rest is sitting in exports an AP team can pull this week. The structural problems persist either way. Reading the evidence is what makes them visible while they are still cheap to fix.
