Handling Exceptions That AR Automation Cannot Resolve

The premise of AR automation is simple: give it a clean, predictable transaction and it works beautifully. The problem is that real-world AR is not clean or predictable, and every invoice that falls outside the rules lands in a queue that no amount of additional automation is going to clear on its own. That queue is where cash sits. That queue is where DSO inflates. And for most finance teams, that queue has no deliberate process behind it at all — it's like a waiting room where everyone has a number but no one is calling names.

The answer is building the operational layer that handles the work automation was never designed to do.

How Large the Exception Problem Actually Is

Start with the headline number. According to Ardent Partners' State of ePayables 2025, the average exception rate sits at 18.4% of all invoices processed, with each exception taking an average of 8.2 days to clear. Earlier Ardent data showed the rate was closer to 24%. So after years of automation investment across the industry, the needle has barely moved.

Here's what that looks like in practice:

• Top-performing teams process exception invoices at roughly $2.78 per invoice, cleared in about 3.1 days
• Average teams spend $12.88 per invoice and take 17.4 days to clear the same item
• Exception invoices cost three to five times more to process than standard transactions

The staff-time burden is where this becomes an operational emergency. Ardent Partners research shows AP departments spend roughly 62% of their time handling exceptions rather than anything that can be described as strategic work. Think about that. More than half the department's capacity goes to cleaning up problems, not doing the actual job. It's like spending most of your morning looking for your keys and calling it a commute.

The working capital math is also pretty direct. Manual exception handling creates payment delays of three to seven days for simpler cases, six to nine days for complex ones. For a mid-market supplier, that translates to significant annual working capital strain. Spread across a year, it's invisible. Aggregated, it's a real number that shows up in a CFO conversation.

And then there's the human cost: 86% of businesses report that up to 30% of their monthly invoiced sales are overdue. Twenty-seven percent of finance teams spend at least half their time resolving invoice disputes instead of doing forward-looking work.

The question these figures raise isn't whether exceptions matter. It's whether the team handling them has any deliberate method for doing so. Most don't.

The Eight Exception Types Automation Consistently Cannot Clear

These are not edge cases or unusual scenarios. These are the predictable failure modes of rule-based systems. Each one is blocked for a different structural reason, which is exactly why a single automation fix doesn't work.

1. Invoice Disputes

The customer contests the price, the quantity, the delivery terms, or the contract interpretation. Resolving it requires pulling the original PO, proof of delivery, and pricing agreement. Then someone has to make a judgment call.

Sending another automated reminder to a customer who believes they've already raised a valid dispute doesn't just fail. It actively makes the situation worse. Dispute management consumes up to 30% of total order-to-cash effort, which tells you how common and how expensive these cases are.

2. Unapplied Cash and Cash Application Failures

The payment arrived. The money is in the bank. The receivable still shows open because the remittance was unreadable, covered multiple invoices, or got lost somewhere in the system.

This is the most visible and avoidable AR failure there is. The customer gets chased for an invoice they paid weeks ago. The root cause is that remittance formats vary completely by customer. Unstructured documents like credit memos, debit memos, and proof-of-delivery confirmations cannot be matched until their data is extracted and structured. Automation handles standard formats reasonably well. It handles everything else poorly.

3. Short Payments and Customer Deductions

The customer pays less than the invoice amount. The difference is either valid (an agreed discount, a promotional allowance) or invalid (an unauthorized chargeback, a duplicate claim). Figuring out which one requires the PO, proof of delivery, the promotional agreement, and the pricing terms. Then someone has to decide.

Depending on the industry, deductions represent 5% to 20% of gross revenues. In consumer products and CPG, the number is at the higher end because of trade promotion billbacks. Up to 20% of all deductions go unresolved or get written off due to poor tracking. That is a direct, recurring margin hit.

Small deductions often cost more to investigate than they're worth to recover individually, so they get written off. Here's the problem: customers who learn that certain deductions are never challenged have very little incentive to stop taking them. Deduction resolution ties up as much as 75% of some AR departments, plus sales team time for research and reconciliation.

4. Missing or Misdirected Invoices

The invoice went to a contact who left the company, or it lacked a PO number, or it was emailed when the customer requires portal submission. The customer isn't unwilling to pay. The document just isn't where it needs to be. Research from the Credit Research Foundation puts 61% of late payments down to administrative errors or invoices received too late. Chasing the wrong address adds no value at all.

5. Missing PO Numbers and Non-PO Invoices

This is the most common single exception category. No PO on the invoice. A PO that's already been fully consumed. A PO that was never created because someone bought outside the normal process.

Non-PO invoices (legal, facilities, marketing services) have to be matched to statements of work and approval chains. There is no PO to match against. The automation has nothing to anchor to.

6. Active Promise-to-Pay

The customer has committed to a specific payment date. What this situation needs is a diary entry and a check on that date. Additional reminders in the meantime work against the process. Cadences that keep firing through a promise-to-pay window are a self-inflicted source of customer complaints and relationship damage. This one is entirely preventable.

7. Fraud-Risk Flags and Bank Detail Changes

An invoice references recently changed bank details. A vendor record is still marked active despite the relationship ending. These are common vectors for invoice fraud. Nearly 80% of organizations experienced attempted or actual payment fraud in 2024, with 30% reporting an increase over the prior year.

High-value payments, supplier banking changes, and policy exceptions require explicit human approval. No tolerance rule covers a potential fraud signal. None.

8. Customer Insolvency or Inability to Pay

Twenty-seven percent of financial executives report that late payments stem from customers lacking funds or being unreachable for issue resolution. These cases require credit judgment, legal escalation, or both. A rule engine cannot navigate either path.

Where the Automation-to-Human Handoff Should Actually Happen

Here's the practical reality. Dunning automation clears one type of overdue invoice: the one where an able, willing customer simply forgot. Once those are resolved, what remains is a queue where every single item is blocked for a reason a reminder cannot address.

Analysis of invoice exceptions across mid-market suppliers shows that the large majority can be auto-resolved using tolerance rules. Price variance within a small threshold. Rounding differences. Unit-of-measure mismatches. Missing fields. These clear themselves. The remaining cases, roughly 15% to 30% of the queue, require human reasoning. They also represent the high-value, high-risk portion of the queue.

The logic for routing using tolerance thresholds looks like this:

• Price variance within a defined small band: auto-approved
• Price variance above that band: routed to procurement with full context attached
• Missing fields that can be inferred from history: auto-corrected
• Missing fields that require judgment: routed to the analyst who owns that customer

Companies that implement automated tolerance rule engines consistently report that the approach saves meaningful AR team time per month. But only for the routine slice. The complex cases must arrive with full context, not just a hold code.

The compounding risk of not drawing this line is real. Adding more reminders to a queue of genuine exceptions increases customer irritation without increasing cash collected. The relationship cost shows up later in payment behavior. It's harder to quantify than DSO, but it's there.

The division between automation and human work is about the nature of the decision, not the dollar amount. Automation flags and classifies. Human judgment investigates, decides, and resolves. Employees should own disputes, unusual transactions, sensitive customer accounts, and any decision that requires financial or legal judgment. That's the line.

Building the Operational Layer That Clears Exceptions Deliberately

The operational layer that most AR teams are missing isn't complicated. It just has to be deliberate. Here's what it actually looks like.

Structured Exception Routing

Classification has to happen at intake. Not after a human has already opened the ticket and spent ten minutes figuring out what kind of problem they're looking at.

The system categorizes by exception type at the point of flag:

• Missing information goes to the analyst who owns that customer relationship
• Price mismatches route to procurement with the PO and pricing agreement attached
• Missing receipts go to warehouse or receiving
• Coding issues go to AP
• High-value anomalies and bank-detail changes go immediately to a controller or AP manager

Notifications have to go through the channel the assignee actually monitors. Dashboard, email, or mobile alert. Not a ticket in a system they check once a week.

Escalation Paths with Defined SLAs

Every exception type needs a time limit before it escalates. Unresolved items should not sit silently.

• Simple exceptions (missing PO, formatting error): short resolution window, single owner
• Complex exceptions (disputed line items, deduction investigations): longer window, cross-functional owner involving AR plus sales or AR plus legal
• Fraud-risk flags: immediate freeze and senior approval, no standard SLA, full stop

Document Retrieval as a First-Class Step

Most exception resolution stalls because the person resolving it doesn't have the relevant documents at hand. They spend their time hunting rather than deciding.

The PO, proof of delivery, pricing agreement, promotional terms, and remittance advice should be attached to the exception ticket automatically. Not retrieved manually. Not emailed around.

Portal navigation is also a real operational blocker. Supplier portals like Coupa and Ariba have their own submission requirements, and invoices sent by email when the customer requires portal entry create the "missing invoice" exception before resolution even begins. That one can often be prevented entirely with upfront customer onboarding notes.

Promise-to-Pay as a Distinct Workflow

This is not a collections task. It's a diary task and a verification task.

• Suppress the dunning cadence for the committed window
• Trigger a single check on the promised date
• If payment doesn't land, escalate immediately. Don't restart the standard sequence from the beginning.

Deduction Investigation Protocol

Small deductions get written off because the investigation cost exceeds the recovery value. That's often the right call individually. The problem is what it teaches the customer.

A practical triage approach:

• Below a defined dollar threshold: document it, write it off, but log the pattern
• Above that threshold: structured investigation with evidence gathering; invalid deductions get a formal dispute response with supporting documentation
• Pattern tracking is non-negotiable: a customer taking repeated small deductions that stay below the investigation threshold is a systematic problem, not a run of isolated ones

Cash Application Failures Get a Triage Step First

Before any collections action on an open receivable, confirm the payment hasn't already landed with an unreadable remittance. This is an internal reconciliation check, not a customer communication. Chasing a customer for an invoice they already paid is avoidable, and it happens far more often than it should.

The Information Gaps That Cause Exception Queues to Grow Faster Than Teams Can Clear Them

Manual exception handling consumes a substantial share of AR team capacity on low-value reconciliation work. The bottleneck is rarely effort. The team is usually working hard. The problem is that effort goes toward reconstructing context rather than resolving the actual issue.

The document layer is where most AR automation projects stall. Platforms that handle invoicing and standard collections reasonably well struggle with unstructured documents coming in from the customer side. Remittance formats, credit memos, debit memos, and proof-of-delivery confirmations all arrive differently. Each one needs its data extracted and structured before any matching or resolution can happen.

Then there's the tribal knowledge problem. Every experienced AR analyst carries hundreds of customer-specific patterns in their head. This supplier always bills freight on a separate invoice. That plant uses a different cost center. This customer's AP team only processes invoices on the first Tuesday of the month. None of it is in any system of record, which is a big part of why exception resolution has resisted automation for so long. The next analyst to touch the account starts from scratch. Every time. It's like inheriting a jigsaw puzzle with no picture on the box.

Without a central exception log, two failure modes compound on each other:

• Invalid deductions that are individually too small to investigate get written off, but the pattern goes unnoticed until it has become a significant margin leak
• Customers who receive automated chasers on invoices they've already paid, or in the middle of an active dispute, lose trust in the AR process. That relationship cost is harder to quantify than DSO, but it directly affects future payment behavior.

What's needed is structured exception logging that captures resolution decisions so they become institutional knowledge and pattern-detection inputs for the next time — layering more automation on top of the same data won't achieve that.

What Finance Teams Should Actually Measure to Know If Exception Handling Is Working

DSO is useful for the board. It is not useful for diagnosing exception-handling performance. By the time DSO moves in a meaningful direction, the exception queue has already been bleeding for weeks.

The metrics that actually reflect the exception layer:

• Exception rate as a share of total invoices. The Ardent Partners 2025 benchmark is 18.4% average. Top performers are meaningfully below that. If your rate isn't tracked, you can't improve it.
• Average exception resolution time by type. This one is important because it distinguishes between a team that clears simple exceptions quickly while complex ones languish, versus a team where the entire queue is stalled. The distinction tells you where to intervene.
• Exception aging. What share of the open exception queue is older than your defined SLA threshold. The aging curve reveals whether escalation paths are actually functioning or just exist on paper.
• Deduction write-off rate and deduction recovery rate. The gap between them is your margin leakage number. It's the number that gets attention in a CFO conversation.
• Promise-to-pay kept rate. This measures whether commitments convert to actual cash, or whether promise-to-pay is being used by customers to pause collections without any real intention to pay.

The cost-per-exception comparison matters here too. Top teams at $2.78 versus the average at $12.88 per invoice. Closing even a fraction of that gap on your exception volume pays for structured exception handling. That's the investment case, and it's not a hard one to make.

One more point on cadence: exception metrics should surface weekly, not monthly. The working capital strain from three-to-nine day delays per exception compounds quickly at volume. Monthly reporting hides the damage until it's already large.

Where Persistent, Human-Like Follow-Up Closes the Gap Automation Leaves Open

After all the routing logic, the SLAs, the document retrieval workflows, and the triage protocols, there is still a gap. It's the gap between a classified exception and an actually resolved one. That gap is closed by follow-up. Persistent, context-aware, human-like follow-up that understands where in the resolution process each exception sits and responds accordingly.

This is where tools like Kolleno, Esker, and HighRadius are doing interesting things. Each approaches the AR workflow differently, but the ones worth evaluating share a few traits: they maintain context across interactions so a follow-up communication reflects what's already been discussed, they route and escalate based on exception type rather than just aging buckets, and they support the kind of promise-to-pay management that suppresses reminders rather than sending them regardless.

Kolleno, in particular, is worth looking at for mid-market teams dealing with high exception volume. It combines workflow automation with a collaboration layer that keeps AR teams, sales, and customers working from the same information. The focus on keeping human judgment in the loop for complex cases, rather than automating past it, reflects how the problem actually works.

The core principle is this: the point of human-like follow-up is to make sure the human doing the judgment has the context they need, the customer gets a communication that makes sense given the current state of the account, and nothing falls through the cracks between the moment an exception is flagged and the moment cash actually lands.

Automation stops at the hold code. The operational layer picks it up from there. The teams that have built that layer deliberately are the ones processing exceptions at $2.78 instead of $12.88. The gap between those two numbers is a process gap. And it's entirely closable.