SaaS metrics versus engineering reality: when the ARR and the codebase disagree

SaaS metrics and engineering reality disagree in six predictable places, and technical due diligence is the workstream that finds them because it is the only one with the code, the invoices and the model open at the same time. The financial reviewer checks that the ARR adds up. The technical reviewer checks that the software can produce it.

The disagreements are rarely fraud. They are usually definitions stretched in the target's favour, costs left out of a margin, and a roadmap written by someone who did not ask the engineers. Reveneau's review reconciles each metric in the deck against the engineering artefact that supports or contradicts it, and reports the gap as a finding with a cost, because a metric that the system cannot deliver is a repair bill or a price adjustment, and the deal team needs to know which.

This page assumes the reader has the pillar guide and what technical due diligence is in hand. For the cloud bill in detail, see cloud cost due diligence.

What does a SaaS metric claim about the software?

Every SaaS metric makes a claim about the software that can be checked, and the table below pairs each common metric with the engineering artefact that checks it. The definitions come from a16z's 16 Startup Metrics (2015-08-21), which remains the reference most investors use.

Metric in the deck	What it claims about the software	Artefact that checks it
ARR	Revenue that recurs because the platform delivers the service without new work each period	Contract list against the product: which lines are subscriptions the software fulfils, and which are services people deliver
Gross margin	The cost of delivering the service, including hosting and inference, is what the model says	Twelve months of cloud and model provider invoices
Net revenue retention and churn	Customers stay and expand because the product works	The incident log, the support ticket volume, and usage per account over time
Bookings and pipeline	Contracts signed can be delivered by the product as it exists	The list of features promised in contracts against the roadmap and the delivery metrics
Roadmap and product velocity	The team ships at the pace the plan needs	DORA delivery metrics from the pipeline, and the last two quarters of shipped work against what was planned
Customer count and usage	The platform serves the number of tenants claimed at the usage claimed	Production usage data, tenant count in the database, and the cloud bill's per-unit trend

Each row is a reconciliation. Where the deck and the artefact agree, the metric is supported. Where they disagree, the size of the gap is the finding.

How should ARR be checked against the platform?

ARR should be checked by asking which revenue lines the software produces on its own and which need people, because a16z's definition is that ARR "should exclude one-time (non-recurring) fees and professional service fees", and targets stretch it. The same guide separates bookings ("the value of a contract between the company and the customer") from revenue ("recognized when the service is actually provided"), and warns that "letters of intent and verbal agreements are neither revenue nor bookings".

The engineering check is concrete. Take the largest twenty contracts and, for each, ask what the product does for that customer without human work. Implementation fees, custom integration work, managed services and dedicated support are revenue that people deliver, and they come out of ARR. A company whose ARR is a third services is a consultancy with a software product, and the plan to scale it as SaaS assumes engineering work that has not been done: turning the services into product. That work has a cost, and it goes in the report.

Watch also for custom builds. A contract whose value depends on a feature that exists only for that customer, maintained by hand, is recurring for as long as someone maintains it. The codebase shows these as per-customer branches, configuration files with customer names, or a services directory with one module per account. Each is ARR with an engineer attached.

Why does gross margin disagree with the cloud bill?

Gross margin disagrees with the cloud bill when the margin leaves costs out, and the invoices are the only place to find them. a16z's guidance is that "all costs associated with the manufacturing, delivery, and support of a product/service should be included" and that a founder should "be prepared to break down what's included in and excluded from that gross profit figure". The reviewer's job is to do the breakdown from the source.

Rebuild the margin: revenue from the contracts, minus hosting from the cloud invoices, minus model inference from the provider invoices, minus third-party services the product calls per transaction, minus the support and customer-success people whose work delivers the service. Compare the result with the deck. A gap of a few points is a definitional difference to note. A gap of twenty points is a finding.

The AI case is where the gap is largest. Bessemer's The State of AI 2025 (2025-08-13) reported that its fastest-growing AI companies had "only 25% gross margins", and ICONIQ's State of AI 2026 (July 2026, surveys of over 300 executives) put the average at 45 percent in 2025 with projections of 53 percent in 2026 and 59 percent in 2027. Those are surveys across many companies. The target's number is its own, and rebuilding inference gross margin from invoices shows the arithmetic. A deck margin above the survey averages for a company at the same stage is a claim to check line by line.

What does the incident log say about churn?

The incident log says whether the retention figure is a property of the product or a property of the sales team, because customers who suffer outages leave, and the log records the outages. a16z defines gross churn as "MRR lost in a given month/MRR at the beginning of the month" and net churn as the same after upsells, and both are financial measures of something the engineering artefacts explain.

Lay the twelve-month incident log against the twelve-month churn series. A cluster of churn two months after a major outage is a product problem with a date on it. Churn that is flat while incidents rise means either a captive customer base or a lag that has not arrived yet. Then look at usage per account: a customer whose usage has fallen to zero and whose contract has not yet ended is churn the metric has not recorded, and a company with many of these has a retention figure that is a year out of date.

Support ticket volume is the third artefact. Rising tickets per customer with flat headcount means either the product is getting harder to use or the team is falling behind, and both show up in the retention figure eventually. Assessing the engineering team covers what falling behind looks like from the inside.

Can the team deliver the roadmap the plan assumes?

The team can deliver the roadmap when the delivery metrics support the pace the plan needs, and the pipeline is the artefact that shows it. DORA's four keys guide defines change lead time, deployment frequency, failed deployment recovery time and change fail rate as the measures of software delivery performance, and a target that can pull them from its own pipeline gives the reviewer a measured pace.

Take the roadmap in the deck and the last two quarters of shipped work. Ask what was planned two quarters ago and what shipped. The ratio is the team's real velocity, and applying it to the next four quarters of roadmap gives a delivery date the plan can be checked against. A roadmap that assumes three times the demonstrated pace is a hiring plan in disguise, and hiring has a cost, a lead time and a risk that belong in the findings.

Then take the contractual commitments: features promised to customers in writing that are not yet built. These are engineering work with a legal deadline, and they come before anything on the roadmap. A company with a quarter of committed work and a roadmap that starts from zero has a quarter it has not told you about.

How should the disagreement be reported?

Report each disagreement as a finding with the metric, the artefact, the gap and the cost, in the four-field format from the report template. The SEC's Commission Guidance on MD&A (Release 33-10751, effective 2020-02-25) says a public company presenting a metric should give "a clear definition of the metric and how it is calculated", "the reasons why the metric provides useful information to investors", and "how management uses the metric". A private target owes its investors the same three things, and a metric the target cannot define is the finding before any reconciliation starts.

Three outcomes cover most cases. The metric is supported by the artefact: say so, because supported metrics are evidence for the deal. The metric is overstated by a definitional stretch: restate it with the tight definition and give both numbers. The metric depends on engineering work not yet done: cost the work, and hand the deal team a choice between a price adjustment and a funded plan. The point of finding the disagreement early is that each of those is cheaper before signing than after, and a finding with a cost attached is one the deal can act on.