financial-modeling
Builds and stress-tests financial models for forecasting, scenario planning, and decision support — revenue build, cost structure, driver logic, and the sensitivities that show where a plan breaks. Use this to model a decision's financial consequence, build a forecast or long-range plan, evaluate an investment or hire, or pressure-test someone else's model before relying on it.
git clone --depth 1 https://github.com/cbrock84/headcount /tmp/financial-modeling && cp -r /tmp/financial-modeling/plugins/finance/skills/financial-modeling ~/.claude/skills/financial-modelingSKILL.md
# Financial modeling A model is an argument about how the business works, expressed in arithmetic. Its value is the argument, not the output precision. ## Structure Three separated layers, always: 1. **Inputs** — every assumption, in one place, each with a source and a date. An assumption buried inside a formula is invisible and therefore never challenged. 2. **Calculations** — no hard-coded numbers. Ever. A constant inside a formula is an untraceable assumption. 3. **Outputs** — the statements and the summary a decision-maker actually reads. One row, one calculation, carried consistently across periods. Models become unauditable through inconsistent rows more than through complexity. ## Build revenue from drivers Never grow a top-line by a percentage. Build it: volume × price, or accounts × retention × expansion. Driver-based models can be argued with, and being argued with is the point — a growth rate cannot be wrong, only optimistic. Cost structure separated into fixed, variable, and step-fixed. The step-fixed items are where plans break, because they move in jumps nobody modeled. ## Sensitivities are the deliverable A single-scenario model tells you nothing about risk. For every model, produce: - **Which two or three assumptions actually move the answer.** Usually far fewer than expected. - **Breakeven on each** — how wrong can this be before the decision reverses? - **Downside case** — not a haircut on the base case, but a coherent story where things go badly. If a plan only works in the base case, that is the finding. ## Reviewing someone else's model The description of a model is not evidence about the model. Check these, in this order, because each one invalidates everything after it. - **Trace one number end to end.** Pick an output that matters and follow it back to inputs. If you cannot, nobody else has either, and the model has never actually been reviewed. - **Find the hard-coded constants.** Search the calculation area for typed numbers. Each one is an assumption that escaped the input sheet, and they are where overrides hide. - **Check the row consistency.** A formula that differs partway across a row is either a deliberate change nobody documented or an error, and the two look identical. - **Test the extremes.** Set a key driver to zero and to double. Models frequently break, go negative in impossible ways, or fail to respond at all — which tells you the driver is decorative. - **Check that the statements tie.** Cash flow reconciles to the balance sheet movement; the balance sheet balances in every period, not just the first. - **Ask what is missing.** Working capital, hiring lag, churn, price changes, tax, and the step costs that come with growth are the omissions that flatter a plan most. **Then find the assumption doing the work.** Most models rest on one or two numbers, and those are usually the least evidenced. Ask where each came from and what it is based on — the answer is frequently that it was chosen to make the case work, which is a fine thing to know before relying on it. ## Presenting Lead with the answer, then the two assumptions it rests on most heavily, then what would change it. Never present a model without stating what it is most sensitive to — the recipient will assume robustness you did not claim. ## Never - Report a number to more precision than the assumptions support. Five significant figures from a guessed growth rate is false confidence. - Build a model whose logic you cannot explain in three sentences. - Change an assumption to reach a desired output without labeling it as a target case.
Corporate Strategy (CSO). Owns plugins/corporate-strategy/** and nothing else. Delegate work in this department's remit here.
Customer Experience (CCO). Owns plugins/customer-experience/** and nothing else. Delegate work in this department's remit here.
Data & Analytics (CDO). Owns plugins/data-analytics/** and nothing else. Delegate work in this department's remit here.
Demand Generation (CMO). Owns plugins/demand-generation/** and nothing else. Delegate work in this department's remit here.
Office of the CEO. Owns plugins/executive/** and nothing else. Delegate work in this department's remit here.
Finance (CFO). Owns plugins/finance/** and nothing else. Delegate work in this department's remit here.
Corporate IT. Owns plugins/it-operations/** and nothing else. Delegate service desk, systems and network administration, virtualization and cloud, telephony and conferencing, endpoints, assets, identity lifecycle, and backup work here.
Reviewer-class. Read-only review of what other departments commit to — contract terms, privacy and data handling, risk acceptance, and compliance findings. Holds no write surface. Its findings are not overrulable by the department under review.