The problem
The objective was to reduce overdue receivables in the Support & Services department. The instinct in that situation is to chase harder, and it is usually wrong: by the time an invoice is genuinely old, the reason sits upstream of collections, and chasing produces activity rather than cash.
The first question was therefore not who owes us money, but what is actually overdue. A ledger of unpaid invoices is not the same thing as a ledger of debts, and separating the two was the whole of the first phase.
What we did
Find the real overdue
We analysed the outstanding balance and separated genuine debt from invoices that were unpaid for a reason. The reasons grouped into four recurring causes, and none of them were solved by a reminder:
- Missing documentation — the delivery happened, the paperwork proving it did not follow.
- Non-performing service — the customer was withholding because they had not received what they were owed.
- Delivery non-compliant with the purchase order or specification — a legitimate dispute, not a late payment.
- Internal payment-process failures with sister companies and subsidiaries — money owed inside the group, stalled on process rather than on willingness.
Each of those is a different fix, routed to a different team. Grouping them was what made the remaining balance actionable.
Clean the data, then automate the decision
The analysis exposed process defects and data quality bad enough that no automation would have been trustworthy on top of it, so remediation came first. We then specified and supervised the implementation of a SAP module that computes each customer’s DBO — Days Billing Outstanding — and converts it into an operational decision, rather than leaving it to case-by-case judgement:
| DBO band | Risk | Consequence |
|---|---|---|
| Current | None | Eligible for early-payment discount |
| Modestly overdue | Low | Verbal reminder only |
| Materially overdue | Medium | Non-essential parts and services withheld pending payment |
| Seriously overdue | High | All deliveries blocked until the outstanding invoices are settled |
The DBO thresholds separating the bands are the client’s own credit policy and are not ours to publish. What matters here is the shape: the response is proportionate and automatic. A customer a few days late is not treated like one three months late, and nobody has to argue the case each time.
Four disciplines, one engagement
The work is listed under consulting, but it needed four:
- Data engineering — identifying the process defects and cleaning the data the module would depend on.
- Software specification — the SAP functional specification, and supervision through implementation.
- Process reengineering — redesigning how a disputed delivery is routed and resolved.
- Change management — training the teams on how to handle a delinquent customer under the new rules.
What made it hard
The automation was the easy half. A rule that withholds deliveries from a paying customer is a commercial decision wearing a technical costume: get the data wrong and the system stops shipping to somebody who does not owe anything. That is why the data remediation came first, and why the bands are graduated rather than binary.
The other half was people. A tiered policy only works if the team applying it trusts the number in front of them, which is why change management was part of the engagement rather than a handover at the end. A rule nobody believes is a rule that gets overridden.
Amounts recovered remain confidential.
Why we mention it
It is an unusual thing for a data and AI house to have done, and that is exactly why it is here. The underlying skill is the same one behind the other work on this account: reconstructing what is actually true from records that disagree with each other, then making the result defensible to someone who will challenge it — and, in this case, automatic enough that nobody has to.