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 the order of payments going out. Post #12 was about the order of reminders sent to collect what's owed. Both treated them as separate queues. On the bank statement they aren't separate: there is one balance, and both queues draw on it.
The week described below is a composite built from patterns I've seen repeat across finance teams over the years; the hours, the meeting, and the figures are illustrative and don't describe a specific company, team, or week.
Two lists, one balance, and a meeting nobody scheduled for it
How the two queues actually touch
A receipt that slips from Tuesday to the following Monday changes which payments can safely go out on Thursday. A supplier payment that can't wait changes which customer gets the phone call. Neither list says so, because each one only shows its own side. The link lives in someone's head, or in the meeting where the two lists finally land on the same screen.
| What it looks like | What's actually true |
|---|---|
| Payables and receivables are two separate processes | They are two queues drawing on the same balance; a change in one moves the other |
| A late receipt is a collections problem | It is also a payments problem: it changes what can go out this week |
| The weekly cash meeting is where the decisions get made | In many teams I've seen, it spends most of its time assembling the numbers the decision needs |
| Reporting more often fixes it | Reporting two separate lists more often still leaves someone to combine them by hand |
There is one balance, so there is really one decision. The two lists are just the two places it gets written down.
A finance week, before and after (illustrative)
| Day | What takes the time today | What changes with one view |
|---|---|---|
| Mon | Pull the payables due list and the receivables aging from two places, paste both into one sheet | Both lists arrive already lined up against each day's balance |
| Tue | Chase receipts, then check whether any payment is now at risk | Chasing and paying are reviewed against the same projected balance |
| Wed | Argue about which payments can wait | Decide from one list of what can wait, and what waiting costs |
| Thu | Cash meeting: confirm the numbers | Cash meeting: decide what to do about the gap |
| Fri | Re-run everything because one receipt moved | Update the one view; the knock-on effect shows immediately |
What a combined view would actually have to show
It needs the same shape of mechanism as the last two posts, just pointed at the balance instead of at a single list. It reuses the signals those posts already relied on and adds one: how likely each expected receipt is to arrive on time.
| Signal | Where it comes from | What it does to the view |
|---|---|---|
| Payments due, by day | The payment-priority logic from Post #11 | Takes money out of the projected balance on the day it's due |
| Expected receipts, by day | The collections order from Post #12 | Adds money to the balance, discounted when a hold or silence suggests it may slip |
| Minimum buffer | The idle-cash check from Post #10 | Marks the line the projected balance shouldn't fall below |
| The gap | The difference between the two on any given day | The one number that tells the team whether a delay on one side forces a decision on the other |
I haven't put a script behind this one on purpose. The interesting part isn't another calculation; it's noticing that two lists I'd been treating separately were never separate. The first test I'd run is a simple one: take a single week of your own payables and receivables, line them up against the opening balance day by day, and count how many decisions change.
Follow the series
Post #14 looks at what happens when the two sides don't line up: when cash going out outpaces cash coming in, and a revolving credit line quietly fills the gap — and what that gap actually costs.