What does calculating LTV SaaS correctly actually require?
Calculating LTV SaaS the way most spreadsheets do it — average revenue per account divided by average monthly churn — gives you a number that looks precise and is almost always wrong for a business under three years old. The two structural problems repeat in every version of that formula: it uses revenue instead of what the account actually contributes after cost, and it extrapolates a churn rate measured on immature cohorts out to a horizon nobody has actually observed. Fix both and the number that comes out the other end is smaller, later to arrive, and closer to what the account is actually worth to run the business.
This is a calculation problem for operators running a subscription SaaS product at $3M–$30M in annual revenue, typically 18 to 48 months past their first paying cohort — old enough to have real retention data, young enough that most of the customer base is still inside its first year. If you’re pre-revenue or under the $3M floor, the honest answer is that you don’t have enough cohort history yet to calculate LTV with any confidence; project churn from early users’ behaviour as a working hypothesis rather than publish an LTV number that will be wrong by the time anyone reads it.
Why contribution margin replaces revenue in the calculating LTV SaaS formula
Revenue-based LTV counts money that never reaches the business. Contribution margin is revenue minus the costs that scale directly with each account: payment processing fees, hosting or compute allocated per account, third-party API costs the product depends on, and the support or success time spent per seat. Multiply average revenue per account by average lifespan and the result is a top-line number that ignores all of that; multiply contribution margin by the same lifespan and the result is the number that actually funds acquisition spend.
Three line items get left out most often. Payment processing — typically the card network’s rate plus the payment processor’s own cut — reduces revenue before it becomes margin on every charge, not just the failed ones. Support cost per seat is real even for self-serve products: a ticket, a screen-share, an onboarding call all cost staff time that should be allocated back to the account that generated it. Infrastructure cost that scales with usage (API calls, storage, compute) belongs in the same bucket even when it’s billed to the company as a whole rather than itemised per customer — allocate it by active account count or a usage proxy, and note which method was used.
A revenue-only LTV inflates the number every acquisition channel gets measured against. Paid search, an affiliate programme or a retention email flow that looks profitable against gross revenue LTV can be underwater once contribution margin replaces it, because the margin on the accounts that channel brings in might be thinner than the accounts a partnership or referral programme recruits. The formula can’t tell the difference between a channel that recruits low-margin, discounted annual accounts and one that recruits full-price monthly accounts unless margin is built into the base number from the start.
What cohort window can you actually observe?
The cohort window is the number of consecutive months since a customer’s first payment for which real, closed data exists — not projected, and not this month’s still-accruing figure. If a product launched 20 months ago, the oldest cohort has a 20-month window and every younger cohort has less; the observable window for the whole business is capped by the youngest fully-elapsed month, usually one month behind today’s date because the current month is still accruing cancellations.
Define the window before calculating anything else. A common and defensible choice is to use only cohorts with at least six full months of history, and to report the result as “six-month observed contribution margin per account” rather than as an unqualified lifetime number. That label matters: it tells a finance reviewer exactly how far the number can be trusted and where the guessing starts.
A three-month window is too short to say anything useful about SaaS LTV. Most voluntary cancellation activity in a monthly-billed product concentrates in the first 90 days, so a three-month cohort is still mid-churn and gives almost no signal on what a surviving account is worth. A twelve-month window is far more defensible, but it also means the calculation is always describing last year’s product and pricing, not this year’s — a real constraint worth stating out loud rather than letting a stakeholder assume the number is current.
Build the observation as a simple cohort table: rows are signup month, columns are months since signup, and each cell holds either the surviving contribution margin for that cohort-month or a blank if that cell hasn’t happened yet. The diagonal of blank cells is the boundary of what’s observable; anything past it is a forecast, and forecasts belong in a separate, clearly marked column, never blended into the same number as the observed cells.
Why does average churn overstate LTV for a young SaaS business?
A single average monthly churn rate assumes every account has the same constant probability of cancelling every month — the assumption behind the textbook LTV = margin ÷ churn formula. Real subscription cohorts don’t behave that way: churn is highest in the first one to three months, drops through months four to twelve as the remaining accounts self-select for fit, and flattens further after that. Average the whole thing into one number and the result is too high for the long-run survivors and too low for the accounts that were always going to leave early. For a young company, the blend is dominated by early-life cohorts, so the average sits closer to the high early-churn rate than to the flatter rate mature accounts eventually show.
Run the formula LTV = margin ÷ churn and the calculation implicitly assumes an exponential decay curve: a constant percentage of the remaining base cancels every month, forever. Actual retention curves for subscription products are closer to an S-curve that steepens early and flattens late, so a formula built for exponential decay overstates the area under a flattening curve once it’s projected past the months actually measured. The younger the business, the fewer flattened, mature cohorts exist to correct the average, so the overstatement is worst exactly when a founder is most tempted to lean on the number to justify a funding round or an ad budget.
The fix isn’t a better formula, it’s a shorter, honest one: report observed contribution margin over a defensible cohort window, and if a projection is unavoidable, apply the churn rate of the oldest, most mature cohort segment to it — never the blended average across all cohorts — and label the projected months as an assumption, kept separate from the observed ones.
How to calculate LTV for SaaS, step by step
- Define the account unit — logo, seat or location — and hold it constant across the whole calculation, because switching between per-logo and per-seat halfway through inflates or deflates the number without anyone noticing.
- Pull contribution margin per account per month — revenue minus payment processing, allocated infrastructure and allocated support cost — for a specific historical month, not a blended annual average.
- Build a cohort table: one row per signup month, one column per elapsed month.
- Pick the observation window (six or twelve full months) and sum the surviving contribution margin across that window per account.
- Report that sum as the observed LTV for that window, labelled explicitly by window length.
- Only if the business needs a longer-horizon estimate for a board deck or a CAC payback model, apply the oldest cohort’s own flattening churn rate to extend the projection, in a separate labelled column.
Here’s an illustrative walk-through, not a benchmark: a cohort of 200 new accounts signs up in month zero. Average revenue per account is $150 a month; after payment processing, allocated hosting and allocated support cost, contribution margin per account is $95 a month, or roughly 63% of revenue. By month six, real cohort data shows 140 of the original 200 accounts still active — a 70% six-month survival rate. Summing surviving contribution margin across the six observed months, allowing for accounts leaving mid-window rather than all at once, works out to roughly $79,800 of margin from that cohort, or about $399 per original account across six months. That $399 is the number a finance review can defend; anything claiming more assumes retention behaviour past month six that hasn’t actually been measured.
What breaks in the calculation once you scale past one plan?
A single blended LTV number stops meaning much once a product has more than one pricing tier. A cohort that mixes a $49 entry plan with a $299 enterprise seat produces an average that describes neither buyer. Split the cohort table by plan tier at signup, because tiers usually carry different margin profiles and different churn curves — enterprise accounts typically churn slower but cost more in support time, which changes the margin side of the equation too.
Expansion revenue — upsells, seat additions, usage overages after signup — breaks the simple cohort-margin-times-months model unless it’s tracked explicitly. An account that started on a $49 plan and expanded to $199 by month eight is contributing more margin in month eight than the cohort average assumes; without tracking expansion by month, the window-based number understates mature, expanding accounts and overstates accounts that only ever contract.
Mid-cohort price changes are the one teams miss most. If prices rose in month five and a cohort spans months zero through twelve, the accounts that renewed after the change are contributing a different margin than the ones still on the old price. Either split the cohort at the price-change boundary or note which months used which price — blending them silently produces a number that doesn’t correspond to any price actually charged.
What edge cases change how you calculate LTV for SaaS?
Annual contracts hide churn inside the renewal boundary. A customer who signs a 12-month contract in January shows zero monthly churn signal until the January renewal a year later — the cohort looks perfectly retained for eleven months and then either renews or doesn’t in one visible event. Calculate LTV for an annual-contract business at the contract-term level, not the monthly level: cohort table columns should be renewal cycles, not calendar months, or a flat pre-renewal line reads as health rather than as an absence of data.
Usage-based pricing means average revenue per account tells you almost nothing, because the distribution is usually skewed — a small number of accounts drive most of the usage and most of the margin. Calculate contribution margin LTV in usage-based cohorts by percentile band, say top 10%, middle 80% and bottom 10% of usage, rather than as one blended average; a single number here hides the fact that losing one heavy-usage account can outweigh retaining twenty light ones.
Free trials and freemium tiers shift when “month zero” actually starts. Counting the trial start date as month zero pulls early-cohort churn toward people who never intended to pay; counting the first paid invoice as month zero loses visibility into trial-to-paid conversion, which deserves tracking as its own metric rather than folding into the LTV cohort. Set paid-invoice date as month zero for the LTV calculation specifically, and track trial conversion separately upstream of it.
Failed and retried payments quietly shrink the observed margin inside a cohort that otherwise looks stable. Baremetrics has reported that roughly 9% of monthly recurring revenue is lost to failed payments industry-wide (vendor-reported) — revenue that shows up as active in a subscription platform right up until the card genuinely fails to recover, meaning a cohort’s true survival curve is often a little worse than what billing software shows on the surface. A reporting setup that doesn’t reconcile failed-then-recovered charges against the cohort will overstate the observed margin, not just the projected margin.
What do reporting tools like Triple Whale and Northbeam actually calculate for you?
Ecommerce attribution and reporting platforms, including Triple Whale and Northbeam, publish LTV and cohort-revenue reporting as a built-in feature (vendor-reported), and it’s worth being precise about what that feature does and doesn’t give a SaaS operator trying to calculate LTV correctly.
| Reporting layer | What’s reported (vendor-reported) | What still needs independent calculation |
|---|---|---|
| Triple Whale | Revenue-based cohort curves and blended LTV, marketed as a built-in metric | Contribution margin inputs — payment processing, hosting allocation, support cost — aren’t in an ad-attribution data model and have to be joined in separately |
| Northbeam | Attribution-weighted LTV and cohort revenue tied back to ad spend | Same margin gap, plus its LTV windows are typically set for attribution decisioning rather than the accounting-grade window a finance review needs |
| A cohort spreadsheet or warehouse table built in-house | Nothing vendor-reported — every number is one the team defined | Fully within your control, and only as reliable as the churn and margin definitions your team agreed on and kept consistent |
The pattern across both platforms is the same: they’ll hand you a churn or revenue curve fast, but the contribution-margin correction that makes an LTV number decision-grade is still a step your own reporting has to do, because neither tool holds your cost-of-goods or support-cost data by default. Current plan names, feature scope and pricing tiers on both platforms change often enough that this page won’t reproduce them — check each vendor’s own pricing page for the tier and included order volume that applies before committing budget to either as an LTV reporting layer.
Where does the LTV calculation actually break on a Tuesday?
The failure looks like this: a growth lead asks finance for “the LTV number” ahead of a Monday board meeting, someone pulls last quarter’s spreadsheet, updates the top-line revenue and churn cells, and emails back a number by Tuesday morning without checking whether the churn cell still refers to a blended average or whether new cohorts have shifted the mix. Nobody re-derives the contribution margin, because the margin inputs live in a different system than the subscription platform’s dashboard, and reconciling them takes longer than the deadline allows. The number that goes into the deck is technically real but describes a business that no longer matches the one being run.
The second common break is a dashboard silently swapping its churn input from logo churn to revenue churn, or the reverse, after a tool update or a new analyst inherits the sheet, without anyone renaming the column. Logo churn counts cancelled accounts; revenue churn counts cancelled dollars, weighted toward the highest-paying accounts. An LTV formula built on logo churn and then fed a revenue-churn percentage from a different report produces a number with no defensible meaning, and it rarely gets caught because both are expressed as a similar-looking percentage.
Who shouldn’t rely on this LTV calculation?
This calculation assumes a subscription product with at least six months of real cohort history and a finance function that can separate contribution margin from gross revenue. A pre-revenue product, a business under the $3M floor this article is written for, or a team billing project or usage fees with no recurring cohort structure at all shouldn’t force its numbers into a cohort-window LTV model — the inputs don’t exist yet, and a precise-looking number built on six weeks of data is worse than no number, because it invites decisions the data can’t support.
Getting this number right is a reporting and analytics problem before it’s a finance problem: the contribution margin inputs, the cohort table and the window labelling all need to live in one consistent reporting setup instead of a spreadsheet rebuilt from memory each quarter. That’s the gap Pointerflow’s reporting and analytics service works on — keeping the margin inputs and the cohort window consistent so the LTV number in a board deck matches what the underlying data actually supports.
Sources
- Baremetrics: approximately 9% of monthly recurring revenue lost to failed payments, reported across its subscription-business customer base (vendor-reported).