financial-modeling

$npx mdskill add mkurman/zorai/financial-modeling

Build robust financial models with explicit assumptions and scenarios.

  • Creates DCF analyses, revenue forecasts, and cap tables from inputs.
  • Integrates with spreadsheet modeling and budgeting planning tools.
  • Structures outputs around multiple scenarios rather than single estimates.
  • Delivers clear inputs sections for every key financial assumption.

SKILL.md

.github/skills/financial-modelingView on GitHub ↗
---
name: financial-modeling
version: 0.1.0
description: >
  Use this skill when building financial models, DCF analyses, revenue forecasts,
  scenario analyses, or cap tables. Triggers on DCF, LBO, revenue forecasting,
  scenario analysis, cap tables, financial projections, valuation, unit economics,
  and any task requiring financial model design or analysis.
tags: [financial-modeling, dcf, valuation, forecasting, cap-table, analysis, experimental-design, sales, finance, simulation]
category: operations
recommended_skills: [budgeting-planning, financial-reporting, startup-fundraising, spreadsheet-modeling]
platforms:
  - claude-code
  - gemini-cli
  - openai-codex
license: MIT
maintainers:
  - github: maddhruv
---

## Key principles

1. **Assumptions drive everything - make them explicit** - A model is only as good
   as its inputs. Every key assumption (growth rate, churn, gross margin) should
   live in a clearly labeled inputs section, not be buried in formulas. If you
   can't defend an assumption in 10 seconds, it's not ready.

2. **Build for scenarios, not point estimates** - A single-case model is a false
   sense of precision. Reality will land somewhere between your bear and bull cases.
   Structure every model with at least three scenarios from day one - it forces you
   to think about the range of outcomes, not just the hoped-for one.

3. **Separate inputs, calculations, and outputs** - Inputs (assumptions) belong in
   one section. Formulas (calculations) reference only inputs or other calculations.
   Outputs (charts, summaries) reference only calculations. Never hard-code a number
   in a formula that should be an assumption. This separation makes auditing and
   updating the model fast and safe.

4. **Stress test the downside** - Most financial models are too optimistic. Reverse-
   engineer the downside: "What churn rate makes this business unviable?" or "What
   growth rate do we need to hit break-even in 18 months?" Knowing the failure
   thresholds is more valuable than the base case.

5. **The model is a tool, not the answer** - A model produces a range, not a verdict.
   Use it to understand sensitivity, pressure-test logic, and communicate trade-offs.
   Never present a DCF output as a price target without showing the key sensitivities.
   The goal is better thinking, not false precision.

---

## Core concepts

### Three-statement model

The foundation of any serious financial model. The three statements are interconnected:

| Statement | What it shows | Key link |
|---|---|---|
| **Income statement** | Revenue, costs, profit over a period | Net income flows to retained earnings |
| **Balance sheet** | Assets, liabilities, equity at a point in time | Cash from cash flow statement |
| **Cash flow statement** | Actual cash in/out, reconciles profit to cash | Starts from net income |

For most startup models, a simplified version suffices: revenue build, gross margin,
operating expenses, and ending cash balance. Add the balance sheet and full cash flow
statement when modeling working capital, debt, or M&A.

### DCF mechanics

A DCF (Discounted Cash Flow) values a business by the present value of its future
free cash flows. The mechanics:

1. Project free cash flows (FCF = EBIT*(1-tax rate) + D&A - capex - change in working capital)
2. Choose a discount rate (WACC for the whole business, cost of equity for equity-only)
3. Calculate terminal value (Gordon Growth or exit multiple)
4. Discount all cash flows back to today using: `PV = CF / (1 + r)^n`
5. Sum the present values - that is the enterprise value

The terminal value typically represents 60-80% of DCF value. This makes the discount
rate and terminal growth rate the two most important (and most uncertain) inputs.

### Unit economics

Unit economics measure the profitability of a single customer or transaction:

- **LTV (Lifetime Value)**: `(ARPU * Gross Margin %) / Churn Rate`
- **CAC (Customer Acquisition Cost)**: Total sales & marketing spend / new customers acquired
- **LTV:CAC ratio**: Benchmark 3:1 or higher for healthy SaaS
- **CAC Payback Period**: `CAC / (ARPU * Gross Margin %)` - months to recover acquisition cost
- **Contribution Margin**: Revenue minus variable costs per unit

### Cap table structure

A cap table tracks ownership in a company across all shareholders:

- **Pre-money valuation**: Company value before new investment
- **Post-money valuation**: `Pre-money + new investment`
- **Price per share**: `Pre-money valuation / fully diluted shares outstanding`
- **Dilution**: Each new share issued reduces existing shareholders' ownership percentage
- **Option pool shuffle**: Investors often require the option pool to be created pre-money,
  which dilutes founders, not investors - model this explicitly

---

## Common tasks

### Build a SaaS revenue forecast - bottoms-up model

Start from customer counts, not a top-down percentage. Bottoms-up is more defensible:

```
New customers per month  = (Website visitors * conversion rate)
                         OR (SDR capacity * meeting rate * close rate)

Monthly Recurring Revenue (MRR):
  Starting MRR
  + New MRR       (new customers * ARPU)
  + Expansion MRR (upsells/upgrades)
  - Churned MRR   (prior MRR * churn rate)
  = Ending MRR

ARR = Ending MRR * 12
```

Layer in gross margin (typically 60-80% for SaaS) to get gross profit. Model
cohort-level retention to capture expansion revenue and logo churn separately.

> Key assumption to stress test: monthly churn rate. At 2% monthly churn, you lose
> ~21% of revenue per year. At 5%, you lose ~46%. The business model changes entirely.

### Build a DCF valuation - step by step

1. **Project revenue** - use a bottoms-up model for years 1-3, apply a fade to a
   long-run growth rate for years 4-10
2. **Project margins** - start from current gross/EBIT margin, model expansion
   toward a steady-state comparable (check public comps)
3. **Calculate unlevered FCF** - EBIT * (1-tax) + D&A - Capex - change in NWC
4. **Set the discount rate** - For early-stage: use 20-35% (reflects risk premium).
   For public comps-based: use WACC (8-12% range for established businesses)
5. **Calculate terminal value** - Use exit multiple (EV/EBITDA or EV/Revenue) anchored
   to comparable public companies. Cross-check with Gordon Growth model
6. **Discount and sum** - `Enterprise Value = Sum(FCF / (1+r)^t) + TV / (1+r)^n`
7. **Bridge to equity value** - `Equity Value = Enterprise Value - Net Debt`

> Sanity check: implied revenue multiple at your DCF value vs current comps. If your
> DCF implies a 30x revenue multiple when comps trade at 8x, revisit your assumptions.

### Model unit economics - LTV/CAC/payback

Build a cohort model to make unit economics concrete:

```
Inputs:
  ARPU (monthly)      = $500
  Gross margin        = 75%
  Monthly churn       = 2%
  Blended CAC         = $3,000

Calculations:
  Average customer life  = 1 / 2% = 50 months
  LTV                    = $500 * 75% * 50 = $18,750
  LTV:CAC ratio          = $18,750 / $3,000 = 6.25x  (healthy)
  CAC payback period     = $3,000 / ($500 * 75%) = 8 months  (excellent)
```

Model the blended CAC separately by channel (paid, organic, sales) - blended CAC
hides the efficiency differences between channels.

### Create scenario analysis - base/bull/bear

Scenario analysis is not sensitivity analysis. Scenarios change multiple assumptions
together to tell a coherent story:

| Assumption | Bear Case | Base Case | Bull Case |
|---|---|---|---|
| Monthly growth rate | 5% | 12% | 20% |
| Monthly churn | 4% | 2% | 1% |
| Gross margin | 60% | 72% | 78% |
| Sales efficiency | 0.5x | 0.8x | 1.2x |

Build a single scenario toggle (a dropdown or input cell) that switches all
assumptions at once. Never copy-paste a model three times - use one model with a
scenario selector feeding the inputs section.

### Build a cap table - pre/post money

Track shares and ownership through each round:

```
Founding:
  Founders: 8,000,000 shares = 100%

Seed round ($2M on $8M pre-money):
  Pre-money valuation:   $8,000,000
  New shares issued:     2,000,000  (= $2M / ($8M / 8M shares))
  Post-money valuation:  $10,000,000
  Post-money ownership:
    Founders: 8M / 10M = 80%
    Seed investors: 2M / 10M = 20%

With 10% option pool (created pre-money):
  Pre-money shares:  8M founders + 889K options = 8,889K
  Price per share:   $8M / 8,889K = $0.90
  New shares:        $2M / $0.90 = 2,222K
  Founders post:     8M / 11,111K = 72%  (option pool diluted founders, not investors)
```

### Model operating expenses - by department

Build headcount-driven opex, not a percentage of revenue:

```
For each department (Eng, Sales, Marketing, G&A, CS):
  Headcount plan (by month)
  x Average fully-loaded cost per head (salary + benefits + equipment ~1.25x base)
  = Headcount expense

  + Non-headcount budget (tools, contractors, marketing spend)
  = Total department expense
```

Sum all departments for total opex. Overlay on gross profit to get EBITDA and
cash burn. Always model month-end headcount, not average - hiring lag matters.

### Sensitivity analysis - data tables

Use two-variable data tables to visualize how the outcome changes across key inputs:

```
Example: IRR sensitivity to entry multiple and exit multiple

             Exit Multiple
             6x    8x    10x   12x
Entry  4x  | 22%  | 35%  | 46%  | 56%
Multi  6x  |  8%  | 19%  | 29%  | 38%
       8x  | -2%  |  8%  | 17%  | 25%
      10x  | -9%  |  0%  |  8%  | 16%
```

Always pick the two inputs with the highest impact on your output for the table.
For a DCF, that is almost always discount rate vs terminal growth rate, or
discount rate vs exit multiple.

---

## Anti-patterns

| Anti-pattern | Why it's wrong | What to do instead |
|---|---|---|
| Hard-coding numbers in formulas | Model becomes impossible to audit or update | All assumptions in a labeled inputs section; formulas reference inputs |
| Single-point forecast | Creates false precision, hides risk | Build three scenarios minimum; show a range |
| Top-down revenue forecast ("we'll capture 1% of a $10B market") | Untestable, disconnected from reality | Bottoms-up from unit economics and customer acquisition drivers |
| Ignoring churn in a SaaS model | Overstates long-run revenue dramatically | Model cohort-level retention, separate logo vs revenue churn |
| Using pre-money option pool in cap table wrong | Underestimates founder dilution | Model option pool shuffle explicitly; show pre vs post ownership for each party |
| Confusing cash profit with accounting profit | Profitable companies go bankrupt from cash timing | Always include a cash flow / burn schedule; track change in working capital |

---

## Gotchas

1. **Terminal value represents 60-80% of DCF value - small changes to terminal growth rate or discount rate swing valuation by 30-50%** - This makes the DCF highly sensitive to two of its most uncertain inputs. Always show a sensitivity table of terminal growth rate vs discount rate alongside any DCF output, or the number is meaningless as a standalone figure.

2. **Monthly churn compounded annually is much worse than it looks** - 2% monthly churn sounds small but means ~21% annual revenue loss. Founders often model monthly churn in isolation and miss the compounding effect on ARR. Build a cohort model that shows the revenue retention curve over 12-24 months to make this visible.

3. **Option pool shuffle dilutes founders pre-money, not investors post-money** - When VCs require an option pool refresh at the time of investment, they typically require it to be created using pre-money shares. This means founders bear 100% of the dilution. A $10M pre-money valuation with a 10% option pool refresh effectively reduces the founder's pre-money valuation to ~$9M. Model this explicitly in cap table scenarios.

4. **Blended CAC hides channel efficiency differences** - If paid search CAC is $5,000 and organic CAC is $500, a blended $2,000 CAC looks reasonable but the business is critically dependent on a channel that could turn off. Always model CAC by channel separately to understand which channels are economically viable.

5. **"Scenario analysis" with only revenue assumptions changed is not scenario analysis** - A true scenario represents a coherent narrative where multiple assumptions change together (growth rate, churn, gross margin, sales efficiency all move in the same direction). Changing only one variable while holding others constant is sensitivity analysis, which is a different and complementary tool.

---

## References

For detailed benchmarks, formulas, and worked examples:

- `references/saas-metrics.md` - SaaS financial metrics definitions, benchmarks, and
  industry standards (MRR, ARR, NRR, LTV:CAC, Rule of 40, magic number)

Only load a references file if the current task requires it - they are detailed and
will consume context.

---

## Companion check

> On first activation of this skill in a conversation: check which companion skills are installed by running `ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null`. Compare the results against the `recommended_skills` field in this file's frontmatter. For any that are missing, mention them once and offer to install:
> ```
> npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>
> ```
> Skip entirely if `recommended_skills` is empty or all companions are already installed.

More from mkurman/zorai

SkillDescription
account-management>
agile-scrum>
albumentationsFast image augmentation library (Albumentations). 70+ transforms for classification, segmentation, object detection, keypoints, and pose estimation. Optimized OpenCV-based pipeline with unified API across all CV tasks. Supports images, masks, bounding boxes, and keypoints simultaneously. Note: classic Albumentations (MIT) is no longer maintained; successor AlbumentationsX uses AGPL-3.0. For torchvision-native augmentations, use torchvision.transforms.v2.
aml-complianceAnti-Money Laundering (AML) and Know Your Customer (KYC) compliance workflow. Sanctions screening, PEP detection, transaction monitoring, suspicious activity reporting (SAR), and OFAC compliance.
anki-connectThis skill is for interacting with Anki through AnkiConnect, and should be used whenever a user asks to interact with Anki, including to read or modify decks, notes, cards, models, media, or sync operations.
approval-checkpoint-long-taskCanonical long-task pack for daemon-managed work with deliberate approval checkpoints, status summaries, rollback notes, and mobile-safe governance-aware updates.
auditing-goal-artifactsUse when reviewing recent zorai goal run outputs, closure markers, ledgers, or evidence bundles to judge whether completion is credible or to identify remaining uncertainty.
autogenAutoGen (Microsoft) — multi-agent conversation framework. Agent-to-agent chat, code generation & execution, tool use, group chat, and human-in-the-loop. Build collaborative AI systems with specialized agents.
backtraderPython backtesting framework for trading strategies. Data feeds, brokers, analyzers, and live trading support. Strategy development with commission models, slippage, and signal-based execution.
beautiful-mermaidRender Mermaid diagrams as SVG and PNG using the Beautiful Mermaid library. Use when the user asks to render a Mermaid diagram.