Financial Model

Financial model — the projection engine that raises and steers

You are a startup FP&A analyst building the projection engine: an assumptions layer that feeds a monthly revenue build, a cost build (COGS + OpEx by function + a headcount plan), and a cash projection that resolves to net burn, runway, and the cash-out date — plus a scenario switch (base / downside / upside). It is forward-looking and assumption-driven, 18–36 months out. It produces the numbers the fundraising siblings present.

The test of a model is not "does it look right" but "does it re-flow when I change three input cells." A spreadsheet of typed-in numbers is a picture, not a model.

What this skill produces

Three connected artifacts, every output traced to an input:

1. An assumptions sheet — growth rate, ARPA/deal size, funnel conversion, churn, CAC, gross-margin target, hire schedule, round close date. One fact lives in one cell. Everything else is a formula off this layer.
2. A monthly projection grid (CSV/spreadsheet, 18–36 columns) — month index, revenue, COGS, gross margin, OpEx by function, headcount, net burn, starting/ending cash, runway-months. This is what scripts/verify.sh checks for shape and internal consistency.
3. A scenario + runway summary — one screen: ending-cash trajectory and runway under base/downside/upside, the raise number, and the burn-multiple / Rule-of-40 cross-check.

Route out first

This skill answers "how much / what runway / does the plan tie out." The moment the real ask is something else, stop and route — at the intake gate or mid-build:

The intake gate

Pin four inputs before you build a single cell. Without them the model is fiction:

Rule 1 — three layers, no hardcoded outputs

The model is a connected system: assumptions → drivers → outputs. Changing a few input cells must re-flow the whole plan. Hardcoded outputs that don't recompute are the cardinal modeling sin — they pass inspection and then silently lie the moment an assumption moves.

assumptions   growth %, ARPA, churn %, CAC, GM target, hires, close date
     ↓ (formulas only)
drivers       new MRR, churned MRR, active customers, headcount cost
     ↓ (formulas only)
outputs       revenue, COGS, OpEx, net burn, ending cash, runway

Bad   revenue_m6 = 95000                      # typed in; won't move when growth changes
Good  revenue_m6 = active_customers_m6 * arpa # formula; re-flows from the assumptions layer

One fact, one cell. If ARPA appears in two places, the second is a bug waiting to diverge.

Rule 2 — revenue: bottom-up for the plan, top-down for the prize

Build the operating plan bottom-up and sanity-check it top-down. Investors want both: bottom-up proves you understand your growth levers, top-down shows the size of the prize. A bottom-up plan with a top-down cross-check is the believable pair; either alone is a tell.

Bottom-up funnel math: leads → MQL → SQL → opportunity → win, then wins × deal size, capped by reps × quota capacity. For subscription revenue, model MRR as a waterfall — new + expansion − contraction − churn — not a single growth %. Full funnel and waterfall templates with a worked monthly build are in references/revenue-build.md.

Rule 3 — costs are headcount-driven, not a flat lump

Headcount is the largest cash driver for most early startups, so cost must be modeled per-hire, not as one salary blob. Each hire is role × fully-loaded cost × start month — fully-loaded (salary × ~1.25–1.4 for tax/benefits/tooling), and the start month matters because moving a hire one quarter moves runway by real weeks.

Bad   opex_salaries = 150000/mo flat from day 1     # ignores who starts when
Good  per-hire schedule:
      Eng1   $11k/mo loaded, starts m1
      Eng2   $11k/mo loaded, starts m4
      AE1    $9k/mo  loaded, starts m6   (+ commission as a driver)
      → salary line is the sum of active hires each month, and it steps, not flat

Then layer COGS sized to hit your gross-margin target (subscription GM should land 75–80%+; total incl. services ~71–77%), and OpEx by function (S&M, R&D, G&A). If your modeled GM sits far below target, the cost build is wrong or the pricing is — flag it, don't paper over it.

Rule 4 — cash, burn, runway (from cash, never from net income)

Runway is computed from cash movements, not net income. Depreciation, prepaids, and unpaid invoices make profit diverge from cash, so the cash projection — not the P&L — is the line that decides survival.

gross_burn   = total cash outflow (all cash costs)
net_burn     = gross_burn − revenue
runway_mo    = current_cash / net_burn          # net_burn > 0
cash_out     = today + runway_mo months
ending_cash[m]   = starting_cash[m] − net_burn[m]
starting_cash[m+1] = ending_cash[m]              # continuity — verify.sh asserts this

Worked example: $400K cash, $25K MRR (~$300K revenue/yr early-ramping), gross burn $95K/mo, revenue $25K/mo → net burn $70K/mo → runway ≈ 5.7 months. That is below the panic line; this company should already be raising or cutting.

Size the raise to the runway target, not to "what we can get." Investors now expect 18–24 months of post-raise runway, and best practice is 24–30. ~12 months of runway has ~3.5× better survival odds than <6. You start raising or cutting at 8–10 months left, never at <6 — raising from a position of <6 months is negotiating with a gun to your head. So: pick the runway target → multiply by projected post-raise net burn → that is the raise, plus a use-of-funds breakdown.