What to Get Right Before AI Chases Your Late Payers

Open the aged debtor report on a Friday afternoon and the pattern is usually the same. The small overdue balances have been chased twice. The largest one, the account everybody in the business knows by name, has not been chased at all.

That is not a discipline problem, and it is not fixed by a tool that sends more email. It is fixed by deciding in advance who gets chased, when, in what words, and who takes over when the conversation stops being routine.

Why the largest debt gets chased last

Chasing is discretionary work inside a role full of non-discretionary deadlines. Payroll has a date. The VAT return has a date. Chasing has a queue, and a queue with no owner gets worked when somebody has a quiet afternoon.

The second mechanism costs more. Awkwardness scales with the size of the relationship. A small balance from an account nobody has met is easy to chase. A large one from a major customer, where the account manager is mid-renewal, is not, so it slips down the list every week. The oldest and most sensitive debt gets the least attention.

Chasing is relationship work, which argues for structure rather than against automation

Nervousness about automating this is correct, usually a worry about what a machine might say to a good customer. But wording, timing and any decision to press harder are judgement calls, while knowing which invoices are overdue, whether anything has been queried against them and who owns the account is record-keeping. That second half is where the process actually fails. The alternative to structure is not a careful human process, it is an unstructured one, where the wording depends on who is writing and how their morning has gone.

What a receivables system can genuinely do

Receivables preparation is one capability in our AI for Business Operations pack. Preparation is the operative word, and the list is deliberately narrow:

• read invoice, payment and allocation status on a schedule, so the picture is current rather than a Monday export;
• queue overdue items by age, value and account owner, so the sequence comes from the ledger rather than from wherever somebody started;
• check whether a query, credit request or dispute has been logged against an invoice before anything is prepared;
• draft a chaser from wording your finance lead has approved, with the reference, age and payment detail correct;
• route material, aged or sensitive accounts to a named person, history attached.

Dispute detection is the least obvious part and the most valuable

Chasing an invoice the customer has already queried is how a late payment turns into a lost account. They raised a delivery shortfall three weeks ago, got no reply, and now receive a reminder that ignores it. Not a rude message. Worse, because it tells them nobody is reading.

The dispute is rarely recorded where the debt is. The invoice sits in the finance system, while the query sits in a shared mailbox, a note on the deal, a service ticket, or a conversation nobody wrote up. Anything reading only the ledger sees none of it, so it chases confidently and wrongly. Catching it before a chaser is prepared, and holding that account until a person has dealt with the query, is the most valuable thing here.

One record, not four

A separate receivables platform keeps its own copy of your customer data. Invoice status then lives in one place, the dispute flag in another, the relationship in a third and the audit trail in a fourth, and reconciling the four becomes somebody's job. Built into the finance stack and CRM you already run, they are one thing: status from the ledger, the dispute flag from wherever your team logs queries, context from the CRM record.

Our integration library covers the usual finance stack, including Xero, Sage 200, Microsoft Business Central and NetSuite. The full integration library lists the rest. Naming a system is not a claim about what it will do for your edition or estate, which discovery establishes first.

The escalation ladder is designed, not learned

The ladder is a written artefact. Your finance lead sets the stages, the wording and the thresholds, and your finance lead changes them. The system does not adjust tone, wording or frequency on its own, at any stage, for any account.

Written down, a ladder can be reviewed and applied consistently when somebody is on leave. The version living in two or three heads cannot.

Where the approval line sits

Each action carries its own permission, written down before release. The table below is that map for receivables, where the steady state is draft or recommend, permanently.

One row gets argued about. A person sends anything a customer reads, at every stage including the courtesy reminder before the due date. The system monitors, queues, checks for disputes and drafts. That is strict on purpose, and it is what lets you point this at your largest account rather than only the ones you would not mind annoying.

Tone and frequency are restricted for the same reason: they cause most of the damage and are the last to be noticed. A chaser that reads as a threat costs you a customer and creates a problem your finance director has to explain.

What depends on who the debtor is

Whether chasing a given debt carries a regulatory obligation depends on who owes the money. A limited company customer and a sole trader are not the same case, and your own terms and customer base affect the answer. SpotDev gives no financial, tax, legal or accounting advice, and we do not advise on regulatory classification. Your own legal or compliance advisers do that, and the workflow we build reflects the boundary they set rather than one we assumed.

In practice those constraints arrive as configuration: which segments are in scope, what wording is approved, and which accounts never enter a queue. Automated or recorded-message calling is outside what this capability does.

Every message traceable to why it was sent

The log is what lets you answer a customer who says they were chased twice in a week while their query sat unanswered. Against each invoice you should be able to see what was prepared and when, which approved wording was used, what the dispute check returned, who sent it, and what came back.

Reconciliation is the other half. Payment and allocation status are read back, so an invoice that has been paid or credited leaves the queue immediately. Chasing an invoice settled last Thursday does more damage than not chasing at all, and it is a data problem rather than a judgement one.

How you would know it is working

We do not publish a debtor-days improvement figure, because a number quoted without your ledger behind it is marketing. The baseline comes from your own data, and the measures reported back are:

• the proportion of overdue value carrying a named owner and a dated next action;
• time from due date to first contact, and how consistent it is across the ledger, largest accounts included;
• the number of chasers that reached an account with an open query, where the design target is none.

Time saved in finance is not reported as cost reduction. It is not the same thing, and we would not want you to buy on that basis.

The next step

We build AI that works inside the systems you already run. Receivables preparation is one capability in the business operations pack, one department inside our 12-month AI transformation programme, bought a quarter at a time. A standard wave activates two production agents in one department, so the pack is a catalogue of what can be covered rather than a list of what is included.

Before committing to that, start with one of our short, fixed-scope assessments. Each shows where to invest first and the roadmap to get there. For receivables that means establishing where invoice status, dispute signals and account ownership actually live today, which decides whether this can be built well. No guesswork, no obligation. Operations is usually the last department in a programme, and the sequencing argument explains why.