Short answer: receivables is where AI over Business Central pays back fastest. The data is already structured, the question repeats weekly, and the work is comparing a customer's current behaviour against their own norm — which people do badly and systems do well.
Why ageing is not enough
An ageing report sorts debt into buckets: under 30 days, 30–60, over 60. The problem is that a bucket says nothing about risk. A customer who always pays on day 45 and is currently on day 45 sits in the same bucket as one who paid on time for two years and has now been silent for forty days. The first is a payment terms question. The second is something to act on today.
Telling them apart requires per-customer payment history. Computing that by hand across two hundred customers does not happen. That is where AI gives something a report cannot. The underlying process is covered in receivables control; the AI layer changes who can ask the question and how fast.
Payment behaviour change
The single most valuable signal in receivables. The assistant computes each customer's typical delay and then looks for deviation from that, rather than from the contract date.
| Signal | What it usually means |
|---|---|
| Delay grew from 5 to 30 days | Liquidity trouble or a document dispute |
| Started paying in instalments | Stretching payment before saying so |
| Paying but ordering less | Moved to a competitor, settling old balances |
| Order volume up sharply plus delay | The most dangerous combination |
The last row deserves attention. A sharp rise in purchases from a customer who has simultaneously started paying late is a classic precursor to a large loss. It is nearly invisible in a report, because each figure on its own looks fine.
How the call list is built
Sorting by amount or by days produces a list that does not reflect risk. A working order is built from three components: deviation from the customer's own norm, the amount at risk including what is already shipped or promised on open orders, and combined signals like the one above.
The difference from a fixed report is that the criterion can change mid-conversation: "same list but only customers without an active supply agreement" is a new question, not a new report configuration.
The assistant should explain why each customer is on the list. A list without explanations gets read for two weeks and then ignored.
What to hold
Overdue debt means something different when the customer has open orders waiting to ship. That is a join between two tables which standard reports usually do not make, and it produces the most actionable answer: not "who owes us" but "what are we about to ship to someone who has stopped paying".
Business Central can block shipment on credit limit, and that is worth configuring regardless of AI. The assistant is useful in the grey zone: where the limit is not formally breached but behaviour has already changed.
Where the agent starts
Everything above is read-only. An AI agent adds preparation: drafting reminders referencing specific documents, submitting approval requests for extended terms, updating the next contact date.
The boundary here is firm and not for technical reasons. Decisions about credit, terms and escalation are commercial. The agent prepares; a person decides. We do not build agents that change credit limits on their own, and not because it is impossible.
One design detail that matters in practice: the agent needs to remember that it already contacted a customer this week. Between runs it remembers nothing by default, so that state has to be built deliberately — best as a field in Business Central, where it stays visible to people.
How to tell whether it works
Two numbers, both worth recording before launch because they cannot be reconstructed afterwards.
How many prepared reminders a person discards. This is the quality measure. If half get discarded, the assistant is creating work rather than removing it, and the reason is usually a missing exception rather than a technical fault.
Average days to payment, three months in. This is the value measure. If it has not moved, the list is being produced and not acted on — which is a process problem, not a tooling one. Seeing a problem and resolving it are different actions, and the second does not happen automatically.
A third, softer signal: whether the collections list is still being opened after a month. Tools like this are rarely rejected loudly. People simply stop using them, and that shows up in usage before it shows up in complaints.
What has to be configured
- Payment terms on customer cards. Without them "overdue" is calculated from the document date, which is wrong for anyone with individually agreed terms.
- Payments applied to documents. Unapplied payments mean no payment behaviour history can be built.
- A way to mark disputed amounts. If there is none, this is the first thing to add.
- A field for last contact date, so the agent does not repeat itself.
The third point is the most common reason lists like this stop being used: one awkward call to a customer who was in the right, and trust in the tool is gone.
A useful preparation exercise: ask whoever currently handles collections to name five customers they would not chase despite overdue balances, and why. That is your exception list, and getting it out of someone's head in an hour is cheaper than discovering it one case at a time in production.
Frequently asked questions
How is this different from a standard ageing report?
A report sorts debt into buckets. AI compares a customer's current behaviour with their own norm and adds context: open orders, history, volume changes. A customer who always pays on day 45 and one who has just slipped to 40 look identical in a report and are different situations.
Can the system send reminders to customers itself?
Technically yes, within the permissions granted. In practice we recommend the agent drafts and a person sends, at least until it is clear how the wording lands with your customers. A wrong reminder costs more than a minute of review.
What about disputed amounts?
They need marking in the system, otherwise a customer with a legitimate complaint ends up on the collections list. This is the most common reason such lists stop being used.
Does AI predict who will not pay at all?
It surfaces signals that historically preceded problems: behaviour change, partial payments, volume growth alongside delay. That is a watchlist, not a probability forecast.
How long does a receivables-specific implementation take?
It is a narrow, well-defined scenario, so usually faster than average: two to three weeks after discovery to a working prototype, provided payment terms are filled in and payments are applied to documents.