TL;DR
- Automation is not one thing. A lender’s receivables process has several distinct tasks, and only some of them belong to a machine.
- What should be automated: scoring every account by risk of default, timing and channel selection for contact, and the retraining loop that improves both over time.
- What should stay a human decision: disputes, hardship cases, and anything that ends in legal escalation.
- Where automation breaks in practice: a system built to contact accounts on a schedule, with no override for a customer who has withdrawn consent or raised a dispute.
- What to check before automating: whether the system enforces contact-hour rules by default, logs every automated decision, and lets a human override any single account without switching the whole process off.
- Honest caveat: this piece describes what a lender’s automation boundary should look like, not a certification standard, since South Africa has no published rule that draws this line for AI-driven collections yet.
Automation gets sold as a single switch. Turn it on, and the whole receivables process runs itself. For a South African bank, NBFC, or insurer, that pitch skips the actual question: which parts of the process should run without a person, and which parts should not.
Accounts receivable software covers what the underlying system needs to do. This piece is about the automation decision inside that system, the line between what a machine should handle on its own and what still needs a person to sign off.
What automation means once the receivable is a loan, not an invoice
An invoice-automation tool automates one kind of task: matching a payment to an invoice and sending a reminder when it is late. A lender’s receivables process has more moving parts, because the receivable carries a risk score, a regulatory contact rule, and a customer who may dispute, request hardship terms, or withdraw consent partway through. Automating that process well means automating the parts that are repeatable and leaving the parts that require judgment to a person.
The three tasks that belong to automation
Scoring every account. A model assigns each account a risk-of-default score using repayment history and behavioral signals, refreshed continuously rather than recalculated once a month. This is the task automation does best, because it runs the same calculation across an entire portfolio faster and more consistently than a person could.
Timing and channel selection. Once an account is scored, the system decides when to make contact and through which channel, based on when that specific customer has responded before. A fixed calling schedule cannot do this. A model that learns from outcomes can.
Retraining on results. Every contact and its outcome feeds back into the model, so the scoring improves each cycle instead of running on the same logic indefinitely.
What should stay a human decision
Disputes. The moment a customer disputes the debt or the amount, the account needs a person, not a script. An automated system that keeps contacting a disputed account is a compliance problem waiting to surface.
Hardship and vulnerable-customer cases. A customer who has lost income or is in a debt review process needs judgment a model was never trained to apply. Automation can flag the case. It should not decide the outcome.
Legal escalation. The decision to move an account toward legal action or repossession carries consequences a model cannot be accountable for. That decision belongs to a person, with the model’s score as one input among several.
Where automation breaks down in regulated collections
The failure pattern is consistent: a system built to run contact on a schedule, with no built-in check for a customer who has withdrawn consent, raised a dispute, or fallen into a protected category since the last scoring run. The account keeps getting contacted because nothing in the automation stopped it, and the first anyone hears about it is when the customer complains.
A typical version of this: a customer emails a dispute on a Tuesday, the case sits in a queue for review, and the automated contact schedule keeps running against that same account through Wednesday and Thursday because nothing linked the dispute inbox to the contact engine. No person made a bad decision here. The system had no path for a dispute to reach the process that keeps dialing.
None of this means automation is unsafe. It means the automation needs an override built in from the start, connected to every channel a dispute or a hardship request can arrive through, not added after a complaint forces the question.
What to check before automating your receivables process
A short list separates automation built with these boundaries in mind from automation that was not.
Contact-hour enforcement by default. The system should refuse to schedule contact outside National Credit Act hours on its own, not depend on an agent to check the clock.
A visible override on every account. A single account should be pullable out of the automated flow without switching off scoring or contact for the rest of the portfolio.
Full logging of automated decisions. Every score, every contact, and every model version behind them needs to be recorded in a way an examiner could review later.
A phased rollout, not a single cutover. Automating scoring first, then contact timing, then escalation routing, gives a team the chance to catch a bad pattern before it runs across an entire portfolio.
A single dispute or consent channel that reaches every automated process. If a customer can dispute a debt or withdraw consent through more than one channel, phone, email, a portal, each of those channels needs to reach the same override, or a dispute raised the wrong way keeps getting treated as an ordinary account.
A leading NBFC in India phased its own rollout this way, starting with propensity scoring before extending automation into contact strategy, and reached a 116% improvement in collections recovery with 86% predictive accuracy, deployed in two weeks.
Sources
- iTuring case study, “Improve Collections and Optimize Efforts” (Leading NBFC in India): 116% collections improvement, 86% predictive accuracy, two-week deployment. https://ituring.ai/case-study/improve-collections-and-optimize-efforts/
