---
name: financial-model
description: "Use when a founder needs the multi-period, driver-based projection that raises a round and steers the company — build 3-year projections, model revenue + costs + headcount + runway, size the raise, or stress-test scenarios. Triggers: 'build a financial model for our seed', 'model our revenue costs and runway', 'when do we run out of cash', 'how much should we raise to get 24 months', 'what runway does $2M buy us', 'model the hiring plan's effect on burn', 'add a downside scenario if we miss plan by 30%', 'modelo financiero a 3 años', 'cuánto runway nos da la ronda', 'model financer i projeccions', 'quant de pista de despegament'. The engine is assumptions → revenue/cost/headcount builds → cash/burn/runway/scenarios, 18–36 months forward, every output a formula. NOT the next-13-weeks liquidity reconciled to the actual bank balance (that is finance-ops), NOT the isolated LTV/CAC math (that is unit-economics, which this model consumes as drivers), NOT the slide story (that is pitch-deck)."
tags: [financial-model, projections, runway, burn-rate, fundraising, fp-and-a, forecast]
recommends: [finance-ops, unit-economics, pricing, forecasting, pitch-deck, investor-materials, fundraising]
origin: risco
---

# 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 is not the controller's short-horizon liquidity tool, not the deck narrative, not the LTV/CAC deep dive. 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.

## What it does NOT do — 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:

- Next-13-weeks liquidity reconciled to the **actual bank balance**, this-month burn, are-we-solvent-now → `finance-ops`.
- Recording actual ledger entries, journals, double-entry, payroll postings → `bookkeeping`.
- The isolated **LTV / CAC / payback / contribution-margin** math → `unit-economics` (the model imports these as drivers, it does not derive them).
- Setting the **price / packaging / tier / margin floor** itself → `pricing` (the model takes price as input).
- Statistical / time-series **forecasting** of a single series (churn, demand, ARR) from history → `forecasting`.
- The slide **story** and decision-grade headline numbers → `pitch-deck`. Packaging the model into the data room / sending it → `investor-materials`.
- Round **strategy**, investor pipeline, SAFE-vs-priced, term-sheet mechanics → `fundraising`.
- Per-unit COGS / infra / AI spend as actuals → `cost-tracking`.

## The intake gate

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

| Input | Why it gates everything |
| --- | --- |
| **Stage** (pre-seed / seed / Series A) | sets which benchmarks apply and how much runway investors expect |
| **Current cash** | the numerator of runway; the model is meaningless without it |
| **Current revenue / MRR + recent growth** | the base the revenue build grows from, not a fresh hockey stick |
| **Target raise & horizon** (or "size it for me") | the model either takes the raise as input or solves for it from a runway target |

STOP-and-route at the gate:

- If the ask is "what does next quarter's cash look like against the bank" → that is the 13-week tool, route to `finance-ops`.
- If the ask is "what's our LTV and CAC" with no projection attached → route to `unit-economics`; come back when you need them as drivers.
- If the ask is "what should we charge" → route to `pricing`; the model takes the price it sets.

## 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.

```text
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
```

```text
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.

| Approach | Use it for | Strength | Failure mode if used alone |
| --- | --- | --- | --- |
| **Bottom-up** (funnel × deal size × capacity) | the monthly operating plan | grounded in levers you control | can miss that the market is too small |
| **Top-down** (TAM × penetration) | the raise / market-size slide | shows the ceiling | hides whether you can actually acquire — "0.5% of a $10B market" is wishful |

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.

```text
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.

```text
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.

## Rule 5 — scenarios are mandatory; gate assumptions against benchmarks

A single-line hockey stick with no downside reads as naive — investors stress-test the **downside first.** Build **base / downside / upside** off a small set of toggled drivers (growth rate, CAC, churn, hire timing, round close date), and report runway under each. Most cash surprises come from one of these toggles, especially the **round closing late**: model the gap and show runway if the close slips a quarter.

Then run the whole model through a reasonableness gate. Drivers far outside 2025/26 benchmarks are a red flag to **surface, not hide**:

| Check | Reasonable band | What it catches |
| --- | --- | --- |
| **Burn multiple** (net burn ÷ net new ARR) | <1.0 elite · 1.0–1.5 healthy · 1.5–2.0 ok early | capital efficiency — in SaaS Capital's 2025 survey 56% of seed / 83% of Series C+ investors call it critical |
| **Rule of 40** (growth % + FCF margin %) | ≥ 40 | the one-number sanity test; 200% growth AND positive margin is fantasy |
| **LTV:CAC** | ≥ 3:1 (top quartile 4–6:1) | acquisition economics imported from unit-economics |
| **CAC payback** | under ~12mo SMB (2025 median worsened to ~20mo) | how long cash is underwater per customer |
| **NRR** | ≥100% floor · 104–106% typical · 120%+ best | whether the install base grows itself |
| **Subscription gross margin** | 75–80%+ | is the cost build plausible |

Most companies miss Rule of 40 — McKinsey's run of 200+ software firms (2011–2021) cleared it only ~16% of the time, and Meritech's public-SaaS median sat near 12% in early 2025 — so don't claim it casually. The full benchmark sanity-table, the driver-toggle recipe, and a worked runway-under-scenarios example are in `references/benchmarks-and-scenarios.md`.

## Anti-patterns

| Bad | Good | Why |
| --- | --- | --- |
| Hockey-stick revenue, one line, no downside | base / downside / upside off toggled drivers | investors stress-test the downside first; no downside reads as naive |
| Runway computed from net income / P&L | runway from cash balance ÷ net cash burn | depreciation, prepaids, AR make profit ≠ cash; cash is the survival line |
| Outputs typed in as numbers | every output a formula off the assumptions layer | a model that doesn't re-flow is a static picture, not a model |
| Costs as one flat salary lump | per-hire schedule × fully-loaded cost × start month | headcount is the biggest early cash lever; timing moves runway by weeks |
| Revenue = TAM × wishful % only | bottom-up funnel plan, TAM as the sanity-check | top-down alone hides whether you can actually acquire |
| Raise sized to "what we can get" | sized to 18–24mo post-raise + a use-of-funds split | the runway target drives the ask, not vice-versa |
| Round closes instantly in the model | model the close date; show runway if it slips a quarter | timing risk is the most common cash surprise |
| Same ARPA / churn typed in three tabs | one fact, one cell, referenced everywhere | duplicates diverge silently and the model lies |

## Verify

The model emits a checkable artifact, so `scripts/verify.sh` runs against your generated `model.csv` (or assumptions + projection pair) and asserts **shape and internal consistency** — never whether the forecast is wise:

```bash
./scripts/verify.sh --path model.csv     # check one model file
./scripts/verify.sh --path build/        # scan a directory of model CSVs
./scripts/verify.sh --strict             # treat warnings as failures (CI gate)
```

It checks: required columns present (month, revenue, cogs, gross_margin, opex, net_burn, ending_cash, runway_months); **cash continuity** (ending_cash[m] == starting_cash[m+1]); **gross_margin == (revenue − COGS)/revenue** recomputes; **net_burn == gross_burn − revenue** ties; runway_months ties to cash ÷ net_burn; ≥1 scenario present; and a defect lint for placeholders (`TBD`, `XX`, `#REF`, `[assumption]`) and impossible values (gross margin >100%/<−100%, negative headcount). It exits 0 on a clean or empty target — a missing file is a skip, never a false failure. The schema it enforces is documented in `references/model-structure.md`.

## Hand-offs

- Need the LTV/CAC/payback that feed the drivers → `unit-economics`.
- Price/packaging the model assumes → `pricing`.
- Single-series statistical forecast of churn/ARR → `forecasting`.
- The near-term bank-reconciled cash view → `finance-ops`.
- Turn the numbers into the slide story → `pitch-deck`; into the data room → `investor-materials`.
- Run the actual round off the raise number → `fundraising`.

## references/

- `references/revenue-build.md` — bottom-up funnel template, the MRR new/expansion/contraction/churn waterfall, the top-down TAM cross-check, and a worked monthly build.
- `references/benchmarks-and-scenarios.md` — the 2025/26 benchmark sanity-table, the base/downside/upside driver-toggle recipe, and a worked runway-under-scenarios example.
- `references/model-structure.md` — the assumptions/projection row+column contract `verify.sh` enforces, the cash-continuity rule, and the `model.csv` schema with a filled mini-example.
