A rejection is more expensive than it looks. The invoice has already been found, opened, entered, coded and routed. Then it comes back, and most of that has to happen again — often by a different person, days later, without the context that made it quick the first time.
A rejection rate that feels like a minor annoyance can quietly be a large share of the total effort in AP, because the rejected ones are handled two or three times.
Worth knowing what's actually causing them, because in most cases it isn't the approver being difficult.
Most rejections aren't decisions
There's a distinction that changes how you fix this.
A decision is an approver looking at a legitimate, complete invoice and concluding the business shouldn't pay it. This is what approval is for, and it should be rare — by the time an invoice exists, the money is usually already committed.
An exception is an approver unable to make a decision because something's missing, wrong, or unrecognisable. The invoice goes back not because the answer is no, but because there isn't enough information to say yes.
Nearly all rejections are exceptions. That matters, because exceptions are preventable before the invoice is ever routed, and decisions aren't.
The common causes
The approver doesn't recognise it
The single biggest category. A manager gets an invoice from a supplier they don't remember, for a service described in the supplier's language rather than theirs, ordered by someone in their team three months ago.
They can't approve what they can't identify, so it comes back with "what is this?" — which isn't a rejection so much as a request for context that should have travelled with it.
It's gone to the wrong person
Routed by department, or by an old rule, or by whoever approved the last one from that supplier. The person receiving it has no authority over that spend or no knowledge of it.
Often it isn't rejected outright but sits, and gets rejected eventually only because someone chases and the approver finally says "this isn't mine".
The amount doesn't match what was expected
The quote was £4,000, the invoice is £4,680. Sometimes it's VAT. Sometimes it's delivery, or a variation nobody minuted, or a price increase the supplier applied without saying.
The approver knows the number they agreed. Any difference stops the invoice, and rightly.
The coding is wrong
Finance codes it to the nearest plausible account, the budget holder sees it hit their cost centre, and it comes back. This one is often invisible as a rejection because it gets handled as a journal later, but the rework is the same.
There's no backup
An invoice for "consultancy — March" with no timesheet, or materials with no delivery note. The approver wants the supporting document, and it exists, but it arrived separately and is in a different inbox.
It's a duplicate
The same invoice arrived twice, or was re-sent after chasing, or came both from the supplier's system and as a PDF from their account manager. Occasionally the approver spots it. More often it's found later, which is worse.
It's not actually an invoice
Statements are the classic. Also pro-forma invoices, order acknowledgements, and delivery notes with prices on them. Each looks close enough to an invoice to be entered, and none of them should be.
What these have in common
Almost every cause above is the same underlying thing: the invoice reached the approver without the context needed to approve it.
Not a missing process step. Missing information — what it was for, who ordered it, what was expected, what supports it.
Which explains why adding approval stages makes this worse rather than better. Another reviewer without the context is another person who can't decide.
What reduces them
Send the context with the invoice. Who ordered it, what it relates to, and any related documents — the delivery note, the purchase order, the previous invoice from that supplier. An approver who can see what they're approving usually approves it. This is the highest-value change and it's mostly about assembly, not authority.
Route by who ordered it, not by department. The right approver is the person who made the commitment. If nobody knows who that is, that's the real finding, and it's worth fixing upstream.
Check the arithmetic before routing. Does net plus VAT equal gross, does the total match the lines. It's a small check that catches supplier errors before they cost an approval round trip, and finding it early means one query to the supplier rather than a rejection and a re-entry.
Screen for duplicates on entry. Same supplier, same invoice number is the obvious case. Same supplier, same amount, same week is the one that catches re-sends where the reference changed.
Set a threshold. Low-value recurring invoices from known suppliers don't need a manager to look at them. Every one you route is an opportunity for an exception, and the review costs more than the risk on small familiar spend.
Agree coding conventions with budget holders once, rather than discovering them one rejection at a time.
Tell approvers what to do with a bad one. "Reject" with no reason produces a second round trip. A required note costs the approver five seconds and saves a conversation.
Two worth being careful about
Don't confuse this with variance matching. Comparing an invoice line-by-line against a purchase order and a goods receipt — three-way matching — is a heavier control that suits businesses with formal purchasing. Most small businesses don't run one, and bolting on a partial version tends to create exceptions rather than prevent them. Getting the right context to the right approver solves most of this without it.
Don't fix rejections by removing approval. The rejections that are genuine decisions are the ones earning the control its place. The aim is to remove the exceptions so the decisions are visible, not to stop looking.
Measuring it
Count rejections for a month and note the reason for each. Not a formal exercise — a tally on a page.
The distribution is usually lopsided, and the top one or two reasons will account for most of it. Those are worth fixing properly. The tail generally isn't.
Most teams who do this find the top reason is context rather than disagreement, and that it's fixable without changing anybody's authority.
Cribble reads the documents around an invoice — delivery notes, credit notes, statements — and links related ones together, so what reaches an approver arrives with its supporting paperwork rather than on its own. It flags likely duplicates before they're routed.