Most SaaS teams moving to usage-based pricing start with what's easiest to measure — API calls, tokens, compute. None of those are what the customer came for. They bought work done, time saved, a problem handled. Meter the first thing and every renewal turns into an argument about your infrastructure bill.

Chargebee's Pricing Labs playbook, built with James D. Wilton of Monevate, covers the part most teams skip:

Worth reading before you touch your pricing page, not after.

Consulting | Shop | Website | Newsletter | Speaking

Hey {{first_name}} 👋, I hope you’re having a great week! In the last issue, we discussed about Venture Debt, and now we are moving with the next topic from Reporting content.

Let’s talk about ⬇️

Company at $9M ARR. Three spreadsheets they called a financial model.

Revenue model. Headcount and opex plan. Cash forecast. Different owners, different update cadences, no connection between any of them.

The founder believed they had 14 months of runway. Was about to make a senior hire that would add roughly $35K a month to burn.

We built the integrated version. Two things surfaced immediately.

The revenue model projected $6.2M in new ARR for the year. The headcount model had AE capacity for about $4.1M at quota. The revenue line was assuming productivity that the hiring plan couldn't physically deliver.

And the cash forecast was running a 30-day collection assumption. Actual DSO over the prior six months averaged 47 days.

Both corrections together: 14 months of runway became 10.

The senior hire got pushed six months. The founder pulled their fundraise forward by a quarter, started conversations earlier, and closed a Series A they would otherwise have been raising under real pressure.

Neither spreadsheet was wrong on its own. The problem only existed in the space between them.

A three-statement model connects your P&L, balance sheet, and cash flow statement into one structure. Change an assumption anywhere and every output updates. Gross margin, deferred revenue, AR, net burn, ending cash.

The value isn't the outputs. It's that the model propagates trade-offs correctly.

Without integration you can produce a P&L showing breakeven in 14 months while your cash model shows you're out of money in 9. Both look right in isolation. The problem surfaces only when someone asks a connected question.

You cannot answer that from three files.

Here's how each statement earns its place:

Income statement is the engine. Where growth assumptions live.
Balance sheet is the ledger. What you own, owe, and have left.
Cash flow statement is the truth. What actually moved.

Most SaaS companies at Series A through C have the first one. Fewer have a linked balance sheet. Almost none have a cash flow statement that reconciles automatically.

That gap is where runway surprises come from.

The slide: monthly revenue forecast, twelve months out, clean line going up and to the right.

What was underneath it: =C14*1.075

A 7.5% month-over-month growth rate. Locked in eighteen months earlier by someone who had since left the company.

Nobody knew where it came from. Nobody owned it. And because it was a rate rather than a driver, when growth slowed there was no assumption anyone could go update. The model couldn't tell you what changed, only that the actuals no longer matched.

The fix: replace the rate with a build. New logo count times ACV, plus expansion rate times prior ARR, minus churn rate times prior ARR. Three inputs, three named owners, one number you can actually interrogate.

This is the entire mechanical core. Get these right and the model balances itself.

Hard-code those five connections correctly and the balance sheet balances automatically. Cash reconciles period over period with no manual patching.

If it doesn't balance, you have a linkage error. Don't plug it.

SaaS has a linkage most business models don't. Cash arrives before revenue does, and each statement tells a different part of that story.

When you invoice an annual contract:
Cash increases. Deferred revenue increases. Income statement doesn't move at all.

Each month as you recognize:
Deferred revenue decreases. Revenue increases. No cash moves.

Which means your cash flow statement and your income statement can tell completely different stories in the same quarter. Especially if you're signing large annual or multi-year deals.

One implication founders consistently miss: when deferred revenue increases, that's a source of cash. When it decreases, that's a use of cash, even while you're reporting positive recognized revenue.

So a company shrinking its annual contract volume while maintaining revenue recognition through backlog drawdown will see cash deteriorate before the P&L shows anything.

Without a model handling this loop explicitly, your runway estimate and your revenue forecast will routinely disagree, and you won't know which one to believe.

Most models at $5 to $20M ARR get revenue and cost assumptions roughly right. Then they skip working capital entirely.

That's why runway estimates are consistently wrong. The model is tracking P&L timing when the question is about cash timing.

Three assumptions close the gap:

DSO. Average days between invoice and cash receipt. Use your actual trailing six months, not your payment terms. Those are different numbers and the difference cost the company at the top of this email four months of runway.

Billing mix. What percentage of new ARR is billed annually upfront versus monthly. This drives the entire deferred revenue schedule.

DPO. Payment terms with your vendors. Less dramatic, still real.

Add those three and your cash forecast stops being a P&L in disguise.

The right complexity depends on your stage. A twelve-tab model with cohort waterfalls and a sensitivity matrix is worse than a clean five-tab model if the linkages are broken.

Series A ($3 to $10M ARR). Monthly P&L with driver-based revenue, three to five segments max. Five-account balance sheet. Indirect cash flow that ties automatically. One base case, one downside. Skip cohort waterfalls and segment P&Ls. You don't have the data to calibrate them yet.

Series B ($10 to $30M ARR). Add cohort-level churn and expansion. Department-level cost structure. NRR by segment. Three scenarios. And fix the things you deferred at Series A: replace any remaining growth-rate assumptions, add DSO, reconcile to bank statements monthly.

Series C ($30 to $50M ARR). The model becomes a capital allocation tool. Add a rolling 13-week cash flow for near-term liquidity. Headcount ROI by team. Segment-level P&L with allocated COGS. Sensitivity tables on churn, ACV, expansion. Integration with actuals from your accounting system.

At every stage, one rule holds. Separate the assumptions layer from the calculation layer. Every input lives in one tab. Every formula references it. Anyone should be able to trace any number to its source in under two minutes.

A model without scenario analysis is a reporting artifact. With it, the model becomes a decision tool.

Build the conservative case first. Boards want to know the floor. Not because they expect it, but because knowing the floor is what lets you invest confidently in the base case.

If your conservative scenario still leaves 15+ months of runway, you can hire aggressively against your plan. That's the actual use of a downside model.

One structural note: use a scenario toggle in a dropdown, driven by a lookup table. Duplicate tabs drift. By Q3 the base case and the conservative case share almost no structural similarity and comparing them means tracing every number by hand.

Second story, and this one's about a twenty-minute process that didn't happen.

Company at $7M ARR. Annual plan projecting $11.5M by year end.

By month nine, actual ARR was tracking at $8.9M.

The variance was visible from month four. Nobody was running the comparison.

The broken assumption was new logo close rate. Model used 22%, based on late-stage pipeline. Actual was 14%. Pipeline volume was on plan the whole time. Conversion wasn't.

By month nine the company had hired against the planned revenue, so burn was running ahead of plan while revenue ran behind. Year-end forecast got rebuilt at $9.4M, which moved the Series A timing the founder had built everything around.

The process is one column and three questions. What did we project. What happened. Why is there a gap.

If you can't answer the third one, your assumptions need revision, not just your actuals row.

The three-statement model isn't a deliverable for investors. It's operating infrastructure.

Built properly, it answers the questions that actually matter in ten minutes instead of ten days. How much runway in the conservative case. What two AEs in Q2 do to cash. Whether discounting the enterprise deal to close this quarter moves breakeven.

Three properties do more for decision quality than five extra tabs ever will.

Integrated. The five linkages hard-coded, balance sheet balancing itself.
Assumption-driven. Every number traces to a cell someone owns.
Reconciled. Monthly, against actuals, with an explanation for every gap.

The most common thing I find when auditing a model is that it stops at the P&L. No balance sheet capturing deferred revenue properly. No cash flow derived from anything. Runway estimated as bank balance divided by average burn.

That estimate is usually directionally fine and tactically useless. It can't tell you what changes if you accelerate hiring, delay a vendor contract, or close a large annual deal in Q4.

Those are the only questions worth building a model to answer.

Reply "MODEL" and I'll send the three-statement template. Assumptions tab structured for SaaS, the five linkages pre-built, indirect cash flow that derives automatically, scenario toggle instead of duplicate tabs, and the monthly reconciliation sheet.

Made it to the market before it got hot this week, which felt like a genuine achievement.

{{first_name}} You can get free stuff for referring friends & family to my newsletter 👇

50 referrals - Cash Flow Models Bundle 💰

10 referrals - SaaS Financial Model 📊

{{rp_personalized_text}}

Copy & Paste this link: {{rp_refer_url}}