Dunning is the sequence of reminders — emails, in some cases calls — that runs on an overdue invoice until the customer pays. Collections automation is software running that sequence on a schedule, drafting the reminders, and stopping the moment payment lands, instead of a person tracking an aging spreadsheet and sending emails manually.
The idea is simple. Two things determine whether it actually works: getting "overdue" right, and getting "paid" right — fast enough that the system stops chasing someone who already sent the money.
Overdue means sent and unpaid — nothing else
The most common mistake in collections tooling is treating every unpaid invoice as overdue, including drafts that were never sent. A draft invoice isn't late — it hasn't gone out yet. Ageing a draft alongside a genuinely overdue sent invoice inflates the AR number and, worse, can trigger a dunning email for an invoice the customer has never seen.
The correct rule: only sent, unpaid invoices age. Everything still in draft or unsent-final status is excluded from collections entirely, no matter how old the record is.
The anatomy of a dunning sequence
A dunning configuration is usually a series of stages, each with:
- A trigger — how many days overdue before this stage fires
- A message template, often with merge fields (customer name, amount, days overdue)
- A channel — email is standard; some tools add SMS or a task for a human to call
Real collections work needs more than a fixed sequence, though. Two behaviors separate a usable dunning system from a blunt instrument:
- A promise to pay pauses the cadence. If a customer says "I'll pay by the 15th," the reminders should stop until that date, not keep firing on schedule and annoying someone who already committed to a date.
- A partial payment reduces the balance, not the urgency. If half an invoice gets paid, the cadence should continue on the remaining balance — it shouldn't reset to "not overdue" or keep chasing the original full amount.
Why bank reconciliation has to feed into it
The fastest way to make a collections tool look untrustworthy is to keep chasing a customer after they've actually paid. This happens constantly when collections and cash application are two separate, disconnected systems: the invoice shows unpaid in the billing tool because the payment landed in the bank and nobody's matched it to the invoice yet.
An unmatched deposit is real cash that already arrived — the moment it's matched to the invoice, dunning should stop. A collections system that doesn't watch bank matching (or doesn't have bank matching at all) will keep sending reminders to people who already wired the money, which is one of the fastest ways to damage a customer relationship over a purely internal process gap.
What to check before trusting a collections tool
- Does overdue strictly mean sent and unpaid — are drafts genuinely excluded from ageing?
- Does a promise to pay actually pause the sequence, or does it just get logged as a note while reminders keep firing?
- Does a partial payment reduce the balance and keep the cadence going on the remainder, rather than resetting or full-stopping incorrectly?
- Is there a direct link to bank matching, so a landed deposit turns off the chase without someone manually flagging it?
- Can cadences be overridden per customer, for the accounts that need a gentler or more aggressive sequence than the org default?
Sonic AI's Watchtower evaluates sent-unpaid invoices only, supports promise-to-pay pauses and partial-payment-aware cadences, and stops chasing the moment bank reconciliation matches a deposit to the invoice — with per-customer overrides on the default sequence. See how collections works, or the deeper mechanics on collections starts after send and Watchtower and dunning configuration.
Related terms: dunning, promise to pay, accounts receivable, days sales outstanding, unmatched deposit.