Who Do We Call First?

Part 8 of 10 – getting paid

Collections as a triage problem, and the cash a single day of DSO ties up.

It is 8:20 on a Wednesday, and Nadia is deciding who to disappoint.

Not in those words. What is actually on her screen is the aged receivables report at Spiese Fluid Power – a long, sorted list of everyone who owes the company money and has not yet paid, bucketed into the familiar columns: current, 1–30 days past due, 31–60, 61–90, over 90. Nadia runs collections. She has this morning, a phone, and a list far longer than the morning. So the real question, the one the report does not answer, is which of these accounts deserves her between now and lunch.

The report sorts by dollars and by age, and neither is the same as who to call first. The biggest past-due balance belongs to Spiese's third-largest customer, who always pays on day fifty and always has, and who will be insulted by a dunning call on day forty-four. The account that should actually scare her is smaller, newer, thirty-eight days out, trending the wrong way, and buried on page three because the balance is not big enough to float to the top. The list has the facts. It does not have the judgment.

So Nadia works from memory and instinct – the accounts she is worried about, the ones she promised to follow up on, the two a salesperson pinged her about. She is good at it. But it lives in her head, it does not survive her being out for a week, and on a busy morning the account that should have been the first call is the one that quietly does not get called at all.

This is not a failure of the ledger. The ledger is perfect. It knows to the penny who owes what and for how long. The problem is one step past the arithmetic, and it is a problem of judgment and language – which is exactly the seam this series keeps prying at.

What it costs today

Start with the money, because for once it is genuinely the point. Spiese carries an accounts receivable balance of $9,780,822 against $85M in revenue, which works out to a DSO – days sales outstanding, the average time a dollar of revenue spends as an unpaid invoice – of 42 days.

Here is the lever, and it is worth doing the arithmetic in the open. Spread $85M of revenue across 365 days and a single day of DSO represents about $232,900 of cash tied up in invoices instead of sitting in the bank – that per-day figure is just revenue ÷ 365, falling straight out of the grounded 42-day DSO and the $9,780,822 balance. Which means the whole game of collections has a number on it. Pull DSO from 42 down to 38 and Spiese frees on the order of $930,000 in working capital – four days at roughly $232,900 each – money that was always earned and just had not arrived. (The four-day pull is illustrative; set your own target – the per-day cash is what makes any target real.)

Now the cost of the current way of getting there. Three people cover AR and credit at Spiese – posting cash, chasing the past-due, watching credit. A real share of that team's week goes not to collecting but to deciding – reading the aging report, cross-checking who promised what, working out who is worth a call today. Call it a couple of hours a day across the desk spent on prioritization and prep before a single customer is contacted – the first thing to measure in your own shop, and easily measurable.

At an AR-clerk loaded rate of about $34.67/hr – the profile's loaded clerk rate, borrowed as a stand-in for an AR collector, who may sit a few dollars either side – that prep time is real payroll, but the payroll is the small cost. The large one is the same shape as every other post in this series: the buried signal. Somewhere in the over-60 column is an account that is not slow-paying, it is not-going-to-pay, and every week it goes un-worked is a week closer to a write-off – revenue Spiese already recognized, product already shipped, cash that simply never comes. You will need your own bad-debt figure here – what Spiese books in write-offs a year – because that is the number that turns this from a nice-to-have into a project.

And there are two costs that never show on a report at all, pulling in opposite directions. Chase a good customer too hard, on day forty-four, and you spend goodwill you cannot get back – the third-largest account does not forget a rude call. Chase a bad one too late, and the money is gone. The aging report, sorted by dollars, walks Nadia straight into both mistakes.

Where the boundary sits

The ledger is the system of record doing arithmetic, and it is not the problem. Every invoice, every payment, every aging bucket, every credit limit and hold status – deterministic, current, auditable. Do not point a model at the balance. The number of record is the ledger's, always.

The problem is one step later, and it is two judgment problems stacked. First: out of hundreds of open, past-due accounts, which handful should a human work this morning, and why – weighing not just dollars and days but payment pattern, recent promises, the size and health of the relationship, whether a dispute is open, whether an order is waiting on a hold. Second: what do you actually say to each one – a gentle nudge to the reliable-but-slow, a firmer note to the drifting-newer, a careful hold-the-relationship message to the big account you cannot afford to offend. Ranking a messy pile against a lot of context, and then writing the right words for each – that is the home turf of a system of inference, and it is precisely the part the ledger cannot do.

What the AI does – and what it must never do

Does: reads the full aged receivables ledger and, for each past-due account, assembles the context Nadia would gather by hand – how the customer has paid over the last year, whether they are trending slower, what they promised and whether they kept it, how large and how healthy the relationship is, whether an order is sitting on credit hold against this balance, whether a dispute or short-pay is open. Then it ranks the accounts into a worklist and, for the ones worth working today, explains why this one, now in terms a human can check against the record. For each, it drafts the outreach – matched in tone to the relationship – as a proposal in Nadia's queue, never a message on its way out. And on the cash side, when a payment arrives that does not cleanly match its invoices, it reads the messy remittance, lines it up against the open items, and proposes an application for a human to confirm.

Must never do:

• Never apply cash or post to the ledger itself. It proposes a match for a stray payment or a short-pay; a human confirms and the ERP posts it through the normal path, with the normal audit trail. Cash misapplied silently is one of the two ways this workflow ends in disaster.

• Never place or release a credit hold on its own. Whether an account goes on hold, or comes off so an order can ship, is a decision with a customer on the other end of it – it stays a human's call, executed in the record.

• Never send a dunning message to a customer. The customer-facing send is irreversible and relationship-sensitive; a human reads every draft and sends it, every time. This is the other way this workflow ends in disaster: a tone-deaf collection note fired off in the company's name to a good account.

• Never promise, threaten, or offer terms it cannot back. No "we'll waive the late fee," no "pay by Friday or we cancel," no settlement figure – the draft never commits Spiese to anything a human and the record have not authorized.

• Never expose one customer's balance, terms, or history to another. Each account's data stays scoped to that account; the draft for customer A can only ever see customer A.

• Never write off, adjust, or dispute a balance. It can flag "this one looks uncollectible, here is why," but the write-off is a human decision posted in the record – never a number the model quietly changes.

The catastrophic failure of this workflow has two faces: a wrong or tone-deaf message sent in Spiese's name to a customer who did not deserve it, or cash applied to the wrong invoice with no one looking. Every rule above exists so that a human stands between the model and both.

The plumbing

The good news, again, is that the hard part already runs. The AR ledger, the payment history, the credit limits, the hold logic, the cash-application posting – all of it lives in the ERP today and should keep living there, untouched. Nothing here rebuilds the system of record.

What you add is a read-and-propose layer in front of it. It reads the aging report and the account history through read-only services, ranks and annotates the worklist, and drafts a message for each account into a queue Nadia works. It writes nothing on its own. The cash-application assist proposes a match for a messy remittance; the actual posting stays inside the record, behind a human confirm. The hold and the write-off stay exactly where they are today – decisions a person makes and the ERP executes.

Who builds it. A layer reading the AR ledger, payment history, and hold status through the ERP's own services – and posting nothing itself – belongs closest to whoever already runs your system of record.

Failure modes and guardrails

The tone-deaf send. The model drafts a firm past-due notice to a thirty-year account that happens to be four days late, and it goes out because it read well. Guardrail: nothing sends without a human; the draft's tone is matched to relationship data from the record and shown alongside that reasoning; and the highest-value accounts can be flagged to always require a second look before any outreach.

The silent misapplication. A payment arrives, the model matches it to the wrong invoice, and the ledger now says an account is current that is not. Guardrail: the match is a proposal, never a post; every proposed application shows the remittance next to the open items it was matched against; and low-confidence matches route to a human automatically rather than being smoothed over.

The buried uncollectible. The account that will never pay stays in the pile because it is small, and the model, tuned for a tidy list, lets it scroll. Guardrail: tune for recall on the accounts that are trending toward write-off, not for a short call list; surface the not-going-to-pay cases loudly; and sample-audit the un-worked bucket weekly.

The cross-customer leak. One account's balance or terms bleed into another's draft. Guardrail: scope every lookup to the one account at the query layer, not by asking the model to be careful.

The tempting auto-send. The drafts get good, the queue gets long, and someone suggests letting the gentle reminders go out on their own. That is a write path to a customer, and earning the right to remove the human from it is the subject of the final post – not a corner you cut in month five because the tone held up.

How you'd know it worked

Not calls made, and not messages sent – those reward activity and hide the miss. Watch what the business actually feels.

First, DSO. It is the one number that ties directly to cash, and at roughly $232,900 a day it is the number the CFO already cares about. Did the average age of a receivable fall, and did it fall because the right accounts got worked sooner?

Second, the losses that stopped. Count write-offs and the drift into the over-90 bucket for the quarters before and after. Build a set of past accounts where you already know which slid into write-off, and measure how many the ranking would have surfaced early. Catching the ones that were going to hurt is the evidence it is safe to lean on.

Third, capacity and relationship. How much of the desk's prep time came back for actual collecting? And, on the other side of the ledger, are complaints about collection tone flat or falling – because a faster desk that alienates good customers has not won anything.

Monday morning

Before any software, measure the two things that are the whole business case. Pull ninety days of the aging report and have Nadia mark, for a sample, which accounts genuinely needed working and which paid on their own – you get your real noise ratio, the same way every post in this series starts. Then pull last year's write-offs and put a dollar figure on what actually went uncollected. Between them, those two afternoons tell you whether this is a project or a footnote, and they turn every reader-supplied number above into a real one.

Then pilot narrow. One collector – Nadia is the obvious choice, she will spot a bad draft and a wrong call in a second – sixty days, ranked worklist and drafted outreach only, nothing applied, no hold touched, nothing sent without her hand on it. Watch whether DSO on her book of accounts moves, whether the drafts are good enough to send with a light edit, and whether the accounts that were going to slide got caught earlier.

If it holds up, widen it. If it doesn't, you learned that cheaply, and you kept it away from customers and away from the ledger the whole time. Ellen, the controller, still owns the credit policy; the ledger still owns the balance; Nadia still owns the relationship. The model's job was never to collect the money. It was to make sure the first call of the morning is the one that should have been.

Start with the money you already earned.

Spiese Fluid Power is fictional – a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published separately.