Inside a 3-Statement Model: From Spreadsheet to Decision: Where Most Models Stop Short

From Spreadsheet to Decision: Where Most Models Stop Short

Last week I walked a founder through her own model. She'd built it herself, three statements linked, scenarios wired in, cash flow tracking monthly. It calculated correctly. Every formula closed.

She still made the wrong hiring decision.

The model answered the question she asked: can we afford two new hires this quarter? It said yes, positive cash through year end. What it didn't show her was the answer to the question she needed: what happens if the enterprise deal we're counting on slips three months, and how long do we have to course-correct before we're in trouble?

Her model was static where her business was dynamic. It showed one future, the one where everything went to plan. It didn't show her the decision space, the range of outcomes her choice would create, or the early signals that would tell her which path she was actually on.

This is where most models stop short. They calculate, but they don't inform. They answer "what" without showing "so what" or "now what."

A working model does three things the spreadsheet alone won't: it surfaces the interdependencies (revenue timing affects hiring capacity affects cash runway), it stress-tests the decision across plausible scenarios (not just the base case), and it gives you the leading indicators to watch after you decide.

It's the difference between a forecast and decision infrastructure.

This is the fourth and final part of the Inside a 3-Statement Model series. A shorter version of this post appears on LinkedIn [LINKEDIN_POST_URL]. This is where the full depth lives.

The Model Trap

The trap is thinking the model's job is to be right.

It's not. The model's job is to show you what being wrong looks like early enough to do something about it.

Most founder-built models optimize for accuracy in the base case. They tune assumptions until the output matches the plan. Revenue grows at the expected rate, costs stay predictable, the big contract closes on time. The three statements balance. The cash flow stays positive. The model looks correct because it reflects the world as you hope it will be.

But a business doesn't run on the base case. It runs on the version of the future that actually happens, which is always some deviation from plan. The contract slips. A key hire takes longer to ramp than expected. A supplier changes payment terms. The model that looked right in July becomes useless in September, because it was built to confirm the plan, not to navigate away from it.

This compounds every build flaw from the prior three weeks. Static assumptions (week one) mean the model can't flex when reality diverges. Annual granularity (week two) hides the cash timing that kills you between quarters. Single-scenario thinking (week three) means you never tested what happens if two things go wrong at once.

The founder I walked through her model last week had all three problems at once. Her revenue assumption was a single growth rate applied uniformly across the year. Her granularity was quarterly, which meant she couldn't see the gap between when payroll hit and when the enterprise deal was supposed to fund it. And she'd only modelled the scenario where the deal closed on schedule.

When I asked what happens if the deal slips to Q1 next year, she had to rebuild the model from scratch to answer. That's not a working model. That's a spreadsheet that calculates one version of the future and stops.

What Decision Infrastructure Actually Looks Like

A working model is built around the decision, not the calculation. The decision in this case was: should we hire two people now, or wait until the enterprise deal closes?

To answer that, the model needs to show three things:

First, the interdependencies. Revenue timing affects hiring capacity affects cash runway. If the deal slips, the new hires burn cash faster than the existing business generates it. That's not a revenue problem or a hiring problem, it's a timing problem, and the model needs to show how those three variables move together.

The formula that makes this visible is the cash runway calculation:

But the monthly net burn rate itself is a function of revenue and operating expenses, which means the runway calculation needs to be dynamic, not static. When you add two hires, the burn rate increases. When revenue grows, it decreases. The model needs to recalculate runway every month based on the actual revenue and cost structure at that point in time.

In her model, runway was calculated once, at the start of the forecast period, using the average burn rate for the year. That told her she had twelve months of runway. What it didn't tell her was that if the deal slipped and she hired anyway, her runway would drop to seven months by the time she realized the deal wasn't closing on schedule.

Second, the stress test. The model needs to show what happens under plausible deviations from plan. Not worst-case scenarios, plausible ones. The deal slips three months. One of the new hires takes four months to ramp instead of two. A major customer churns mid-year.

The way to build this into the model is to create a scenario matrix that tests the decision across multiple versions of the future. Not three separate models, one model with three scenario toggles that change the key assumptions and recalculate the entire forecast.

For the hiring decision, the scenario matrix looked like this:

• Base case: Deal closes Q4, both hires ramp in two months, no churn.
• Moderate delay: Deal slips to Q1 next year, hires ramp in three months, no churn.
• Compounded delay: Deal slips to Q1, one hire ramps in four months, one major customer churns Q3.

The base case showed positive cash through year end and twelve months of runway. The moderate delay case showed cash turning negative in Q1 and runway dropping to eight months by December. The compounded delay case showed cash turning negative in Q4 and runway dropping to five months by year end.

That's the decision space. The model isn't telling her whether to hire or not. It's showing her what each version of the future looks like, so she can decide which risk she's willing to take.

Third, the leading indicators. Once the decision is made, the model needs to tell her what to watch. If she hires now, what are the early signals that she's on the moderate delay path instead of the base case path, and how much time does she have to course-correct?

The leading indicators in this case were:

• Deal velocity: if the enterprise sales cycle hasn't moved to contract review by mid-Q3, the deal is likely slipping.
• Ramp time: if the first hire hasn't closed their first deal by month two, ramp time is running longer than expected.
• Burn rate: if monthly burn exceeds the base case assumption by more than 10% for two consecutive months, the cost structure is off.

These aren't outputs the model calculates automatically. They're the questions the model helps you ask. But to ask them, the model needs to show you the variance between plan and actual in real time, which means it needs to be built with a structure that compares forecast to actuals every month and flags the deviations that matter.

The formula for variance tracking is straightforward:

But the insight comes from knowing which variances matter. A 5% revenue miss in a single month might be noise. A 5% revenue miss for three consecutive months is a trend. A 10% increase in burn rate in the same quarter as a revenue miss is a compounding problem.

The model needs to surface those patterns, not just calculate the variance.

The Practical Build

Building this into a model that doesn't require a full rebuild every time the business changes takes structure. The model I walked her through had four layers:

Layer one: the assumption sheet. Every variable that could change lives here. Revenue growth rate, gross margin, headcount, ramp time, payment terms, the timing of the enterprise deal. Each assumption has a base case value and a scenario toggle that switches it to the moderate or compounded delay value.

The assumption sheet is the only place you change inputs. The rest of the model pulls from here. That means you can test a new scenario by changing one cell, not rewriting formulas across three statements.

Layer two: the monthly forecast. Revenue, operating expenses, and cash flow calculated month by month, pulling assumptions from layer one. The monthly granularity is what lets you see the timing gaps that quarterly or annual models hide.

The revenue build in particular needs to be monthly, because revenue timing is the variable that changes most often. The formula structure looks like this:

But the monthly growth rate itself is a function of the annual growth assumption, the seasonality pattern, and the timing of large deals. In her model, the enterprise deal was modelled as a step function: zero revenue from that customer until the close month, then the full contract value recognized over the term.

That step function is what makes the deal slip scenario visible. If the deal closes in Q4, the revenue step happens in October. If it slips to Q1, the revenue step happens in January. The model recalculates cash flow for every month in between, and you can see exactly when cash turns negative.

Layer three: the three statements. Income statement, balance sheet, and cash flow statement, all linked. The income statement drives the balance sheet through retained earnings. The balance sheet drives the cash flow statement through changes in working capital. The cash flow statement closes back to the balance sheet through the ending cash balance.

The linking formula for retained earnings is:

The linking formula for cash is:

These formulas are standard, but the insight comes from building them at monthly granularity and linking them to the assumption sheet. When you change the deal timing in layer one, the revenue step moves in layer two, net income recalculates in the income statement, retained earnings update in the balance sheet, and ending cash recalculates in the cash flow statement. The entire model flexes.

Layer four: the dashboard. This is where the decision infrastructure lives. A single sheet that pulls the key outputs from the three statements and displays them as a scenario comparison.

The dashboard shows:

• Cash runway under each scenario, calculated monthly.
• Cumulative cash flow under each scenario, plotted as a line chart so you can see when each scenario turns negative.
• Variance between forecast and actuals for the current month and trailing three months, flagged red if the variance exceeds the threshold.

The dashboard is what turns the model from a calculation engine into a decision tool. You can see the range of outcomes at a glance, compare the scenarios side by side, and track whether you're on the path you expected.

The Gap Between Having a Model and Using One

The founder I walked through this with had the first three layers. She had an assumption sheet, a monthly forecast, and three linked statements. What she didn't have was the fourth layer, the dashboard that turned the model into decision infrastructure.

Without the dashboard, using the model required opening the full workbook, navigating to the cash flow statement, scrolling to the bottom to find ending cash, then manually comparing it across scenarios. That's too much friction. When using the model takes five minutes of navigation, you stop using it.

The dashboard collapses that friction to zero. One sheet, one glance, three scenarios side by side. The model becomes something you check weekly, not something you rebuild when a decision forces you to.

That's the gap between having a model and using one. The model that sits in a folder and gets updated once a quarter isn't decision infrastructure. It's a historical record. The model that lives on your screen and updates every week is the one that changes what you see early enough to act.

What This Means for the Hiring Decision

After walking through the scenario matrix, the founder made a different choice. She hired one person immediately, the role that would generate revenue fastest, and delayed the second hire until the enterprise deal reached contract review.

The model showed her that one hire kept her on the base case path even if the deal slipped moderately. Two hires pushed her onto the compounded delay path if anything else went wrong. The decision wasn't about affordability in the abstract. It was about which version of the future she was willing to bet on, and how much time she'd have to course-correct if that bet didn't play out.

Three months later, the deal did slip. It moved to Q1, exactly the moderate delay scenario. But because she'd only hired one person, her runway stayed at nine months instead of dropping to seven. She had time to adjust. She closed two smaller deals to bridge the gap, renegotiated payment terms with a major vendor, and brought the second hire on in Q1 when the enterprise deal actually closed.

The model didn't predict the slip. It showed her what the slip would cost, and gave her the time to respond.

That's what decision infrastructure does. It doesn't make you right. It makes being wrong survivable.

Where Most Models Stop Short

Most models stop at layer three. They calculate correctly, the statements link, the formulas close. But they don't show you the decision space, they don't stress-test across plausible scenarios, and they don't give you the leading indicators to track after you decide.

That's not a technical failure. It's a design failure. The model was built to answer "can we afford this?" instead of "what happens if we're wrong, and how will we know?"

The fix isn't more complexity. It's more structure. A model built around the decision, not the calculation. A scenario matrix that shows the range of outcomes, not just the base case. A dashboard that turns the model into something you use weekly, not something you rebuild quarterly.

The model that stops at calculation is a spreadsheet. The model that goes to decision is infrastructure.

---

Next week: how to build a model library that doesn't need rebuilding every time the business changes.

If your model calculates correctly but doesn't inform the decision, the structure is the gap: calendly.com/muhammed-adediran/30min