TL;DR
Collections is the work of getting a past-due invoice paid. Dunning is the automated reminder cadence inside it. Dunning automation is mature and effectively commoditized, which is why most collections tools lead with it, and it genuinely clears the invoices that are late because someone forgot. What it cannot touch is the exception queue behind it: invoices under dispute, short payments, payments that arrived but were never applied, active promises to pay, and invoices that never reached the right contact. Each needs evidence read and a judgment made, which is why sending more reminders does not clear it.
Key Takeaways: Dunning is the reminder cadence; collections is the whole process of getting a past-due invoice paid, and conflating them is how teams end up with a healthy cadence and a flat receivables ledger. Reminder sequencing is a solved, rules-based problem. What remains is an exception queue where every item needs evidence gathered and a decision made. Chasing an invoice that is already paid or already disputed costs more than the reminder saves, because it damages the relationship and buries the accounts that would actually pay. Accurate cash application removes the largest single source of those false chases, which makes it the first fix rather than the last.
What collections and dunning actually are
Collections is the accounts receivable work of getting a past-due invoice paid. It covers everything that happens after an invoice goes overdue: working out why it has not been paid, contacting the right person, resolving whatever is blocking payment, and escalating when that fails.
Dunning is one part of that: the scheduled sequence of reminders sent to a customer with an overdue balance. A typical cadence sends a polite notice a few days after the due date, a firmer one at 30 days, and an escalation notice at 60 or 90, each drawn from a template and triggered by the age of the invoice.
The distinction matters because collections software tends to blur it. A product that automates dunning has automated the reminder cadence, which is a scheduling problem. It has not necessarily automated collections, which is a reasoning problem. Conflating the two is how teams end up with an impressive-looking cadence and a receivables ledger that does not move.
Why the reminder layer is already solved
Sending the right reminder at the right time is rules work. If an invoice is more than 30 days past due and the balance is above a threshold, send template B to the billing contact and flag the account for the collector. The inputs are structured, the logic is deterministic, and there is no judgment involved.
Every major AR suite does this, most ERPs do a usable version of it, and the capability is effectively commoditized. It is also genuinely valuable: a meaningful share of overdue invoices are overdue because someone forgot, and a reminder fixes those. Automating that recovers real cash and real collector hours.
But it only works on one kind of customer: the one who intends to pay, is able to pay, and simply has not. Once the reminder cadence is running, those accounts clear quickly. What is left in the queue afterwards is everything that a reminder cannot resolve, and that residue is where collections teams spend most of their time.
The exceptions that actually hold up payment
The accounts still sitting in the aging report after the cadence has run are not there because nobody told the customer. They are there for reasons that each require someone to gather evidence and make a decision.
The invoice is disputed. The customer contests the price, the quantity, the delivery, or the contract terms. Resolving it means pulling the purchase order, the proof of delivery, and the pricing agreement, then deciding who is right. Another reminder is not just ineffective here, it actively annoys a customer who believes they have already raised the issue.
The payment arrived but was never applied. The money is in the bank, the remittance was unreadable or covered several invoices, and the receivable still shows as open. The customer is chased for an invoice they paid weeks ago. This is a cash application failure that surfaces as a collections problem, and it is the single most damaging item on this list because it is both avoidable and visible to the customer.
A short payment or deduction is open. The customer paid most of the invoice and withheld the rest, sometimes with a reason code, often without. Until that gap is investigated and either accepted or recovered, the balance stays open. This is its own discipline; see deduction management for how those are classified and resolved.
There is a promise to pay. The customer has committed to a date. What this needs is a diary entry and a check on the agreed date, not another reminder in the meantime. Cadences that keep firing through a promise-to-pay window are a common and entirely self-inflicted source of customer complaints.
The invoice never reached the right place. It went to a contact who left, or it was missing a purchase order number, or the customer requires submission through a supplier portal and it was emailed instead. The invoice is not disputed and the customer is not unwilling. The document simply is not where it needs to be, and no amount of chasing the wrong address changes that.
The customer cannot pay. Genuine financial distress needs a payment plan, a credit review, and possibly a hold on further shipments. That is an escalation and a commercial decision, not a message.
Every one of these needs the same three things: read the available evidence, work out which situation applies, and take the action that fits. That is judgment work, and it is why the queue does not shrink when you add reminders to it.
What the exception queue costs
The most obvious cost is inflated days sales outstanding. Invoices that are disputed, short-paid, or already paid but unapplied all sit in the aging report looking like slow collections, which makes DSO and receivables turnover read worse than the underlying reality and sends the team chasing the wrong accounts.
The second is misallocated effort. Collector time is finite, and the accounts that generate the most queue noise are frequently not the accounts with the most cash at stake. Without a reliable read on why each invoice is open, prioritization defaults to whatever is oldest or largest, which is not the same as whatever is most collectible.
The third is relationship damage, and it is the one that does not show up in any AR report. Chasing a customer for an invoice they have paid, or for one they have formally disputed, tells them your records are unreliable. Do it repeatedly to a large account and it becomes a topic in the next contract negotiation.
The fourth is margin lost to age. Disputes and deductions that are not worked within the customer's claim window frequently become write-offs by default, not because anyone judged them invalid but because the deadline passed while the item sat in a queue.
What makes this hard to see from the outside is that dunning metrics stay healthy throughout. Reminders sent, delivery rates, and cadence coverage all look fine, because the reminder layer is doing exactly what it was built to do. The number that does not move is cash.
Where automation fits
The useful way to think about this is in two layers, the same split that shows up across accounts receivable automation generally.
The workflow layer runs the cadence: aging buckets, templates, send schedules, escalation rules, and the collections dashboard. This layer is mature, well served by existing tools, and covers most of the transaction count.
The exception-and-reasoning layer handles what is left. For collections that means reading the evidence attached to an open invoice, the remittance advice, the purchase order, the proof of delivery, the email thread where the customer raised an objection, determining which of the situations above applies, and routing to the action that fits: suppress the reminder and open a dispute, apply the payment, log the promise to pay and diarize it, resend to the correct portal, or escalate to credit.
Two properties matter more here than in most finance automation. The first is auditability. A collections action is customer-facing, so the reasoning behind it has to be inspectable after the fact, both to defend a disputed charge and to explain why a reminder was or was not sent. The second is that errors are asymmetric. A missed reminder costs a few days of float. A reminder sent to a customer who has already paid, or a dispute silently written off, costs credibility and margin respectively. That argues for a deterministic, explainable approach over a probabilistic score.
On sequencing, fix cash application first. Unapplied payments are the largest single source of false chases, and clearing them removes an entire category of exception before you build anything else, which is why accurate cash application makes every downstream collections step more effective. Then work the remaining exception classes in order of trapped cash. The reminder cadence, the part most collections projects start with, is the part you should expect to spend the least time on, because it is the part that already works.
If you want to see how Kognitos reads the evidence behind an open invoice, decides why it is unpaid, and takes the next action with a full audit trail, book a demo or try the platform.
