Debt Should Not Become a Problem Only After the Money Has Been Missing for Too Long
A table with columns for customer, amount, and debt can reveal a problem, but it does not always help manage it.
One customer still has ten days before payment is due. Another is two days late but has already confirmed a payment date. A third has not replied for several weeks. A fourth paid half. A fifth disputes part of the invoice.
Technically, all of them have accounts receivable. But the next action is different in every case.
I would therefore manage not only the debt amount, but also the state of the work around that debt.
What I Would Want to See for Every Receivable
Some of this data can come automatically from the sale, invoice, or payment. People should not have to reconstruct it before every customer call.
What Created the Debt
The order, shipment, invoice, service act, or another transaction that created the amount due.
How Much Remains
Not only the original amount, but the current balance after partial payments, corrections, or returns.
When Payment Is Due
The due date or the business rule that determines it.
How Overdue It Is
The overdue period matters separately from the amount because it changes the priority of work.
What Has Already Been Agreed
A promised payment date, agreed partial payment, dispute, or another arrangement with the customer.
Who Owns the Next Action
Sales, finance, management, or another role should see the next action they are responsible for.
How I Would Design the Accounts Receivable Flow
Not every company needs the same workflow. But I would separate normal payment terms from overdue debt, payment agreements, and genuinely problematic receivables.
Payment Obligation Created
After a sale, shipment, or another event, the system knows the amount, customer, and payment terms.
Payment Expected
Before the due date, the amount is not necessarily a problem. It simply needs to be visible as an expected inflow.
Due Date Approaching
Where useful, the customer or responsible manager can receive a reminder before the payment becomes overdue.
Payment Overdue
The receivable enters a state that requires a concrete action instead of merely appearing in a report.
Customer Contact Recorded
The outcome of a call or message becomes part of the debt workflow instead of remaining only in the manager’s private chat.
Payment Agreement Recorded
If the customer promises a specific date or partial payments, the system knows exactly what is now expected.
Payment Received Partially or Fully
Actual payment reduces the outstanding balance without manual recalculation.
Agreement Missed
If the promised date passes, the debt becomes an active exception again and can move to a higher level of attention.
Debt Escalated
A significant amount, long delay, or repeated broken promises may require management or another responsible role.
Receivable Closed
Full payment, an agreed correction, or another final financial outcome closes the process while preserving its history.
| Situation | What I Would See | Next Action |
|---|---|---|
| Due date has not arrived | Expected amount and date | Wait or remind before the due date |
| Two days overdue | Amount, customer, responsible person | Verify payment and contact the customer |
| Customer promised payment tomorrow | New promised date recorded | Do not chase daily, check after the agreed date |
| Partial payment received | Actual remaining balance | Work only with the remaining amount |
| Part of the invoice is disputed | Disputed and undisputed amounts | Do not treat them as one status |
| Several promises were missed | History of payment commitments | Increase the level of attention |
Automation here does not necessarily mean sending ten identical reminders to the customer automatically.
I would start with something simpler: the system detects approaching due dates, overdue amounts, partial payments, and broken payment promises. It can create a work list for the responsible person or surface a specific case.
Communication can still remain human. For an important customer, a manager’s call may be much more appropriate than an automated email.
The best automation target is often control and repetitive checking, not necessarily the customer relationship itself.
I would not show management only one number: "customers owe us this much".
It is more useful to see the structure: how much is still within normal payment terms, how much is overdue, which amounts have been overdue for a long time, where payment promises were missed, which customers accumulate debt repeatedly, and how much cash depends on a few large debtors.
Accounts receivable then stops being a number reviewed at month-end and becomes a process that can be managed every day.
A Few Questions About Accounts Receivable
The most valuable part is not another report, but a clear next action for each situation.
Should all accounts receivable be treated as a problem?
What about partial payment?
Should customers receive automatic payment reminders?
What if the customer promises to pay later?
How should a disputed amount be handled?
Where should improvement begin?
How I Would Design This Business Process
In this series, I break down a real business process step by step: which facts should be visible, where human judgment matters, and what repetitive manual control can be removed.
Does Your Debt List Also Fail to Show What Needs to Happen Today?
Take a few real receivables and check whether each one clearly shows the due date, latest agreement, responsible person, and next action. If you need to ask sales and accounting to reconstruct that information, the problem is already larger than the report.
