The examples and architectures in this series are my personal educational, non-commercial experiments; they are not an offer of IT or consulting services.
Post #11 was about money leaving the company, and in what order. This one is about money that's supposed to come in — and mostly does, until it quietly doesn't, for reasons nobody ever writes down.
The customers, amounts, and collection order below are a composite illustration built from patterns I've seen repeat across finance teams over the years; they don't describe a specific company, customer, or collections run.
One collections review, eighteen overdue invoices, one order nobody actually decided on
What the aging report shows, and what it doesn't
The days-overdue count isn't hidden either. It's the first column on every AR aging report, re-sorted every week for anyone who wants to look. What's missing is any record of which reminders actually moved money — and how rarely that lines up with which invoices are simply the oldest.
| What it looks like | What's actually true |
|---|---|
| Reminders get paid in the order they're sent | They get paid based on what the reminder actually threatens, not when it went out |
| The oldest invoice is the hardest to collect | A fresh invoice from a slow-paying customer can be harder to collect than an old one from a reliable payer |
| Bigger invoices get chased harder | In my experience, smaller invoices often get collected faster, because nobody wants to escalate a big relationship over money |
| Days overdue predicts how much attention an invoice gets | Days overdue mostly predicts how it looks on the aging report — not what happens next |
Why the order isn't the days-overdue count
Usually none of this happens because someone doesn't understand credit terms. It happens because "decide which customer to chase this week" usually isn't a single, owned step — it's an emergent property of who happened to notice a balance, and whether chasing it felt worth the relationship risk. A customer who's blocked from placing a new order tends to get chased within the hour, because the hold is leverage today; a quiet, large account that's ninety days late gets left alone for another month because nobody wants to be the one who escalates it.
Days overdue is a fact about the invoice. Whether the money actually comes in is a fact about who's asking, and what they're asking for.
What actually decides which reminder gets paid
| Signal | What it does to the order |
|---|---|
| An active credit hold blocking the customer's next order | Jumps the queue, regardless of how old the balance is |
| Account size | In my experience, the biggest customers often get the gentlest, least consistent follow-up — nobody wants to be the one who pushes |
| Who sends the reminder | A reminder from the account owner lands differently than an automated one from AR |
| A personalized reminder that references the actual relationship | Tends to get a response more often than a templated one |
| The printed days-overdue count | Mostly determines where the invoice sits on the aging report. Rarely determines what happens next |
These are patterns I've seen, not measured benchmarks.
What a collections-priority check would actually have to do
It needs the same shape of mechanism as the payment-priority check from the last post, just pointed at the other side of the ledger: a set of signals to compare against a rule, and an output that ranks who to chase instead of just listing who's overdue. Here the signals are days overdue, an active credit-hold flag, and how many reminders have already gone out with no response — and the rule is which of those, if any, should move a customer ahead of an older balance.
I put together a small script that does exactly that against sample data: it reads a set of open receivables, checks each one for a credit-hold flag and a reminder count, and prints a suggested collections order — nothing connected to a real customer list, no live CRM or banking access, just the ranking logic itself. It sits in the same personal, non-commercial repository as the earlier demos in this series.
There's a small prototype for this
collections_priority_agent.py reads a CSV of open receivables and prints a suggested collections order that isn't just sorted by days overdue — the same logic described above, run against sample data.
Follow the series
Post #13 steps back from any single ledger line to ask a harder question: once both sides of cash — what the company owes, and what it's owed — are visible at the same time, what actually changes about how a finance team spends its week?