playbook
Build a cash-flow model you understand
From a starting balance and recurring costs, project the next 6 months with every formula explained in one plain sentence — so you stay in control instead of trusting a black box.
when to reach for this
Someone asks "how many months of runway do we have?" and the honest answer is you're not sure, because the model lives in a spreadsheet you inherited and half-trust. A cash-flow model is only useful if you understand every cell — otherwise it's a confident-looking number you can't defend in a board meeting. This system builds a simple 6-month projection from scratch, with Claude explaining each formula in one plain sentence, so the model is yours, not a black box you're hoping is right.
gather this first
- Your starting cash balance — a single number you trust, like 240,000, ideally tied to a profiled bank export.
- Recurring costs as a file or list —
recurring-costs.csvwith each line item, amount, and frequency (monthly, quarterly, annual). - Expected inflows: a monthly revenue figure or a simple ramp ("42,000/mo, growing ~5% a month"), and any one-off items (a tax bill, an annual renewal) with the month they hit.
the workflow
-
Agree the assumptions before any math
A model is its assumptions. Make Claude restate them back to you — starting balance, what's recurring, the growth rate — so you catch a wrong input before it compounds across six months of formulas.
you askRead recurring-costs.csv. Before building anything, read my assumptions back to me as a list: starting balance, every recurring cost with its monthly equivalent, expected monthly revenue and growth rate, and any one-off items by month. Tell me anything that looks missing or ambiguous. Don't build the model yet.what you get back A clean assumptions list: "Start 240,000; recurring 198,000/mo (payroll 165k, hosting 18k, software 9k, tools 6k); revenue 42,000/mo growing 5%; one-off: 28,000 tax bill in month 3." Plus flags like "the annual SaaS renewal — which month does it hit?"
Garbage in, confident garbage out. The assumptions read-back is where you catch the input error that would otherwise make the whole model wrong.
-
Build month one and explain every line
Build a single month fully first, with each formula explained in one plain sentence. If you understand month one, the rest is just repetition — and you've verified the logic before it's copied 6 times.
you askBuild just month 1 as a table: opening balance, inflows, each outflow line, net change, closing balance. Next to each row, explain the formula in one plain sentence — e.g. 'closing = opening + inflows − outflows.' I want to understand the logic before you extend it.what you get back A single-month table with a plain-English formula beside every line: "Opening 240,000. Inflows 42,000. Outflows 198,000. Net −156,000. Closing 84,000 = opening + inflows − outflows." Now you can see exactly how a month works.
-
Extend to 6 months and find the runway
Roll month one forward six times, carrying each closing balance into the next opening. The one number everyone actually wants is the month the balance goes negative — ask for it directly.
you askNow extend to 6 months, carrying each month's closing balance into the next month's opening, applying 5% revenue growth and the month-3 tax bill. Give me the full table, the closing balance each month, and tell me the first month the balance goes below zero — that's our runway.what you get back A 6-month table where balances flow correctly month to month, plus the headline: "Balance goes negative in month 4 (−18,000) — roughly 3.5 months of runway at current burn." The number leadership actually asked for, with the table behind it.
-
Stress-test it and keep it re-runnable
A single projection is a guess; a model earns trust when you can flex an assumption and watch it respond. Run two scenarios, then save it so next month is an update, not a rebuild.
you askRun two scenarios off the same model: (a) revenue is flat, no growth, and (b) we cut software spend by 4,000/mo. For each, tell me the new runway and the closing balance in month 6. Then save the model and its assumptions as cashflow-model.md so I can update the inputs next month and re-run it.what you get back Two scenario results — "Flat revenue: runway drops to month 3. Cut software: runway extends to month 5" — and a saved
cashflow-model.mdwith assumptions on top, so next month is editing three numbers, not rebuilding from zero.Spot-check one month by hand against the formulas. If month 2's closing matches your own arithmetic, you can trust the method across all six.
make it your own
- **Budget vs actual:** once a month closes, drop the real numbers in beside the projection and ask Claude to explain each variance — the model becomes a budgeting tool, not just a forecast.
- **Tie it to real data:** feed the model your reconciled actuals from *Reconcile two files, line by line* so the starting balance and revenue aren't guesses but verified figures.
- **Anomaly check the costs:** before modeling, run *Audit the month's spend* over your recurring costs so a forgotten or doubled subscription doesn't quietly sit in your burn rate.
watch out for
- Don't accept the runway number without seeing the formulas. A model you can't explain is a model you can't defend — insist on the one-sentence explanation for every line.
- Spot-check the carry-forward: confirm each month's opening equals last month's closing. A single broken link there throws off every month after it.
- Claude builds the model; you own the assumptions and the decision. A projection informs a hiring or spending call — it doesn't make it, and the inputs are your responsibility, not Claude's.
you'll end up with A 6-month cash-flow projection you fully understand — every formula explained in plain English, a clear runway number, two stress scenarios, and a saved model you can re-run each month.