SaaS Financial Model: The Build That Survives Buyer Diligence

Most SaaS finan­cial mod­els are wrong in a way that does­n’t show up until it costs you mon­ey. They look pol­ished. The tabs are col­or-cod­ed. The sum­ma­ry page has a chart that goes up and to the right. And then a buy­er’s ana­lyst spends forty-five min­utes with it and finds that the rev­enue line is a hard-cod­ed num­ber some­one typed in, the “25% growth” assump­tion has no oper­a­tional basis, and there’s no bal­ance sheet — which means deferred rev­enue and work­ing cap­i­tal don’t exist in the mod­el at all.

A SaaS finan­cial mod­el is the doc­u­ment that trans­lates your oper­a­tional real­i­ty into a three-state­ment fore­cast a sophis­ti­cat­ed buy­er or lender can stress-test. The word that mat­ters in that sen­tence is trans­lates. If your mod­el can’t trace every dol­lar of fore­cast­ed rev­enue back to a real oper­a­tional dri­ver you’ve actu­al­ly hit before, it isn’t a mod­el — it’s a wish with for­mat­ting. This is the sin­gle biggest rea­son a finan­cial mod­el fails dili­gence, and it’s entire­ly avoid­able.

This guide is for the SaaS CEO at $5M–$15M ARR who’s build­ing toward an exit, a raise, or a debt facil­i­ty, and who needs the mod­el to do real work — not just sit in a board deck. I’ll walk through what a real SaaS finan­cial mod­el con­tains, how to make it dri­ver-based instead of made-up, the three state­ments that have to con­nect, the sce­nario log­ic that buy­ers expect, and the spe­cif­ic mis­takes that get mod­els thrown out. There’s a worked exam­ple through­out so you can see the math, not just read about it.

The Difference Between a Financial Model and an Operating Model

Here’s the dis­tinc­tion almost nobody draws, and it’s the one that sep­a­rates a mod­el that sur­vives dili­gence from one that does­n’t.

A finan­cial mod­el tells you the num­bers: rev­enue next year, EBITDA, cash bal­ance, the fore­cast line you present to the board. An oper­at­ing mod­el tells you the activ­i­ty under­neath those num­bers — units of work, con­ver­sion rates, head­count, the things peo­ple actu­al­ly do that pro­duce the finan­cial result. The finan­cial mod­el is the out­put. The oper­at­ing mod­el is the engine.

Most founders build the finan­cial mod­el and skip the oper­at­ing mod­el. They decide they want to grow from $10M to $15M ARR, they type a growth rate into a cell, and the spread­sheet obe­di­ent­ly pro­duces a beau­ti­ful fore­cast. The prob­lem is that noth­ing in that spread­sheet explains how the $5M of new ARR gets gen­er­at­ed. How many new cus­tomers? At what aver­age con­tract val­ue? Requir­ing how many sales reps, hit­ting what quo­ta, fed by how many qual­i­fied leads, at what cost per lead? None of that is in a pure finan­cial mod­el.

When a pri­vate-equi­ty buy­er or a strate­gic investor eval­u­ates your plan, they don’t poke at the finan­cial mod­el. They poke at the oper­at­ing mod­el under­neath it. The ques­tion is always the same: did you make these num­bers up, or is this an empir­i­cal track record? A founder who can answer “we’ve hit this con­ver­sion num­ber for eight quar­ters in a row with very lit­tle vari­ance, and 85% of our new sales engi­neers reach full pro­duc­tiv­i­ty with­in 60 days” has a mod­el that holds. A founder whose growth assump­tion is a round num­ber with noth­ing behind it does not.

So the real instruc­tion is this: build the oper­at­ing mod­el first, then let it feed the finan­cial mod­el. The dri­vers — cus­tomers, ACV, churn, head­count, activ­i­ty ratios — live in the oper­at­ing lay­er. The finan­cial state­ments are down­stream of them. This order­ing is what makes the rest of this guide work.

What a Real SaaS Financial Model Contains

A com­plete SaaS finan­cial mod­el has a small num­ber of tabs that each do one job. More tabs than this and you’ve added com­plex­i­ty that hides errors; few­er and you’ve left some­thing out that a buy­er will ask for.

Tab	What it does	Why a buyer wants it
Assumptions	One page holding every input driver — acquisition rate, ACV, churn, gross margin, hiring plan, marketing spend	A single source of truth; nothing hard-coded downstream
MRR / ARR Bridge	Walks recurring revenue forward month by month: starting, + new, + expansion, − contraction, − churn, = ending	Shows revenue is built from movements, not typed in
Headcount Schedule	Hiring plan by role and month, with fully-loaded cost	Ties the largest expense line to the growth plan
Three-Statement Model	Linked P&L, balance sheet, and cash flow statement	The core financial output; what reconciles to your books
Dashboard	The metrics that matter — ARR, growth, NRR, CAC payback, LTV/CAC, Rule of 40, burn, runway	What gets reviewed first, by you and by buyers

The dis­ci­pline that makes this work is one rule: every num­ber lives in exact­ly one place and flows every­where else by for­mu­la. Your churn assump­tion is entered once, on the Assump­tions tab. The MRR bridge reads it. The LTV cal­cu­la­tion on the dash­board reads it. The cash flow state­ment reads the rev­enue it pro­duces. Change churn from 2% to 1.5% in that one cell, and every down­stream num­ber updates auto­mat­i­cal­ly. The moment a buy­er finds the same input typed inde­pen­dent­ly into three dif­fer­ent tabs, they stop trust­ing the whole file — because now they have to check whether those three val­ues agree, and they usu­al­ly don’t.

Driver-Based Forecasting: Where the Revenue Actually Comes From

Dri­ver-based mod­el­ing means your rev­enue fore­cast is the out­put of oper­a­tional assump­tions, not an input you chose. You don’t fore­cast “$15M ARR.” You fore­cast the dri­vers that pro­duce it, and $15M (or what­ev­er it real­ly is) falls out of the math.

For a B2B SaaS busi­ness, the core rev­enue dri­vers are a short list:

1. New cus­tomers acquired per month, ide­al­ly split by seg­ment, because acqui­si­tion rate and con­tract val­ue vary enor­mous­ly across seg­ments.
2. Aver­age con­tract val­ue (ACV) by seg­ment — what each new cus­tomer is worth in annu­al­ized recur­ring rev­enue.
3. Churn rate by cohort — the per­cent­age of recur­ring rev­enue you lose each peri­od, mea­sured as gross rev­enue churn so you can see the leak before expan­sion masks it.
4. Expan­sion rev­enue — upsells, seat growth, and price increas­es from your exist­ing base.
5. Sales capac­i­ty — reps, quo­ta, and ramp time, because you can’t acquire cus­tomers faster than your sales engine can sell.

Let me make this con­crete. Sup­pose you’re at $10M ARR, which is $833,333 in MRR (month­ly recur­ring rev­enue). Your oper­at­ing mod­el says:

• You add 18 new cus­tomers per month at an aver­age ACV of $30,000, so new MRR is 18 × ($30,000 ÷ 12) = $45,000 per month.
• Your gross rev­enue churn is 1.5% of MRR per month, so you lose $833,333 × 1.5% = $12,500 of MRR in month one.
• Your expan­sion runs 1.2% of MRR per month, adding $833,333 × 1.2% = $10,000.

Net new MRR in month one is $45,000 + $10,000 − $12,500 = $42,500. End­ing MRR is $833,333 + $42,500 = $875,833. Run that bridge for­ward twelve months — com­pound­ing off the new base each month — and you don’t assume an end­ing ARR, you derive one. (The com­pound­ing mat­ters: churn and expan­sion apply to a grow­ing base, so you can’t just mul­ti­ply month one by twelve.)

This is the whole point. The growth rate isn’t an assump­tion — it’s a con­se­quence. And every one of those input dri­vers is some­thing you can defend with your own his­tor­i­cal data. When the buy­er asks “where does the $15M come from?”, the answer is “18 cus­tomers a month at $30K, which we’ve sus­tained for the last six quar­ters,” not “we fig­ured 50% growth seemed achiev­able.”

A note on bench­marks and rates. The spe­cif­ic num­bers in this guide — churn rates, con­tract val­ues, val­u­a­tion mul­ti­ples — are illus­tra­tive and reflect typ­i­cal con­di­tions for mid-mar­ket B2B SaaS at the time of writ­ing. They’re here to show the rela­tion­ships between dri­vers, not to serve as cur­rent absolute val­ues. Use your own his­tor­i­cal data for the inputs, and ver­i­fy any mar­ket bench­mark before you rely on it in a real mod­el.

The Three Statements, and Why You Can’t Skip the Balance Sheet

A real finan­cial mod­el pro­duces three inte­grat­ed state­ments: the prof­it and loss state­ment (P&L), the bal­ance sheet, and the cash flow state­ment. Most founder-built SaaS mod­els include only the P&L. That’s the gap that sig­nals “ama­teur” to any­one who reviews mod­els for a liv­ing.

The P&L (Profit and Loss)

The P&L flows rev­enue and costs from your dri­ver tabs down to EBITDA and net prof­it. Rev­enue comes from the MRR bridge. Cost of goods sold (COGS) — host­ing, infra­struc­ture, cus­tomer sup­port, and the cost of deliv­er­ing the ser­vice — comes off the top to give you gross prof­it. Oper­at­ing expens­es (sales and mar­ket­ing, R&D, G&A) come from the head­count sched­ule plus your spend assump­tions. What’s left is EBITDA (earn­ings before inter­est, tax­es, depre­ci­a­tion, and amor­ti­za­tion — essen­tial­ly oper­at­ing prof­it before financ­ing and account­ing effects).

The Balance Sheet

This is the one founders skip, and it’s the one that con­tains the most SaaS-spe­cif­ic truth. For a sub­scrip­tion busi­ness, the bal­ance sheet cap­tures:

• Deferred rev­enue — when a cus­tomer pays for an annu­al con­tract upfront, you’ve col­lect­ed the cash but haven’t earned the rev­enue yet. That gap is a lia­bil­i­ty that sits on the bal­ance sheet and unwinds over the con­tract term. For a SaaS com­pa­ny sell­ing annu­al con­tracts, deferred rev­enue is often one of the largest items on the bal­ance sheet, and it’s a major source of cash.
• Accounts receiv­able — rev­enue you’ve earned but not yet col­lect­ed, com­mon when you bill month­ly in arrears.
• Cash — the bal­ance that deter­mines your run­way.
• Debt — any ven­ture debt or facil­i­ty, with its covenants.

Skip the bal­ance sheet and you’ve thrown away the mod­el­ing of deferred rev­enue and work­ing cap­i­tal — which for a SaaS busi­ness is a huge part of how cash actu­al­ly behaves. An annu­al-pre­pay busi­ness can be grow­ing fast and gen­er­at­ing cash from deferred rev­enue even while it’s unprof­itable on a P&L basis. A month­ly-billing busi­ness grow­ing just as fast might be cash-starved. The P&L looks sim­i­lar in both cas­es. The bal­ance sheet and cash flow state­ment are where the dif­fer­ence lives.

The Cash Flow Statement

This rec­on­ciles your P&L prof­it to actu­al cash move­ment. It starts from net income, adds back non-cash charges, adjusts for work­ing-cap­i­tal changes (the deferred-rev­enue and receiv­ables move­ments from the bal­ance sheet), and sub­tracts cap­i­tal expen­di­ture and financ­ing flows. The out­put is the change in your cash bal­ance — which has to tie back exact­ly to the cash line on the bal­ance sheet.

When the three state­ments con­nect, chang­ing any sin­gle assump­tion updates all three auto­mat­i­cal­ly. That’s what a sophis­ti­cat­ed review­er means when they say they want a dynam­ic mod­el and not a sta­t­ic spread­sheet. Drop churn by half a point, and you should see rev­enue rise on the P&L, deferred rev­enue and cash shift on the bal­ance sheet, and run­way extend on the cash flow state­ment — all from one cell change. If your three state­ments don’t tie out, the mod­el is bro­ken, and it will be obvi­ous to any­one who foots the cash bal­ance against the bal­ance sheet.

Scenario Planning: Three Cases, One Toggle

Every seri­ous SaaS finan­cial mod­el sup­ports at least three sce­nar­ios, dri­ven by a sin­gle tog­gle on the assump­tions page that switch­es the mod­el between cas­es. This isn’t dec­o­ra­tion — it’s how you and a buy­er both pres­sure-test the plan.

Scenario	What you vary	What it answers
Base case	Your honest best estimate of each driver	"What do we actually expect to happen?"
Conservative	Lower acquisition, higher churn, slower hiring	"If things go sideways, do we run out of cash?"
Upside	Faster acquisition, stronger expansion, more spend	"If we lean in, what's the ceiling — and what does it cost?"

The mechan­ic is sim­ple: build a sce­nario selec­tor (a drop­down or a 1/2/3 switch) on the assump­tions tab, and have each dri­ver pull from a base/conservative/upside col­umn based on the selec­tion. Flip the tog­gle, and the entire three-state­ment mod­el re-fore­casts.

The sce­nario that gets the least atten­tion and mat­ters the most is the con­ser­v­a­tive case, because that’s the one that tells you your real run­way. If your run­way (cash bal­ance divid­ed by aver­age month­ly net burn) drops below 12 months in the con­ser­v­a­tive case, you have a financ­ing deci­sion to make now, not when you dis­cov­er it in nine months. I’ve watched founders fall in love with the base case and nev­er look at the con­ser­v­a­tive one — and then get sur­prised by exact­ly the down­side the con­ser­v­a­tive case would have shown them.

There’s a dis­ci­pline point here from the way good oper­a­tors frame a request for a mod­el: spec­i­fy what you actu­al­ly want. “Build me a finan­cial mod­el” is hope­less­ly vague — some­one could build nine­teen dif­fer­ent ones. “Build me a 24-month, month­ly P&L fore­cast off the last three years of data, with two sce­nar­ios side by side, subto­tals by quar­ter and fis­cal year, mod­el­ing sta­tus quo ver­sus a seg­ment-lev­el growth change” is a spec some­one can actu­al­ly deliv­er and you can actu­al­ly eval­u­ate. The same pre­ci­sion you’d demand from who­ev­er builds the mod­el, demand from your­self when you set up the sce­nar­ios.

The Metrics a Buyer Checks First

Your mod­el’s dash­board should sur­face the met­rics that deter­mine whether the busi­ness is fun­da­men­tal­ly healthy — and these are pre­cise­ly the num­bers a buy­er or investor checks before they read any­thing else. If these aren’t on a sin­gle dash­board tab pulling live from the mod­el, you’re mak­ing the review­er do work, and review­ers who have to do work get sus­pi­cious.

Here are the core ones, with the canon­i­cal for­mu­las:

• NRR (Net Rev­enue Reten­tion) = (Starting MRR − Churned MRR − Contraction MRR + Expansion MRR) ÷ Starting MRR. Above 100% means your exist­ing base grows on its own, even with zero new cus­tomers; below 100% means you’re decay­ing and have to acquire just to stand still. This is the sin­gle most pre­dic­tive met­ric for a SaaS com­pa­ny’s ceil­ing.
• CAC Pay­back Peri­od = CAC ÷ (Monthly ARPA × Gross Margin %), where CAC (cus­tomer acqui­si­tion cost) is total sales and mar­ket­ing spend divid­ed by new cus­tomers acquired, and ARPA is aver­age rev­enue per account. This tells you how many months of gross prof­it it takes to earn back the cost of land­ing a cus­tomer. Under 12 months is strong for mid-mar­ket SaaS; over 24 and your growth is eat­ing cash faster than it returns it.
• LTV/CAC Ratio = LTV ÷ CAC, where LTV = (Monthly ARPA × Gross Margin %) ÷ Monthly Churn Rate. The direc­tion­al­i­ty mat­ters: it’s LTV over CAC, not the reverse. A ratio around 3:1 or bet­ter is the con­ven­tion­al health line.
• Rule of 40 = ARR YoY Growth Rate % + EBITDA Margin %. If the sum is 40 or more, the mar­ket reads the busi­ness as bal­anc­ing growth and prof­itabil­i­ty well. It’s the sin­gle-sen­tence fil­ter investors apply first.
• Burn Mul­ti­ple = Net Burn ÷ Net New ARR over a peri­od. It answers how many dol­lars you burn to gen­er­ate one dol­lar of new recur­ring rev­enue. Low­er is bet­ter; under 1.0x is excel­lent, over 2.0x is a flag.

Let me work one so the for­mu­la isn’t abstract. Take a cohort: start­ing MRR of $100,000, churned MRR of $5,000, con­trac­tion MRR of $2,000, expan­sion MRR of $15,000. NRR is ($100,000 − $5,000 − $2,000 + $15,000) ÷ $100,000 = $108,000 ÷ $100,000 = 108%. That 108% means this cohort grew 8% over the peri­od with­out a sin­gle new cus­tomer — and a buy­er will pay a mean­ing­ful­ly high­er mul­ti­ple for a base that does that than for one sit­ting at 95%.

One more prin­ci­ple that the met­rics make vis­i­ble: seg­ment every­thing. Com­pa­ny-wide aver­ages hide the truth. Cal­cu­late NRR, churn, CAC pay­back, and LTV/CAC by seg­ment — ver­ti­cal, con­tract size, acqui­si­tion chan­nel — and you’ll almost always find sig­nif­i­cant vari­ance. One seg­ment is car­ry­ing the busi­ness; anoth­er is qui­et­ly destroy­ing val­ue. A mod­el that only shows blend­ed met­rics can’t sur­face that, and the moment a buy­er seg­ments your data them­selves and finds it, you’ve lost con­trol of the nar­ra­tive. Build the seg­men­ta­tion into the mod­el so you’re the one who finds it first.

The Mistakes That Get Models Thrown Out

These are the fail­ure modes that show up over and over, in rough­ly the order a review­er encoun­ters them.

1. Hard-cod­ed rev­enue. A rev­enue num­ber typed direct­ly into a cell instead of cal­cu­lat­ed from dri­vers. The instant a review­er clicks a rev­enue cell and sees a con­stant instead of a for­mu­la, the mod­el los­es cred­i­bil­i­ty. Every rev­enue fig­ure must trace to the MRR bridge, which traces to the dri­vers.
2. Assump­tions with no oper­a­tional basis. A growth rate or churn num­ber with noth­ing behind it. If you can’t answer “how do we hit this, and when have we hit it before?”, nei­ther can the buy­er — and they’ll assume the answer is “we can’t.”
3. No bal­ance sheet. Cov­ered above. No bal­ance sheet means no deferred rev­enue, no work­ing cap­i­tal, and a cash fore­cast that’s qui­et­ly fic­tion for any busi­ness that pre­pays or bills in arrears.
4. Incon­sis­tent time peri­ods. Some tabs month­ly, some quar­ter­ly, with bro­ken links between them. Pick month­ly for the fore­cast peri­od (24 months is the stan­dard ask), and roll up to quar­ters and years with subto­tals — don’t mix gran­u­lar­i­ty across tabs.
5. Over-com­plex­i­ty. A mod­el with six­ty tabs and cir­cu­lar ref­er­ences nobody can fol­low is worse than a clean one with six. Com­plex­i­ty hides errors; it does­n’t add rig­or. If you can’t explain how a num­ber is built in two sen­tences, sim­pli­fy the build.
6. Blend­ed met­rics only. No seg­men­ta­tion, so the vari­ance that actu­al­ly runs the busi­ness is invis­i­ble. Build seg­ment-lev­el views in from the start.

Notice that five of these six are cred­i­bil­i­ty fail­ures, not arith­metic fail­ures. The mod­el can be math­e­mat­i­cal­ly cor­rect and still get thrown out because the review­er can’t trace where the num­bers come from. Trace­abil­i­ty is the prod­uct.

When to Build It Yourself vs. Bring in a CFO

Below rough­ly $5M ARR, the founder usu­al­ly builds and owns the mod­el, and that’s fine — the busi­ness is sim­ple enough that a clean dri­ver-based spread­sheet does the job. The build itself is a use­ful forc­ing func­tion: you can’t mod­el the dri­vers with­out con­fronting what your real con­ver­sion rates and churn actu­al­ly are.

Above $5M–$10M ARR, the mod­el becomes a fore­cast­ing and deci­sion-sup­port tool that jus­ti­fies invest­ment in some­one who does this pro­fes­sion­al­ly — a frac­tion­al or full-time CFO. The tell that you’ve out­grown the founder-built mod­el is when you’re using it to answer “if we grow sales 400%, how many more lead-gen peo­ple and sales reps do we need, and what does mar­ket­ing spend become?” That’s not a one-tab ques­tion; that’s an oper­at­ing mod­el feed­ing a finan­cial mod­el, with activ­i­ty ratios and ramp curves under­neath. A good CFO builds mod­els to do deci­sion sup­port, not just to record his­to­ry — and at that scale, the cost of a wrong cap­i­tal-allo­ca­tion deci­sion dwarfs the cost of the CFO.

What’s avail­able to you below that thresh­old, if a full CFO isn’t jus­ti­fied yet: a frac­tion­al CFO for the peri­od­ic heavy lifts (the raise, the dili­gence prep, the annu­al plan), and a dis­ci­plined founder-built mod­el for every­thing in between. You don’t need a $250K hire to have a mod­el that sur­vives dili­gence. You need dri­ver-based log­ic, three con­nect­ed state­ments, and the dis­ci­pline to trace every num­ber to some­thing real.

Where the Model Sits in the Bigger Picture

A SaaS finan­cial mod­el isn’t a stand­alone arti­fact — it’s the quan­ti­ta­tive spine of how you run the busi­ness and how you’ll even­tu­al­ly sell it. The same mod­el that fore­casts next year’s P&L is the one a buy­er under­writes in dili­gence, the one a lender uses to set covenants, and the one your board reviews quar­ter­ly against actu­als. Build it once, build it right, and it serves all of those.

The thread run­ning through every­thing here is the same: a mod­el is only as good as its abil­i­ty to con­nect finan­cial out­puts back to oper­a­tional real­i­ty. The dri­vers have to be real. The state­ments have to tie. The met­rics have to seg­ment. Get those three things right and you have a mod­el that does what a mod­el is sup­posed to do — let you, and any­one eval­u­at­ing you, see exact­ly how the busi­ness works and where it’s head­ed.

If you want to go deep­er on the inputs that feed the mod­el, the most lever­aged places to start are your SaaS unit eco­nom­ics, your net rev­enue reten­tion, and the Rule of 40 — those three dri­ve most of the fore­cast and most of the val­u­a­tion. And when the mod­el’s pur­pose is an exit, it’s worth under­stand­ing the SaaS val­u­a­tion mul­ti­ples the mod­el ulti­mate­ly has to sup­port.

Frequently Asked Questions

What is a SaaS finan­cial mod­el?

A SaaS finan­cial mod­el is a spread­sheet that fore­casts a sub­scrip­tion busi­ness by trans­lat­ing oper­a­tional dri­vers — new cus­tomers, con­tract val­ue, churn, expan­sion, head­count — into three inte­grat­ed finan­cial state­ments (P&L, bal­ance sheet, cash flow) plus the SaaS met­rics buy­ers care about. The defin­ing fea­ture is that rev­enue is derived from dri­vers, not typed in.

How many years should a SaaS finan­cial mod­el fore­cast?

The stan­dard ask is a 24-month fore­cast at month­ly gran­u­lar­i­ty for the near term, rolling up to quar­ter­ly and annu­al subto­tals, with a longer 3–5 year view at low­er res­o­lu­tion for strate­gic and exit plan­ning. Month­ly detail mat­ters most for the first 12–24 months because that’s the win­dow where cash and run­way deci­sions get made.

What’s the dif­fer­ence between a finan­cial mod­el and an oper­at­ing mod­el?

The finan­cial mod­el pro­duces the num­bers — rev­enue, EBITDA, cash. The oper­at­ing mod­el pro­duces the activ­i­ty under­neath them — units of work, con­ver­sion rates, head­count, ramp times. The finan­cial mod­el is the out­put; the oper­at­ing mod­el is the engine. A cred­i­ble fore­cast builds the oper­at­ing mod­el first and lets it feed the finan­cial state­ments.

Why does my SaaS mod­el need a bal­ance sheet?

Because for a sub­scrip­tion busi­ness, the bal­ance sheet is where deferred rev­enue and work­ing cap­i­tal live. An annu­al-pre­pay SaaS com­pa­ny can gen­er­ate cash from deferred rev­enue even while unprof­itable on the P< a month­ly-billing com­pa­ny grow­ing at the same rate can be cash-starved. With­out a bal­ance sheet and cash flow state­ment, your cash fore­cast is fic­tion.

What met­rics should a SaaS finan­cial mod­el out­put?

At min­i­mum: ARR and growth rate, NRR, gross rev­enue churn, CAC pay­back peri­od, LTV/CAC ratio, Rule of 40, burn mul­ti­ple, and run­way — ide­al­ly seg­ment­ed by ver­ti­cal, con­tract size, and chan­nel rather than shown only as blend­ed com­pa­ny-wide aver­ages.

How do I know if my finan­cial mod­el will sur­vive dili­gence?

Click any rev­enue cell. If it’s a for­mu­la trac­ing back through the MRR bridge to oper­a­tional dri­vers you can defend with his­tor­i­cal data, you’re in good shape. If it’s a hard-cod­ed num­ber, or an assump­tion with no oper­a­tional basis, or there’s no bal­ance sheet, a buy­er’s ana­lyst will find it with­in an hour — and that’s the moment trust in the whole mod­el breaks.