The technology behind the SaaS numbers

The model in the deal file shows recurring revenue, a gross margin that looks like software, and retention that holds up. The quality of earnings work confirms the history: the revenue was booked, the costs were paid, the margin is what the seller says it was. What the history cannot show is whether the next three years will look the same.

That depends on things that sit outside the financial statements. A hosting bill carried by credits that end in the spring. A database that needs a larger tier at the next few customers. Three enterprise accounts that each run on their own server with their own code. An operations team that quietly does by hand what the product page says the software does. Most are normal in a growing company, and each one changes the numbers a buyer is paying a multiple for.

This article is for buyers, their financial diligence teams and sellers. It sets out what a technical reviewer checks behind the SaaS numbers and which evidence answers each question.

What the model assumes, and who checks it

A software multiple rests on a few assumptions about the future. Delivery cost per customer stays flat or falls as the company grows. Revenue repeats without much effort to keep it. The product serves the next customer the way it serves the last one, without a new project each time. Our engineering partner PERETZ explains why software is priced on these assumptions in Why Tech Companies Get Valued on Different Math Than Everyone Else. Here we look at the other half: whether the technology supports them.

The work splits cleanly. Accountants test whether the reported numbers are right and how costs are classified. A technical reviewer tests whether the system that produces those numbers will keep producing them at the size and under the ownership the buyer plans. We do not value companies and we do not give accounting opinions. We give the financial team and the buyer facts, with evidence, that they can carry into their own work. The table below shows how the two meet.

Most of this sits in Layer 02, Infrastructure & cost. Reliability touches Layer 04 and Layer 05, manual work touches Layer 06. The six layers are explained in our guide to technical due diligence for buyers.

What sits in cost of revenue

Cost of revenue in a SaaS company usually holds hosting, third-party services the product calls, support, and the part of engineering and operations time spent keeping production running. How each line is classified is a decision for the accountants. The reviewer's job is to make sure they see every line.

The starting point is a map: every paid service, what it does, which environment uses it, and who pays. Cloud hosting and the database are the obvious lines. The less obvious ones add up: email and text message delivery, maps, search, file storage and transfer, error tracking and logging, payment processing, identity providers, video, translation, and any API priced per call. In a product with AI features the model provider belongs on the same map; we cover inference cost separately in AI diligence: is it a product or a wrapper?

Costs that sit somewhere else

A common finding is a production cost that never reaches cost of revenue. Production runs partly in an account booked as research and development. A service is paid on a founder's personal card and expensed, or not expensed at all. A parent company or a sister business shares one cloud account and splits the bill by agreement rather than by use. A contractor hosts a component on infrastructure they pay for and invoice as development. Each of these is a fact for the financial team, and some are also ownership findings in Layer 01.

Credits, discounts and commitments

The current bill is not always the real bill. Startup credits from cloud providers can cover a large part of the cost for a year or more and then stop. Discounts negotiated through a reseller or a partner program may not survive a change of owner. Savings plans and reserved capacity lower the hourly price in exchange for a commitment, which is sensible, but the buyer needs to know the term, the amount and whether it fits the plan after closing. Committed spend agreements with a minimum annual amount can outlive the deal and bind the buyer to a provider it planned to leave.

For each one we record the amount, the end date and what the bill looks like without it. Credits that cover most of the bill and end soon after closing are often rated High on the severity scale, because the margin in the model is temporary.

Costs that grow faster than customers

Some costs are priced on volume that grows faster than revenue. Logging and monitoring priced by data ingested. Storage that is never deleted, so every customer adds cost for as long as the company exists. Data transfer between regions or out to the internet. Per-seat tools billed for every internal user. Text messages and emails sent per user action. Together they can push the margin down while the customer count goes up.

Cost per customer as the company grows

A software margin depends on the cost of serving one more customer staying low. A rule of thumb many deal teams use: hosting and third-party run costs should be a small and stable share of revenue, and if that share rises as the company grows, someone should be able to explain why. The reviewer's job is to explain why.

We build cost per customer from what the system records, not from an average of the bill. Where resources carry cost allocation tags, the work is direct. Where they do not, we estimate from usage: requests, storage, compute time and data volume per tenant. The result separates three kinds of cost.

• Fixed: the platform that runs whether there are ten customers or a thousand. This is where scale helps.
• Variable: cost that follows usage. Fine when pricing follows usage too, a problem when a flat subscription hides heavy users.
• Step costs: a larger database tier, a second region for a customer who requires it, a dedicated cluster, a support shift added at night. Flat for a while, then a jump.

The spread matters more than the average. A handful of customers often generate most of the load, and if they pay the same as everyone else, the margin of the whole base rests on them staying light.

The output is a cost curve with its assumptions written down: the bill today, the bill after the usual fixes such as oversized servers and forgotten environments, and the bill at the size the buyer's plan assumes. Where the system will not reach that size without work, for example a database that only scales by buying a bigger machine, the work is estimated in engineer weeks and costed like any other finding. Some of it is ordinary technical debt, and it should be read that way: a cost with a date, not a verdict.

Reliability as an early churn signal

Retention figures look backward; reliability hints at what comes next. Customers rarely leave after one outage, but repeated incidents, slow pages and failed exports wear down the people who renew the contract. The reviewer reads the evidence a buyer cannot see in a retention cohort.

• The incident history for at least a year: what failed, how long, how many customers were affected, how it was found.
• Postmortems, and whether their action items were done.
• Uptime and response commitments in customer contracts, compared with what the monitoring shows.
• Service credits paid or owed, and whether they are netted against revenue.
• Support tickets about speed, errors and lost data, as a share of all tickets and over time.
• Churn reasons where the company records them, and whether lost customers had incidents in their last months.
• Whether backups have been restored and how long recovery took.

We do not predict churn. We tell the buyer whether the system has been stable, whether the company knows when it is not, and whether the customers who matter most have been hit. A large customer who sat through several incidents in a renewal year is a fact the deal team will want before closing, not after.

Software that behaves like a service

Recurring revenue earns a software multiple when every customer runs on the same product. Some companies that report subscription revenue are partly something else: each large customer has its own deployment, its own version, sometimes its own branch of the code. Revenue repeats, but every upgrade is a project and every new enterprise customer adds a system to maintain.

The signals are in the repository and the infrastructure, not in the pitch deck:

• Separate servers, databases or cloud accounts per customer.
• Several versions of the product in production at the same time, some far behind.
• Branches or forks named after customers, and features merged for one customer only.
• Configuration flags and conditions in the code that test for a specific customer.
• Installations on the customer's own servers that the company cannot update itself.
• Engineers whose time goes mostly to one or two accounts.

None of this is wrong in itself. Single-tenant deployments are sometimes what a regulated customer requires, and they can be run well with automation. The question is whether the cost of serving those customers behaves like software or like a services contract, and whether that cost sits in cost of revenue or in engineering. We report the deployment map, the effort each custom setup takes to keep current, and the cost of bringing them onto one version where the buyer's plan needs that.

People doing what the software claims to do

The product page says onboarding is automatic, data syncs in real time and reports are generated for every customer. Inside, an operations team imports files by hand, an engineer runs a script every Monday to fix records the sync gets wrong, and the reports are assembled by a contractor overseas. The margin looks like software because those people are paid from a line that is not cost of revenue, or because there are few enough customers that the work still fits in someone's week.

This gap is common and rarely hidden on purpose. Founders automate what hurts most and handle the rest by hand. The buyer needs to know which is which, because manual work grows with customers and automation does not.

Where the evidence is

• Direct writes to the production database by people, from audit logs or database logs.
• A folder of scripts run by hand, and who runs them how often.
• Admin panel activity by internal users, especially edits to customer data.
• Support ticket categories that describe tasks rather than problems: "import", "fix", "rerun", "regenerate".
• Contractor invoices and time records, matched to what the contractors actually do.
• Interviews with support and operations staff.

The finding states what the work is, how many hours it takes now, how that grows with customers, where its cost is booked, and what automating it would take. Whether that changes the margin in the model is for the financial team and the buyer.

What changes after closing

The numbers in the data room describe the company as it runs today, under its current owner. Several costs change the day it is owned by someone else, and they belong in the buyer's run-rate before the price is set.

• Accounts move. Moving cloud accounts into the buyer's organization can end startup credit programs and partner discounts tied to the seller.
• Contracts reprice. Vendor agreements with change-of-control or assignment clauses can be renegotiated at list price.
• Enterprise security. A buyer selling to larger customers will be asked for single sign-on, audit logs, a SOC 2 report, penetration tests and data residency. Each has a build cost and a running cost.
• The buyer's own standards. Endpoint protection, central logging with long retention, backup policies and access reviews add tools, storage and time.
• Coverage. A product supported by one person on call, or by the founder at night, needs a real rotation once that person steps back.
• Shared services. In a carve-out, everything the parent provided has to be replaced or covered by a transition agreement.

We list each change with an estimated cost range and its assumptions in the report, so the financial team can put it into the pro forma rather than discover it in the first budget. For owner-operated targets, see our technical checks before buying a software company.

A checklist, and what to do next

Use this list to scope the technical side of a SaaS deal, or as a seller to see what a buyer's reviewer will ask. Each item needs evidence, not a statement, and access granted under a read-only, time-limited protocol.

• A map of every paid service to its purpose, environment and payer, matched to twelve months of invoices.
• Production costs booked outside cost of revenue or paid outside the company.
• Credits, discounts and commitments: amount, end date, and the bill without them.
• Costs priced on volume that grows faster than customers.
• Cost per customer split into fixed, variable and step costs, with the heaviest accounts identified.
• The bill at the size the buyer's plan assumes, and the work needed to reach it.
• Incident history, postmortems, uptime against contracts and service credits.
• Reliability problems among the largest customers in their renewal period.
• A deployment map: shared, single-tenant, custom version or customer-hosted.
• Manual work behind product features, its hours, its growth and where it is booked.
• Costs that start after closing: account moves, repriced contracts, security, coverage.

This is careful work. It needs invoices, consoles, logs and interviews read together, and it is not done in an afternoon. Buyers inside exclusivity get it as part of technical due diligence, with every finding rated and costed. Earlier in a deal, a red-flag memo tells you whether the margin rests on something temporary. Sellers who want the questions answered before a buyer asks them can commission vendor due diligence, or start a year or more ahead with exit readiness.

Questions