← Back to Blog
Dunning agent: automating collections follow-up with AI
AI Agents

Dunning agent: automating collections follow-up with AI

byBruno Galo · Published on 19 Oct 2025

Last updated 12 Aug 2026

Available inCatalàEnglishEspañolPortuguês

Most mid-market companies in Iberia carry more overdue receivables than they need to, and the reason is almost never that nobody knows which invoices are late. The ageing report is accurate and available. What is missing is the labour to act on it consistently.

A credit controller managing several hundred open accounts can realistically chase perhaps thirty to fifty in a week with any care. The remainder receive a generic statement or nothing at all. So follow-up becomes a function of the controller's available hours rather than of which accounts actually warrant attention — and the accounts that get chased are usually the largest balances, not the ones where a small intervention would have prevented a slide from thirty days to ninety.

This is close to an ideal case for an agent: high-volume, rule-bound, repetitive, and currently rationed by human capacity. It is also the finance process where automation carries the most relationship risk, because the counterparty is a customer, the tone of a message is part of the commercial relationship, and an aggressive dunning sequence sent to the wrong account can cost more in revenue than it recovers in cash.

Why this matters

The direct cost of slow collections is working capital. A company with meaningful monthly revenue and receivables running above terms has cash sitting in customers' bank accounts rather than its own, and in a higher-rate environment that carry has a real and calculable cost. Reducing average days to payment even modestly releases cash permanently, not once.

The indirect cost is worse and less visible. Inconsistent follow-up teaches customers what your actual terms are. A customer who pays at seventy days on thirty-day terms and receives no consequence has correctly inferred that your terms are seventy days. That inference spreads within their AP department and is difficult to reverse, because reversing it requires a conversation that now feels like a change in the relationship rather than the enforcement of an existing agreement.

There is a forecasting dimension too. Collections that depend on individual effort produce cash inflows that cannot be forecast, because the driver is a person's workload rather than a process. A consistent dunning process makes cash collection predictable, which is often more valuable to a CFO than the improvement in the average itself.

At a glance: what the agent does and what it must not

Activity Agent-suitable Why
Identifying accounts crossing an ageing threshold Yes, fully Deterministic, rule-based
Sending a first and second reminder Yes, with approved templates High volume, low judgement, low risk
Matching a customer payment to open invoices before chasing Yes Prevents the most damaging error — chasing paid invoices
Detecting a disputed invoice and suppressing chase Yes, if dispute status is recorded Requires the data to exist; the agent cannot infer a dispute from silence
Escalating tone at defined ageing stages Partially Escalation logic is rule-based; the escalated message itself needs human-approved wording
Deciding to place an account on credit hold No Commercial decision with revenue consequences
Negotiating a payment plan No Judgement, relationship, and often a legal dimension
Contacting a strategic account No, route to a named owner The relationship cost of a wrong tone exceeds the cash benefit
Legal escalation or third-party collection No Requires human authorisation and, in Spain and Portugal, procedural care

The pattern is consistent with every agent deployment worth doing: the agent absorbs volume and consistency, humans retain judgement and relationships. The boundary is not drawn by what the technology can do — it is drawn by where a mistake becomes expensive.

What works, and what to be honest about

What works:

Payment matching before every chase. The single most damaging collections error is chasing an invoice the customer has already paid, because it signals that you do not know your own books and it gives a genuinely late customer a defensible reason to disregard future chases. An agent that reconciles receipts against open items immediately before generating any reminder eliminates a class of error that manual processes commit constantly.

Segmented cadence rather than one sequence. A new customer at fifteen days overdue, a fifteen-year account at five days, and a repeat late payer at forty-five days need three different treatments. Human controllers know this and apply it inconsistently. An agent applies segmentation reliably once you have defined the segments — which is the actual work.

Contact-level targeting. Reminders sent to a generic address achieve far less than reminders sent to the person who processes invoices. An agent that maintains AP contact detail per customer and routes accordingly improves response substantially, and this is precisely the kind of maintenance humans deprioritise.

Full logging. Every touch recorded, with timestamp and content, visible to the sales owner. This resolves the most common internal objection to automated dunning — sales discovering that a customer was chased without their knowledge — by making it transparent rather than by asking permission each time.

What to be honest about:

Automation will expose your data quality immediately and publicly. If your ageing is wrong, if credit notes are unapplied, if partial payments are unallocated, a dunning agent will send incorrect chases at scale to real customers. Clean the ledger first. This is not a caveat, it is a prerequisite, and it is the reason we decline to deploy dunning agents on unreconciled receivables.

Not every late payment is a collections problem. A substantial share of overdue invoices in mid-market B2B are late because of a defect upstream — wrong PO reference, invoice sent to the wrong entity, missing documentation, a delivery dispute. Chasing these harder does not accelerate payment; it annoys a customer who is waiting for you to fix something. Categorise your overdue population before automating, and expect a meaningful fraction to be invoice-quality issues rather than payment behaviour.

Tone does not survive templating well. Templates that read as reasonable in isolation read as mechanical in sequence, particularly by the third message. Have someone commercially senior write and approve every message in the ladder, and re-read them as a sequence rather than individually.

Strategic accounts must be excluded by design, not by exception. The excluded list should be maintained deliberately, reviewed quarterly, and owned by someone in sales. Relying on the agent's judgement about relationship importance is a category error.

The measurable gain is usually in consistency, not aggression. Companies expecting dramatic recovery from harder chasing are usually disappointed. Companies that simply chase everything, on time, every time, tend to see the improvement — because most of their prior underperformance was accounts never contacted at all.

Decision framework: deciding whether and how to deploy

Run in order. Stop at the first match.

1. Is your receivables ledger reconciled, with payments and credit notes applied promptly?
If not, stop. Fix this first. Automating chases against an inaccurate ledger damages customer relationships at speed and is the most common way this project fails.

2. Do you know why your overdue invoices are overdue?
If not, categorise a representative sample by root cause — invoice defect, dispute, process delay at the customer, genuine payment behaviour. Only the last category is a collections problem. The others need fixing upstream, and automating chases against them makes things worse.

3. Do you have defined customer segments with different treatment?
If not, define them before building anything: by relationship value, payment history, size and strategic importance. The agent's cadence rules are a direct expression of this segmentation, so it cannot be built without it.

4. Do you have accurate AP contact details per customer?
If not, this is the highest-return preparatory work available. An agent chasing generic mailboxes underperforms substantially, and contact capture can run in parallel with everything else.

5. Are your escalation ladder and message wording approved by someone commercially senior?
If not, get that done before go-live. Wording is not an implementation detail here; it is the product.

6. Are all of the above in place?
Deploy, but start narrow: one customer segment, first and second reminders only, human review of the outbound queue for the first two weeks. Widen once you have seen what it actually sends.

7. Deployed and working, still above target on days to payment?
The remaining constraint is likely credit policy or terms at the point of sale, not follow-up. That is a commercial conversation, not an automation one.

Indicative cost and effort

Workstream Typical elapsed time Effort profile
Receivables ledger reconciliation and clean-up 3–10 weeks Medium to heavy — depends on backlog
Root-cause categorisation of overdue population 2–3 weeks Light — analysis
Segmentation design and treatment rules 2–3 weeks Light, requires sales and finance agreement
AP contact data capture and enrichment 3–8 weeks Medium — often ongoing
Message ladder drafting and approval 1–2 weeks Light, politically sensitive
Agent build, integration and logging 4–8 weeks Medium
Supervised pilot on one segment 3–4 weeks Light — monitoring
Widening to full receivables population 2–4 weeks Light

Assumes a single ERP instance with receivables in one system. Multiple billing systems, or a customer base with complex group hierarchies, extend this. Get a quote for a scoped estimate.

Frequently asked questions

Will customers be able to tell the reminders are automated?
Some will, and it matters less than expected — AP departments receive automated reminders routinely and largely do not mind. What they do mind is inaccuracy, chases for paid invoices, and messages that ignore an open dispute. Get those right and the automation itself is not the issue.

How do we prevent the agent chasing an invoice under dispute?
The dispute must be recorded as data. An agent cannot infer a dispute from an email thread or a phone call that was never logged. This usually means the dispute-logging discipline has to improve before deployment, which is a process change with its own timeline — and it is frequently the real blocker on these projects.

Should the agent handle payment plans?
No. It can detect that a customer is a candidate for one and route the account to a human with the relevant history attached, which is genuinely useful. Negotiating terms is a commercial and sometimes legal act and belongs with a person.

What about GDPR?
Collections correspondence processes personal data — the AP contact's name and business contact details — under legitimate interest in most cases, but the retention of communication logs, and any automated decision-making that materially affects a person, need consideration. Where a customer is a sole trader rather than a company, the data protection position is different. Get this reviewed rather than assumed; it is not onerous but it is not nothing.

How quickly does this pay back?
Faster than most agent deployments, because the benefit is cash rather than efficiency. In our experience the gating factor is almost never the build — it is the ledger clean-up and dispute-logging discipline that precede it, which is where the elapsed time actually goes.

How quickly can the underlying data connection be built?
The sync between CRM, billing and the agent's own data can be live within weeks through a certified partner like Stacksync. What takes longer, and what actually determines whether the agent works, is agreeing the escalation and dunning-policy rules described above — an agent connected to real-time data but running an undefined policy will just be fast and wrong.

Closing — Next steps

A dunning agent is the clearest agent business case in finance, and also the one most often deployed prematurely. The technology is straightforward. The prerequisites — a reconciled ledger, recorded disputes, agreed segmentation, approved wording, a maintained exclusion list — are the entire project, and each of them has independent value even if you never automate anything.

Practical first step: pull your overdue population and categorise a sample of it by root cause. If most of your overdue balance turns out to be invoice defects and unlogged disputes rather than payment behaviour, you have learned that your collections problem is actually a billing problem — which is a more valuable finding than any dunning sequence.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

Comments

No comments yet.

Leave a comment

Your comment will be reviewed before publishing.

An unhandled error has occurred. Reload 🗙