AI Dunning Software: Know When to Stop

AI dunning software should be judged by the reminders it does not send.

That may sound like a strange standard for a product sold on automation. The market is moving toward agents that monitor receivables, draft messages and advance accounts. On 19 August, Oddr announced AI-drafted collection emails and automated follow-up sequences, while keeping its broader Collections Agent in development. On 2 September, Boomi introduced an Agent Control Plane built around governing agent actions and holding high-risk transactions for approval.

Those announcements belong to the same conversation. Once an agent can act, the difficult question is no longer, "Can it write the next message?" It is, "What evidence gives it permission to send?"

My position is simple: AI may interpret the case, but live financial state must control the trigger, the escalation and the stop. A polite message sent after payment is still a product failure.

What is AI dunning software?

AI dunning software helps a business work overdue invoices. It can identify cases that deserve attention, summarize the customer history, classify a reply and prepare an appropriate follow-up. In German workflows, that can span a friendly Zahlungserinnerung, a first Mahnung and a final notice.

The label becomes misleading when every part is described as intelligence. Four different jobs sit behind one email:

The first and last columns are the product boundary. A model can help with ambiguity in the middle. It should not turn uncertain context into a new balance, due date or legal step.

Our broader guide to accounts receivable automation covers the complete architecture, including prioritization and cash application. AI dunning is narrower. It begins when a receivable is late and ends whenever the facts no longer permit contact.

When should an automated reminder stop?

The obvious answer is "when the invoice is paid." Production systems need a more precise contract.

Payment may arrive without a clean reference. One transfer may cover several invoices. A customer may dispute one line but accept the rest. The email address may be wrong. A colleague may record a promise to pay next Friday. The invoice itself may be cancelled or replaced. Each event changes what the system is allowed to do.

A robust send check should therefore read live state immediately before action, not only when the sequence was scheduled. At minimum it should verify:

• the invoice still exists and remains open;
• the outstanding amount is greater than zero;
• no matching payment has closed it;
• no dispute, pause or active promise blocks contact;
• the recipient and approved reminder level are still valid;
• the same action has not already been recorded.

This is why a queue created on Monday cannot blindly send on Thursday. Scheduling creates an intention. Revalidation grants permission.

At Norman, overdue state and reminder history are deterministic. Each sent reminder is recorded with its level and source, so a later policy change does not rewrite what happened. In an agent-led workflow, the agent checks the current invoice state, prepares the reminder and asks for explicit approval before sending. The language can be flexible. The permission is not.

For the German wording and procedural sequence, use a current payment reminder and Mahnung guide. AI should operate inside an approved process, not invent one from a prompt.

Why does one reminder schedule fail?

We reviewed normal paid invoices issued through Norman during the last twelve months. We included only invoices with complete issue, due and payment dates, a non-negative payment term and a clean paid state. More than 1,300 invoices met those conditions, and roughly one in four was paid after its due date.

The late group did not behave like one population:

This is a timing distribution, not proof that a reminder caused payment. It tells us something more useful for product design: a single escalating sequence cannot represent every case. Fewer than half of the late invoices were paid within fourteen days, while more than a third took over a month. The long tail is where missing context matters most.

An agent can help distinguish that context. It can notice that the customer asked for a corrected document, that a promised date passed or that a payment candidate differs by a fee. But the system must preserve the distinction between "the agent found a plausible explanation" and "the ledger confirms the invoice is closed."

What should AI decide, and what should rules own?

Use AI where the output is interpretive and reversible. Use rules where the output changes books, customer relationships or escalation state.

AI is well suited to classifying an inbound reply as a dispute, a request for a copy, a promise to pay or a wrong-contact notice. It can summarize a long thread, translate a draft, suggest a tone and explain why an account moved up the queue. A person can inspect those outputs before they cause harm.

Rules should own the open amount, due date, eligible reminder level, cooldown, duplicate prevention and payment stop. They should also define when a human must approve. If an AI recommendation contradicts the ledger, the ledger wins.

The same boundary applies earlier in the lifecycle. In automated invoice generation, we argue that an agent should earn the right to send only after producing a validated draft. Dunning needs the same separation: generate freely, act conditionally.

The result is not less intelligent. It is an agent with a reliable brake.

How do you evaluate AI dunning software?

Do not begin with a writing demo. Most models can produce a convincing reminder. Begin with a closed historical period and hide the outcomes from the vendor.

Ask the system to reconstruct what it would have done each day. Then compare the proposed actions with the actual payment, dispute and communication timeline. The important errors are not grammatical:

• a reminder proposed after payment;
• an escalation during an active promise period;
• a confident action on an ambiguous match;
• a duplicate send after a retry;
• a legal-sounding step without approval;
• a case left in the queue after the balance changed.

Require a decision receipt for every action: invoice state, outstanding amount, policy version, reminder history, reason, approval state and the timestamp of the final recheck. If the platform can show only the generated email, it cannot explain why that email was allowed to leave.

For cash planning, connect this evaluation to the wider liquidity-planning workflow. An unresolved receivable affects both outreach and forecast confidence. Closing it incorrectly makes both systems look better while making the books worse.

What should you measure after launch?

Measure prevention as deliberately as activity. Sent-message count rewards the system for doing more, even when more is wrong.

I would track five numbers:

1. reminders prevented by a payment or status change at the final check;
2. duplicate actions blocked by idempotency;
3. disputes or promises detected before outreach;
4. cases routed to review because state was ambiguous;
5. time from a meaningful event to the next appropriate action.

Add payment timing by cohort, but do not present it as causal unless you ran a valid experiment. Faster payment can come from customer mix, invoice size, seasonality or better payment methods. A system that sends more emails and happens to collect faster has not proved that the emails did the work.

AI is making dunning more contextual. That is useful. The winning product will not be the one that writes the sternest final notice or automates the longest sequence. It will be the one that can answer, at the moment of action: what is still owed, what changed, why this step is permitted, and what fact would stop it.