A financial model is a decision tool, not a spreadsheet. The best models are simple enough to audit and structured so the assumptions are visible. This is the method we use when building operating models and valuation models. It works for a 30-page buy-side model and for a three-tab operating plan; the difference is depth, not discipline.
Step 1: Decide what the model must answer
Before touching Excel, write down the three questions the model must answer: What is the base-case value? What drives it? What would change the answer? Every sheet and assumption exists to answer one of those. A model without a question is just a collection of tabs.
Write the answer at the top of the model as a named cell or a title block. For an M&A model it might be "what is fair equity value for the target given the capex cycle". For an internal plan it might be "what revenue, cash and headcount do we need to justify a Series B". Keep returning to that sentence when a sheet grows. If a tab does not serve one of the three questions, cut it or move it to an appendix. This single habit is what separates a model from a pile of spreadsheets.
Step 2: Structure in the standard layers
Use a clean layer structure: assumptions on top, drivers in the middle, outputs at the bottom. Inputs in blue, formulas in black, references in green is the convention for a reason: it makes the model auditable and keeps anyone from hard-coding a number into a formula cell. Set a data validation rule on every blue cell so a decimal or a negative lands somewhere it cannot break the build.
Number the sheets so the flow is obvious. Sheet 1 holds the dashboard and the summary outputs. Sheet 2 holds the assumption register. Sheets 3 to 5 hold revenue, cost and cash. Sheet 6 holds the financial statements and the outputs that the dashboard pulls from. A reviewer should be able to trace any output cell back to a driver and then to an assumption without a map. If the trail is long, you have too many intermediate tabs or too many broken references.
Step 3: Define the revenue drivers
Revenue should be driven by volume and price (or price and retention), not by a single "growth rate". For a logistics business that is freight volume and yield per lane; for SaaS it is new customers, expansion, and churn. Driver-based models are easier to stress-test than growth-rate models, because each driver means something you can go check in the real world.
Here is a worked SaaS revenue build. Start with an installed base of 4,000 customers paying $600 per seat per year, or $50 per month. Assume you add 250 new customers each month, churn runs at 3.5% per month on the existing base, and expansion revenue adds 8% of the base MRR each month. Month one MRR is $200,000 from the base. New business adds 250 x $50, or $12,500. Churn removes 3.5% of the starting $200,000, or $7,000, and expansion adds $16,000. Net MRR moves to $221,500. Run that same walk forward for 36 months and you get a projection that a reviewer can interrogate line by line. If someone asks "why is month twelve different", the answer is inside a visible driver, not hidden in a growth rate.
Step 4: Build the cost structure explicitly
Link each major cost line to a driver: fuel to volume, labour to headcount, cloud to usage. Costs that float with the business behave differently from fixed costs, and the distinction matters in the downside case. A business with 70% variable costs survives a 30% volume drop; a business with 70% fixed costs does not.
Split the cost build into three blocks. First, the direct costs that scale with units: materials, hosting per active user, payment processing at 2.9% of revenue, freight per lane. Second, the semi-fixed costs that step: sales headcount per 100 new customers, support staff per 2,000 active accounts. Third, the genuinely fixed costs: rent, software licences, senior management. Model each block separately and add a sensitivity line so a reader can see how contribution margin changes as volume moves. Also model the timing. An operating model that shows costs the month they are paid looks different from one that shows the accrual, and the cash flow only makes sense if the lag is explicit.
Step 5: Project the three statements coherently
The income statement, balance sheet and cash flow must tie together: profit feeds equity, depreciation and capex feed the balance sheet, working capital changes feed cash. A model where the balance sheet does not balance is not a model, it is a sketch.
Build the income statement from the revenue and cost blocks. Then derive cash in three steps. Start with net income, add back non-cash items such as depreciation and stock compensation, then adjust for working capital movements: receivables grow with revenue, payables grow with costs, inventory grows with volume. Add capex and repayments. For the SaaS example above, if receivables are collected in 30 days, roughly one month of revenue sits as a receivable and pulls cash. If you spend $1.2 million on product in year one, that cash leaves the balance sheet even though it is not on the income statement. The reconciliation of the cash flow to the movement in the cash balance is the test that everything ties.
Step 6: Run sensitivities on the true drivers
Stress the drivers that actually move the outcome: price, volume, cost inflation. Not the ones that are easy to change. A tornado chart showing what matters most tells the reader where to focus diligence and negotiation.
Build a two-way table for the top two drivers. For the SaaS build, put churn on one axis and monthly price on the other, and read the resulting year-three revenue across the grid. Churn at 3.0% versus 4.0% with price held at $50 changes the answer materially, and that tells you where to spend diligence effort. Then run the three standard scenarios: a base case, an upside where the best assumptions all land together, and a downside where they do not. Label each scenario with the assumptions behind it. Do not let a scenario be a single changed number; that is a sensitivity, not a scenario, and a reviewer will see through it. The downside scenario should be genuinely uncomfortable, because that is the one that survives a board discussion.
Step 7: Validate against reality
Check the output against external anchors: industry margins, comparables, market growth rates. If the model implies a margin no one in the industry achieves, the assumption is wrong, not the industry.
Compare your steady-state operating margin with the published results of three comparable companies. If SaaS peers run at 20% to 25% contribution margin and your model lands at 55%, something is off in the cost build, probably a missing line or an optimistic headcount ratio. Compare the implied market share too. If the revenue build implies you capture 40% of the addressable market in year three, that is a red flag no amount of formatting can hide. Write the comparison into the model as a reference tab so the validation is visible rather than an oral claim.
Step 8: Document the assumptions
List every assumption with its basis and flag the ones still to be validated. A model you can defend is one where every number traces to a stated assumption.
Keep an assumption register with five columns: the assumption, the value, the source, the date, and a status flag such as "validated", "estimate", or "to confirm". A customer count that came from the CRM is validated; a churn assumption pulled from an industry report is an estimate; the renewal terms of one large contract are to confirm. This register is also the natural input list for the data room. When a client asks where a number came from, the answer is already on the page. The same register lets you date the model, because assumptions go stale and the register tells you which ones to refresh before the next review.
Step 9: Build the output page for the reader
The dashboard is the part a decision-maker actually reads. Put the headline outputs at the top: revenue, EBITDA, free cash flow, and the key return metric, each with the base, upside and downside columns. Below that, the bridge from last year to next year so the movement is visible, then the cash position through time, then the sensitivity charts. Keep it to one page. If the dashboard needs more than one page, it is a report, not a dashboard, and the model's job is to let the report come from it later.
Speed it up
Design the structure first with the Financial Model builder, which lays out revenue drivers, cost structure, projections and sensitivities, and exports to a deck or Word report.