Skip to content

Technology

How to Calculate the Real Cost of a SaaS Subscription

The number on the invoice and the number that determines whether the software was worth buying are usually different.

Published by UseKitl · Last reviewed 7 September 2026

A SaaS business case usually gets reduced to one number: the annual licence fee. That number is real, but it is rarely the number that determines whether the purchase was worth making — implementation, migration and training cost money in year one that a steady-state ROI figure quietly excludes, and time saved only counts as a benefit if it is genuinely redeployed rather than simply absorbed as slack.

The cost has two very different years

Year oneYear two onward
LicenceIncludedIncluded
Implementation / migrationIncluded, one-offNot repeated
TrainingIncluded, one-offOnly for new joiners

Because year one carries costs that never repeat, its return is structurally worse than every following year — and vendors, quite naturally, tend to quote the steady-state figure rather than the year that includes their own implementation fee.

The formula

annual benefit = (hours saved/week × 52 × loaded hourly rate) + annual losses avoided ROI = (benefit − cost) ÷ cost payback months = cost ÷ (benefit ÷ 12)

Worked example: a 10-person team

Ten people each save 3 hours a week (30 hours/week total), valued at a £38 loaded hourly rate, on a £24,000 annual licence with a £15,000 one-off implementation cost.

Year oneYear two onward
Annual benefit£59,280 (30 × 52 × £38)£59,280
Annual cost£39,000 (£24,000 + £15,000)£24,000
ROI52%147%
Payback≈8 months—

The 147% figure is the one a vendor is likely to lead with. It's not wrong — it genuinely describes year two onward — but approving the purchase on that number alone means judging the case on a year that hasn't happened yet, while ignoring the £15,000 that has to be spent first.

What "loaded hourly rate" actually means

Base salary understates the cost of an employee's time, because it excludes employer taxes, pension contributions, benefits and overhead. A commonly used approximation is 1.25× to 1.4× base salary. Using bare salary in a SaaS business case systematically understates the benefit of time saved and makes the case look weaker than it is — but it's an easy mistake to make in the other direction too, by inflating the multiplier to make a marginal case look better. Use a consistent, defensible multiplier and state it.

Stress-testing the benefit assumption

"Hours saved per week" is almost always the softest number in the whole model — it's usually an estimate, not a measurement, made by the same people who want the purchase approved. The useful test is to halve it and recompute. In the example above, halving hours saved to 15/week halves the annual benefit to £29,640 — still comfortably above the £24,000 recurring cost, so the case survives, though year-one payback stretches from 8 months to roughly 16. A case that only works at the optimistic estimate is a weak case; a case that survives being halved is a robust one.

What a simple SaaS ROI figure usually misses

  • Adoption ramp — the model assumes benefit starts immediately and in full. Real rollouts take months to reach full usage, which pushes actual payback later than the headline figure suggests.
  • Integration and maintenance cost that continues after implementation is technically "done".
  • The cost of migrating away later, if the tool needs replacing — switching cost is real and almost never modelled.
  • Discounting — a nominal ROI/payback calculation, including this one, does not apply a cost of capital to future benefit.

Limitations

  • Time savings are the most commonly over-estimated input in a software business case — measure them where you can, rather than relying on a stated estimate.
  • This is a nominal model with no discount rate or cost of capital applied.
  • It does not model vendor risk, lock-in, or the consequences of the tool being withdrawn or acquired.

Found an error or something outdated in this guide? Report a correction.