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 #10 was about money that doesn't move. This one is about money that does move — and lands on the wrong vendor's account first, for reasons nobody wrote down anywhere.
The invoices, amounts, and payment order below are a composite illustration built from patterns I've seen repeat across different projects; they don't describe a specific company, vendor, or payment run.
One payment run, twelve invoices, one order nobody actually decided on
What the due date shows, and what it doesn't
The due date isn't hidden either. It's printed on the invoice, sitting in the AP aging report, visible to anyone who opens the ledger. What's missing is any record of the order invoices actually got paid in — and how rarely that order matches the one the due dates imply.
| What it looks like | What's actually true |
|---|---|
| Invoices get paid in due-date order | They get paid in whichever order someone happened to approve them |
| A vendor calling about a late invoice is a red flag | The call is often the actual reason that invoice gets paid first — not the due date |
| Early-payment discounts are always taken | They're taken when someone notices the window is still open, not by default |
| Cash flow decides who gets paid | Cash flow decides whether anyone gets paid. The order is decided by something else entirely |
Why the order isn't the due date
None of this happens because someone doesn't understand payment terms. It happens because "decide the payment order" usually isn't a single, owned step — it's an emergent property of whoever approved what, in whatever order it landed in their inbox. A vendor who calls gets prioritized because the call is a cost today; an invoice that just sits quietly gets paid whenever there's time. Early-payment discounts get missed for the same reason idle cash sits still: nobody's job is to watch the window open and close.
A due date is a fact about the invoice. Who actually gets paid first is a fact about your inbox.
What actually decides payment order
| Signal | What it does to the order |
|---|---|
| A vendor phone call this week | Jumps the queue, whether or not it's the oldest invoice |
| An early-payment discount window | Gets skipped whenever nobody's actively tracking it |
| Invoice size | Small invoices often get paid first simply because they're easy to clear off the list |
| A vendor you can't afford to upset | Quietly overrides the age of the invoice every time — informally, and inconsistently |
| The printed due date | Mostly determines the late fee. Rarely determines the order |
What a payment-priority check would actually have to do
It needs the same shape of mechanism as the idle-cash check in the last post: a set of signals to compare against a rule, and an output that ranks the queue instead of just listing it. Here the signals are the due date, an active discount window, and whether the vendor is flagged as critical — and the rule is which of those, if any, should move an invoice ahead of an older one.
I put together a small script that does exactly that against sample data: it reads a set of open invoices, checks each one for a discount window or a critical-vendor flag, and prints a suggested payment order — nothing connected to a real vendor list, no live banking or ERP 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
invoice_priority_agent.py reads a CSV of open invoices and prints a suggested payment order that isn't just sorted by due date — the same logic described above, run against sample data.
Follow the series
Post #12 moves to the other side of that same ledger: money owed to the company, and why some collection reminders get paid within days while others get ignored for months.