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 #9 covered a loss that hides inside an exchange rate. This one hides somewhere far more visible: a bank balance that shows up on every report, every month — and that still nobody moves.
The balance, the rate, and the numbers below are a composite illustration built from patterns I've seen repeat across different projects; they don't describe a specific company or account.
One balance, one year, one number nobody calculates
What the balance sheet shows, and what it doesn't
The balance itself isn't hidden. It's on the bank statement, the monthly close, the treasury summary — anyone who wants to can see exactly how much sits in the operating account on any given day. What's missing isn't visibility. It's a number next to it that says what that balance is quietly not earning, month after month, while it sits there.
| What it looks like | What's actually true |
|---|---|
| Nobody is watching this account | Everyone who reads the monthly close is watching it — just not for this |
| It's earning something, so it's fine | 0.05% on €340,000 works out to about €14 a month — invisible until you add twelve of them together |
| Moving it is risky | The amount above the confirmed operating buffer isn't at risk by definition — it's the part already agreed to be excess |
| It's not worth the hassle for a few basis points | The hassle is real. So is roughly a month's worth of runway in interest by the end of the year |
Why nobody moves it
None of this happens because someone doesn't understand interest rates. It happens because moving idle cash usually isn't anyone's single job. Treasury may have no mandate to sweep balances daily. Accounting closes the books on what happened, not on what could have happened instead. And the buffer itself was set once, months or years ago, for a set of conditions that may no longer apply — nobody revisits it, because revisiting it isn't on anyone's calendar.
Idle cash doesn't cost you like a mistake. It costs you like a subscription nobody remembers signing up for — small, recurring, and easy to keep paying by doing nothing.
How often should someone actually check this?
| Review frequency | What you catch | What you miss | Verdict |
|---|---|---|---|
| Annually (budget review) | That the buffer assumption is stale | A full year of forgone interest before anyone notices | High risk |
| Quarterly | Whether the balance has drifted well above buffer | Weeks of drift within the quarter | Acceptable |
| Monthly | This month's excess versus the agreed buffer | Which days within the month it could have been swept | Good |
| Daily, with an automatic sweep | Every day the balance sits above buffer, moved before it matters | Almost nothing — the excess is swept before it accrues an opportunity cost | Optimal |
What daily idle-cash monitoring would actually have to do
It needs the same shape of mechanism as the FX check in the last post: a number to compare against a threshold, a rate to apply to the difference, and a rule for what's worth flagging. Here the number is the account balance, the threshold is the agreed operating buffer, and the rate is whatever the cash could reasonably earn if it were swept instead of sitting still.
I put together a small script that does exactly that against sample data: it reads a set of account balances, compares each one to its configured buffer, and estimates what the excess would have earned at an illustrative rate — nothing connected to a real account, no live banking access, just the calculation itself. It sits in the same personal, non-commercial repository as the earlier demos in this series.
There's a small prototype for this
idle_cash_agent.py reads a CSV of account balances and estimates the forgone interest on whatever sits above a configured buffer — the same logic described above, run against sample data.
Follow the series
Post #11 stays with cash — this time on the other side of the ledger: which invoices actually get paid first, and why the answer usually has nothing to do with the due date printed on them.