When an overdue invoice becomes a problem — and when AI helps

An overdue invoice doesn’t automatically become critical just because its due date has passed. It becomes critical when no one can clearly determine whether the invoice is disputed, a payment promise exists, or the bank details were incorrectly assigned. Many initiatives fail precisely at this point. A practical example of AI in receivables management therefore doesn’t start with a language model, but with a process that defines clear responsibilities, data rules, and controlled exceptions.

In many companies, the dunning process still works like this: Accounting exports a list of open items (OPs), filters by days overdue, and sends reminders in waves. Responses land in the email inbox of individual clerks. Payment promises are noted in free text, if at all. If the customer later pays, the assignment is checked manually. This works for a few cases. Once there are several hundred open positions per month, gaps, duplicate work, and avoidable escalations arise.

Why manual dunning runs overlook the actual case

The due date is just a signal. It doesn’t indicate whether the customer disputed the invoice, whether a partial payment was received, or whether a contact requested an extension. If you dun solely based on the age of the receivable, you treat unequal cases equally. This costs time and can damage a functioning business relationship.

A concrete example: A company processes 1,200 open invoices per month. Of these, 240 are more than seven days overdue. In 65 cases, the customer has already responded. 30 cases include a payment promise, 18 a complaint, 10 involve a missing purchase order number, and seven are actually unanswered. A blanket dunning run sends the same reminder to all 240 contacts. This generates 65 unnecessary messages and shifts the clarification to further emails.

The operational cause is rarely a lack of willingness in the team. Usually, three things are missing: a unified data set, a recognizable case logic, and a regulated handover to humans. AI can close this gap by classifying information and executing prepared steps. It should not decide on its own whether to block a long-standing customer or hand them over to collections.

The practical example of AI in receivables management: From open item to actionable case

The starting point is a connection between the ERP or accounting system, CRM, email inbox, and bank data. A workflow automation pulls open items on a fixed schedule—e.g., daily at 6 AM—and supplements them with available information: invoice number, due date, amount, customer segment, previous dunning level, payments, and known contacts.

Next, a rule set first checks hard facts. Is the invoice already fully paid? Is there a partial payment? Is a credit limit or delivery block affected? Is there an open complaint in the CRM? Such checks don’t belong in free-text interpretation but in traceable queries via integrations/APIs. This is clearer, faster to verify, and easier to correct in case of errors.

Only then does a language model process incoming emails and attachments. It extracts, for example, the invoice number, announced payment date, reason for a complaint, or request for an invoice copy. For documents, document processing can read relevant fields, such as a purchase order number from a PDF. The output isn’t stored as unstructured text but in predefined categories: payment promise, complaint, master data issue, payment proof, general inquiry, or unclear.

In the example, after matching with incoming payments, 212 of the 240 overdue invoices remain. The classification identifies 30 payment promises and 18 complaints. For 112 cases without a relevant response, a friendly reminder is prepared. 40 cases receive no automatic message because the customer is only one day overdue or a support block is recorded in the CRM. The remaining twelve unclear responses go into a worklist.

The result isn’t that no one works anymore. The result is that a clerk assesses twelve unclear cases instead of reviewing 212 emails individually. The metric isn’t the number of dunning notices sent. It’s the processing time per case, the share of correctly assigned responses, and the time until an exception is resolved.

Which decisions can be automated

Steps with clear criteria and limited risk should be automated. These include matching incoming payments with invoices, generating a reminder based on approved text, requesting a missing purchase order number, or categorizing a response into a queue. Even a Voice Agent can prepare a callback or remind about a payment deadline for small, clearly defined amounts—provided the communication, escalation limits, and documentation are set.

The situation is different for complaints, installment agreements, disputed receivables, or account blocks. Here, human-in-the-loop is necessary: The system summarizes the facts, suggests the next step, and presents the case to an authorized person. The approval is logged with timestamp, basis, and decision. This is pragmatic and prevents a misclassification from continuing automatically.

The operational setup starts with exceptions, not prompts

Many teams begin by asking which prompt should write a dunning email. The better first question is: Which cases should never be sent automatically? This defines the exception-handling logic.

A robust process defines at least the blocking reasons, approval limits, and escalation paths before launch. Blocking reasons can include an open complaint, a negative balance, an active payment agreement, or a strategically managed customer. Approval limits apply, for example, to amounts over €10,000 or cases from dunning level three. Escalation paths specify whether finance, sales, or customer service must respond within one business day.

Next comes a limited pilot. A segment with comparable cases is useful—e.g., B2B invoices in one currency and one dunning level. For four weeks, the system first runs in suggestion mode: It classifies responses and creates drafts, but a team member approves everything. During this time, compare at least 50 to 100 cases with human judgment. If the categories don’t match reliably, correct data fields, rules, or examples instead of rolling out the automation more broadly.

Data quality also matters. If invoice numbers are only in the subject line, customer names are written inconsistently, and payment references are missing, no automation can assign them cleanly. Then the process must first establish rules for references, invoice copies, and CRM maintenance. This isn’t a big strategic question—it’s concrete operational work.

How to measure whether the operation holds up

After the pilot, a few metrics count more than an impressive demo. Measure the share of automatically assigned incoming payments, the rate of correctly classified responses, manual processing time, and the number of incorrectly triggered reminders. Don’t isolate DSO (Days Sales Outstanding), as it also depends on payment terms, sales, and customer structure. More meaningful is, for example, whether overdue receivables in the selected segment decrease after 30 days without an increase in complaints.

Reconciliation is mandatory. Daily, it must be traceable which open items were imported, which cases received a message, which response came in, and what resulted from it. Discrepancies between bank, ERP, and workflow must not disappear into a catch-all inbox. They belong in a visible exception queue with a responsible person and deadline.

Monitoring complements this control. It checks whether interfaces deliver data, whether the email inbox is accessible, whether an unusually high number of cases land in the “unclear” category, and whether a dunning run started outside the scheduled time. For critical processes, uptime/SLAs, alerts, and a manual fallback are essential. If the system fails, it must be clear who stops the run, which list is authoritative, and how to avoid duplicate messages.

Reliable operation means: Responsibility remains visible

Receivables management isn’t a suitable area for a bot that’s set up once and then ignored. Incoming payments, customer data, dunning texts, and business rules change. Therefore, the operation requires a functional owner in finance, a technical owner for integrations, and fixed review intervals—e.g., weekly for exceptions and monthly for metrics.

CINDR.LA views such automations as ongoing operational systems: with documented rules, monitoring, adjustments, and a person who acts on deviations. This avoids surprises. Above all, it’s always clear why a case was processed automatically, why it was stopped, and who takes the next step.

Don’t start with all open receivables. Take a clearly defined dunning segment, define the exceptions, and measure for four weeks against the previous process. If assignment, approvals, and reconciliation work cleanly, a reliable operation grows from it—not just a convincing prototype.