The low point, not the total

Every month for years I opened the same spreadsheet to answer one question: how much stock do I have to sell to cover the bills? Sell around the 27th, wait for settlement, pay the pile that clears between the 1st and the 3rd, repeat. The sheet did the arithmetic — everything due, minus the cash, minus the pay coming in — and gave me a number. The arithmetic was fine. The timing wasn’t.

The sheet

A paycheck on the 31st does not pay a mortgage on the 3rd. If the big bills clear on the 1st and the paycheck lands on the 5th, the monthly total can look fine while the account goes negative for four days.

So the thing I replaced the spreadsheet with doesn’t total anything. It walks the window day by day, applying every bill and every paycheck in date order, and watches the running balance. The answer is the deepest point that balance reaches, plus a small buffer.

On my own numbers the two answers differ by enough to matter. The totals-only figure is always the optimistic one.

YNAB and Gmail propose into a review queue. I click Update, Add or Dismiss. Neither source changes a number on its own. There is exactly one write in the whole system — applying a statement amount back onto the matching scheduled transaction in the budget — and that happens after a click too.

A credit card’s current balance is what has been charged so far, not what the statement will ask for. Counting it overstated the sale for a month before I caught it. A stale due date means roll me, not pay me again — everything here is on autopay. Settlement is part of the deadline: sell this much, by this date.

The forecast module is a pure function. No clock, no network. Every number the page shows is covered by ordinary unit tests, including a parity case against the old spreadsheet. This one stays private. Real balances, real pay schedule, admin login. No public link.