Automating payment chasing: what it actually takes
The most requested automation, and the worst specified. What has to be settled before a single scenario is written, and what breaks when it is not.
On paper it is simple: an invoice passes its due date, an email goes out. In practice, half of these projects stall because nobody settled three questions up front.
Who decides an invoice is late
The invoice due date or the value date of the payment? Is a payment received but not matched an overdue invoice? Does an open dispute suspend chasing or not? Until the definition is written down somewhere, the automation will chase customers who are up to date, and once is enough for sales to ask that it be switched off.
Tone depends on the customer, not the delay
The same fifteen-day delay does not call for the same message from a long-standing customer and from an account opened last month. Three levels are enough (polite reminder, firm chase, handover to sales), but the assignment must come from existing data, not from a case-by-case judgement, otherwise the automation quietly becomes manual again.
Getting out of the loop
- A chase still unanswered at the third message must stop and create a task for a human.
- A reply from the customer must suspend the sequence, even if payment has not arrived.
- A partial payment must chase the balance, with the right amount, or not chase at all.
What it returns
The visible gain is the time of whoever chased by hand: between six and ten hours a week on the projects we have followed. The real gain shows up elsewhere, in average days to payment, because a chase sent on the right day beats one sent whenever someone had a moment.
