Accelerating dunning with AI: why automation fails if only the dispatch is automated

An open item is due on Monday. The first reminder goes out on Friday because someone has to update an Excel list, check incoming payments, and select text modules. On the same day, a complaint already lands in the inbox via email. This is where accelerating dunning with AI fails if only the dispatch is automated: the wrong message reaches the wrong case.

The problem is rarely the language model. It’s the process between due date, payment, complaint, contact person, and next action. If this information is scattered across ERP, accounting, CRM, and email, an automated dunning run only speeds up the existing chaos. To put it clearly: first, it must be clear which case deserves which treatment. Then AI can reliably assist.

Why dunning runs get stuck manually despite ERP

An ERP usually knows the invoice number, due date, and open amount. For a correct next step, these three values are often not enough. Was the payment instructed yesterday but not yet posted? Is there a credit note? Has the customer disputed the invoice on factual grounds? Is there a documented payment promise? Or is it a strategic customer where the responsible account manager should be involved first?

In a typical case, an invoice for €8,400 is 21 days overdue. The system marks it as overdue and prepares the second reminder. Meanwhile, the customer wrote two days earlier that an item worth €1,200 was missing from the invoice. If this email is not assigned to the case, the company dunts the total amount. This doesn’t just cost time in clarification. It creates an avoidable conflict that finance, sales, and customer service then have to resolve manually.

The data basis is also often unclear. A debtor number may be correct in the ERP, while the CRM still lists an old contact person. Bank transactions arrive in batches and are only assigned later. Email replies sometimes contain invoice numbers in the subject line, sometimes only in the attachment, and sometimes not at all. Without data reconciliation and exception handling, no system can reliably decide whether to dun, pause, or escalate.

The relevant question is therefore not: Can AI formulate a friendly reminder? It is: Can the process determine for each case in a traceable way why an action was triggered or suppressed? For finance management and executive leadership, this is measurably more important than an especially elegant text.

Accelerating dunning with AI: first rules, then automation

A robust process starts with case logic. It defines which events trigger a dunning step, which events block it, and who decides on exceptions. This doesn’t require months of conceptual work. An operational workshop can convert the existing dunning levels, approvals, data sources, and special cases into a verifiable process.

1. Clearly define the status of each open item

The process needs a leading status per invoice. For example: open, payment announced, payment in clarification, complaint open, reminder prepared, reminder sent, handed over for further processing. What matters is not the label but the rule behind it.

A complaint doesn’t simply set the status to “completed.” It only pauses the disputed amount or the entire case, depending on your specifications. A payment receipt only closes the invoice after reconciliation with amount, purpose, and debtor. If the system cannot assign a transfer with sufficient certainty, it ends up in a clear checklist instead of automatically in the dunning run.

This turns Excel tracking into a workflow with visible states. Each status change receives a timestamp, source, and triggering rule. This is useful for internal inquiries as well as for later audits.

2. Make information from emails and documents usable

Here, AI has a concrete task: it reads incoming emails, recognizes invoice number, amount, payment date, or reason for complaint, and suggests a classification. For attachments, document processing can extract relevant fields such as invoice number, order number, or disputed items.

The suggestion is not automatically a decision. A message like “Transfer will be made next week” can, for example, be recognized as a payment promise and assigned to the correct case. If the invoice number is missing or the sender mentions multiple invoices, the case goes to an employee. This is human-in-the-loop: people check specifically the cases with low assignment certainty instead of reading every message from the start.

In practice, this review needs fixed boundaries. With a clear match from invoice number, email domain, and amount, the workflow can record a payment promise. If the amount differs, there are multiple candidates, or a complaint term is detected, no reminder is sent before someone confirms the case. This keeps the process pragmatic without questionable full automation.

3. Execute dunning levels as controlled actions

Once status and blocking reasons are clear, workflow automation can take over the routine. It checks open amounts on defined days, considers payment terms, and creates the appropriate communication. Integrations/APIs connect ERP, CRM, email, and, if necessary, the accounting system so that the processing status doesn’t have to be updated in four applications.

The texts themselves should come from approved modules. AI can insert salutation, invoice data, payment link, or reference to a documented promise. It should not invent legal formulations or change deadlines. Dunning texts, escalation rules, and goodwill limits belong to an approval by finance and, where necessary, the legal department.

Escalation is also rule-based. After a first reminder, the case can rest for about five working days if a payment promise exists. If this deadline expires without a payment receipt confirmed by reconciliation, the system creates a task for the responsible person. For a disputed amount, communication remains paused until the specialist side has decided. The procedure depends on your business model, contract terms, and customer volume—not on a general AI preset.

Which metrics show whether the process holds

“Faster” is not a sufficient control variable. Measure at least the time from due date to the first action, the share of automatically assigned responses, the number of paused cases, and the rate of manually corrected assignments. Additionally, the time until reconciliation shows whether payment information actually arrives where it’s needed.

An example: If out of 200 incoming responses per month, 140 are clearly assigned to an invoice, 60 cases remain for review. If the number of misassignments doesn’t decrease after four weeks, the error usually lies in incomplete master data, inconsistent subject lines, or overly broad assignment rules. The monitoring then provides a concrete to-do list instead of a general assumption.

Exception cases also belong in the reporting. How many reminders were stopped due to complaints? How often was a payment promise not kept? Which debtors cause recurring manual clarifications? These numbers don’t just help dunning. They show sales and operations where invoice creation, handover, or customer communication need improvement.

Operations determine trust in dunning

A workflow built once doesn’t automatically remain correct. New dunning levels, changed ERP fields, a different bank reference, or a new email inbox can change assignments. That’s why the system needs operational management: monitoring for failed integrations, logs for status changes, clear responsibilities for exceptions, and defined response times for disruptions.

At higher volumes, uptime/SLAs are relevant because a failed retrieval of payment receipts can directly trigger incorrect reminders. A secure process stops the dispatch instead of continuing with incomplete data. This is not a comfort function but a protective rule with clear effects.

CINDR.LA builds such processes not as a presentation but as a system with operations, monitoring, and traceable handovers. However, your process responsibility remains decisive: Who may change rules, who checks exceptions, and who sees the cases that couldn’t be decided automatically every day?

A good dunning system doesn’t have to solve every special case automatically. It must consistently handle the routine, make uncertainty visible, and involve people exactly where their judgment is needed. Then acceleration becomes measurable, the process remains reliable—and for customers, finance, and management, there are no surprises.