A disputed debt is not a forgotten one: debt states, ageing buckets, a promise-to-pay record, escalation paths with owners, and where a person takes over.
Key takeaways
- The first separation is "unpaid" versus "disputed". A disputed debt that receives an automated reminder produces a complaint and freezes the whole payment, including the lines nobody argued about.
- A promise to pay is a record in its own right, with a date, an amount and who promised. Without it you cannot tell whether the customer broke a promise or nobody ever asked.
- Ageing buckets are 1-30, 31-60, 61-90 and 90+, but the action follows the state, not the bucket. A 75-day debt inside an active arrangement is not an escalation case.
- Every path needs an exit to a human. Automation sending a tenth message to somebody who ignored nine is waste and damage at once.
- The metric is not messages sent. It is average time to closure per state, and the number of reminders issued against a debt that was already paid.
Automated collection fails when it treats every open balance as the same thing. A customer who forgot, a customer disputing the amount and a customer in difficulty need three genuinely different paths. The foundation is not a message sequence but a defined state per debt, an owner per state, and a separate record for a promise to pay.
The balance picture before the first message
A reminder is built on a computed balance, not on an invoice amount. Here is a worked customer file, "M. Levi Engineering", as at 14 September:
| Document | Date | Amount | Status | Note |
|---|---|---|---|---|
| INV-2026-0881 | 12.06 | 9,800 | Paid | Receipt 03.07 |
| INV-2026-0944 | 30.06 | 14,200 | Open | Part-paid 6,000 on 05.08 |
| CN-2026-0031 | 14.07 | -2,400 | Credit | Against 0944 |
| INV-2026-1002 | 28.07 | 7,500 | Disputed | Customer disputes two training lines |
The real collectable balance is 5,800 on document 0944 alone: 14,200 less a 6,000 receipt less a 2,400 credit. A system that totals "open invoices" will chase 21,700 - an amount that does not exist - and will include a disputed debt in the demand. The customer replies angrily, the finance person spends an hour apologising, and the genuine 5,800 slips by two weeks.
So the calculation precedes the message: per invoice, sum receipts, credits and adjustments, and only the surviving balance enters the process.
Six states, and every debt sits in exactly one
current- due date not reached. No action.overdue- past due, no dispute, no arrangement. Reminder path.disputed- the customer raised an objection to a line or an amount. Automation stops, an investigation task opens.promised- the customer gave a payment date. Wait until that date, then check.arrangement- a documented instalment or deferral. Tracked against the schedule, not against debt age.handover- the file has left automation for a person or an authorised party. No automated messages.
Transitions are defined: overdue can move to disputed, promised, arrangement or handover. promised returns to overdue when the date passes with no receipt, and that is the only automatic worsening in the model. disputed never returns to overdue without a recorded human decision.
Why must a disputed debt leave the queue?
A disputed debt must leave the queue because the next scheduled message does not answer what the customer asked. They did not forget to pay; they are waiting for a reply. So the dispute record carries four fields:
- What is disputed - a document number and a line number, not "customer unhappy".
- Disputed amount - 3,000 of 7,500, not the whole document. The remainder continues on the normal path.
- Who is investigating - a name, not a department.
- Target date for a reply - an internal commitment that gets measured.
Splitting the amount is the practical point. In the file above, if the customer disputes 3,000 of 7,500, there is no reason for the other 4,500 to stop. Many systems stop the whole document because the dispute flag sits on the document rather than the line - the same resolution problem described in linking quote, order and invoice with one identifier.
A promise to pay as a record, not a note
A promise to pay is the difference between following up and chasing. When a customer says "I will transfer on Sunday", a record is created: promise_id, promised amount, date, the channel it was said on, and who on the customer's side said it. The debt moves to promised and reminders go quiet until that date.
The morning after the date, one check runs: did a receipt arrive for the promised amount. Three outcomes, each with its own action - paid in full and closed, part-paid so a new promise opens on the remainder, or unpaid so the debt returns to overdue with a broken-promise counter incremented. That counter, not debt age, is what decides when you stop accepting promises. A customer who has broken three promises in 45 days is a harder case than one who has been silent for 90 days and promised nothing.
Who handles each bucket, and when a person takes the file
| Days bucket | State | Action | Owner |
|---|---|---|---|
| 1-7 | overdue | Factual message with document number, balance and payment link | Automated |
| 8-30 | overdue | Second reminder plus a short call task | Automated + bookkeeper |
| 31-60 | overdue | Recorded call, instalment offer, review of open orders | Bookkeeper |
| 61-90 | overdue | Summary letter itemising documents, supply-hold decision per policy | Finance manager |
| 90+ | handover | Leaves automation, commercial decision | Management |
| Any | disputed | Investigate and answer in writing, no reminders | The named investigator |
| Any | arrangement | Track against the payment schedule | Bookkeeper |
Holding supply, involving an external party and any legal step are decisions for whoever holds that authority in the business, not for the system. The job of automation is to bring the complete file to the table - every document, every credit, every promise and every conversation - not to decide. This is a process description, not legal or accounting advice.
What do you measure to know this is working?
- Average time to closure per state - days from
overdueto closure, kept separate fromdisputed. - Broken promise rate - promises not honoured over promises recorded.
- Wrong reminders - messages sent against a debt already paid or under dispute. The target is zero and every case is investigated.
- Dispute response time - from the record being opened to a written answer. This is the metric that directly moves the first one.
- Share resolved in the first channel - how much closes after the first message with no human contact.
On the payment channels themselves, a standing authorisation through Masav and an instant payment link behave very differently - the comparison is in Masav direct debits versus card charges, and returns arriving in a return file are covered in updating customer debt from a return file.
Sources
Frequently asked questions
Should reminders go out on WhatsApp?
It depends on what the customer already uses with you and on the consent you hold. The practical difference in collections is not the channel but what the message contains: a document number, a computed balance and one way to pay. A message that says "you have a debt" with no detail produces a phone call instead of a payment.
How many reminders are too many?
The count matters less than the response. If a customer has not replied to three messages across two channels, the fourth will not work and it damages the relationship. The workable rule is that every debt moves to a person after a defined number of unanswered attempts, rather than continuing an endless cycle.
What do you do when a customer pays a round sum with no invoice reference?
This is one of the most common cases. Store the receipt as unallocated and open an allocation task, rather than guessing. Automatically applying it to the oldest invoice looks convenient, but it creates errors precisely in the complicated files - the ones carrying a dispute or a credit note.
Can you start without dedicated software?
Yes, provided a correctly computed balance exists per customer, plus a record for disputes and promises. Start with one table holding states and owners, and add automated sending only once the balances are trustworthy. The reverse order - sending before computing - is exactly what produces reminders about debts that were already paid.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.