How SaaS due diligence changes the purchase price

Buying a SaaS company on a multiple of recurring revenue assumes that the revenue will recur under new ownership. The repository cannot prove that assumption. Customer history, billing behavior, contracts, third-party rights, production access, and the habits of the people who keep the service alive determine whether the buyer acquired a durable business or an expensive support obligation.

Good SaaS due diligence converts those facts into deal terms. It does not produce a red, amber, and green slide for the investment committee. It reconstructs the claims in the seller's model, identifies costs and failure modes that the model omitted, then attaches each material finding to price, escrow, a closing condition, or a post-close budget. If a technical finding cannot affect one of those decisions, it probably needs sharper analysis.

Churn data must survive reconstruction

The seller's churn chart deserves no trust until the buyer can rebuild it from customer-level events. I have seen polished dashboards mix subscriptions, invoices, credits, pauses, migrations, and manual adjustments in ways that make retention look better without anyone explicitly falsifying a number. The usual cause is a metric that evolved inside a billing tool while the board model evolved in a spreadsheet.

Ask for immutable exports from the billing provider, the application database, and the general ledger. You need account identifiers, subscription identifiers, invoice dates, service periods, amounts, currency, plan, discounts, credits, refunds, payment status, cancellation requests, effective cancellation dates, and reactivation events. A monthly revenue snapshot prepared for diligence is evidence only after it reconciles to those sources.

Define churn before calculating it. Logo churn answers how many customers left. Gross revenue retention measures recurring revenue retained before expansion. Net revenue retention includes expansion and contraction. A buyer should calculate all three because a handful of expanding accounts can conceal a weak customer base. Decide how to treat annual prepayments, delinquent invoices, free months, usage charges, and customers that cancel but retain service through a paid period. Record those rules beside the output.

This compact query is a useful first test when the data warehouse has one row per account and month. Column names will differ, but the output shape should not:

WITH movement AS (
  SELECT
    account_id,
    month,
    recurring_revenue,
    LAG(recurring_revenue) OVER (
      PARTITION BY account_id ORDER BY month
    ) AS prior_revenue
  FROM account_monthly_revenue
), classified AS (
  SELECT
    month,
    account_id,
    prior_revenue,
    recurring_revenue,
    CASE
      WHEN prior_revenue > 0 AND recurring_revenue = 0 THEN prior_revenue
      ELSE 0
    END AS churned_revenue,
    CASE
      WHEN prior_revenue > recurring_revenue AND recurring_revenue > 0
      THEN prior_revenue - recurring_revenue ELSE 0
    END AS contracted_revenue
  FROM movement
)
SELECT
  month,
  SUM(prior_revenue) AS opening_revenue,
  SUM(churned_revenue) AS churned_revenue,
  SUM(contracted_revenue) AS contracted_revenue
FROM classified
GROUP BY month
ORDER BY month;

The result should contain one row per month with opening recurring revenue, fully churned revenue, and contraction. Reconcile opening revenue to the previous month's closing balance and reconcile invoiced totals to the ledger. Then sample at least one churned, one contracted, one expanded, and one reactivated account from each important plan. Read their invoices and event histories. A query can be internally consistent while the source events remain wrong.

Cohorts matter more than the blended line. Group customers by acquisition quarter, plan, contract term, channel, company size, and geography where the sample permits it. A recent cohort with generous discounts can lift current recurring revenue while storing up future churn. A legacy cohort may appear loyal only because it has a discontinued plan that the buyer cannot economically support. Reprice the deal when reconstructed retention materially changes forecast cash flow, not merely because two definitions produce different labels.

Revenue quality hides behind the churn percentage

Churn alone cannot tell you whether recurring revenue is collectible, transferable, or expensive to retain. Two companies with the same net revenue retention can deserve different prices when one depends on prepaid multi-year contracts and the other earns monthly card payments from thousands of independent customers.

Start with concentration and behavior. Measure the share of recurring revenue held by the largest accounts, but also inspect common control. Five customer names may belong to one parent company with a single procurement decision. Several reseller accounts may depend on one channel agreement. Build renewal calendars for the largest contracts and note termination rights, price caps, service credits, most-favored pricing, data-location promises, security addenda, and change-of-control clauses. A revenue model that assumes renewal at a new price is fiction if the contract fixes that price for another two years.

Compare contracted recurring revenue, billed recurring revenue, recognized recurring revenue, and cash collected. They answer different questions. A signed order can include implementation work that should not enter the recurring base. An invoice can remain unpaid. Recognized revenue can include a ratable allocation from an annual prepayment. Cash can arrive before the seller has delivered the service. Put the four views on the same account and month so differences become visible.

Discounts need their own analysis. A permanent 50 percent discount is part of the plan's economics, not a promotion. A first-year discount creates a renewal test that may not yet have occurred. Credits issued after complaints can sit outside the subscription table and inflate gross retention. Examine effective price per unit and support effort by cohort. If the lowest-priced cohort creates the most tickets, its recurring revenue may carry a negative contribution margin after the founder stops answering support personally.

Deferred revenue often causes confusion in negotiation. It is cash the seller collected for service the buyer must still deliver. The accounting treatment depends on the transaction structure and advice from the deal team, but the operational fact is simple: the buyer inherits work without receiving the original cash. Quantify the remaining service obligation by customer, then make sure the purchase agreement deals with it explicitly.

Validate demand outside the billing system. Compare cancellations with product activity, support conversations, incident history, and customer-success notes. Sudden inactivity before cancellation can reveal a predictable risk window. Heavy activity can still be unhealthy if it comes from failed jobs and repeated retries. Do not turn product usage into a vanity score. Use it to explain why accounts expand, contract, or leave, then test whether that explanation holds across cohorts.

License bombs start with rights, not package names

A dependency inventory is incomplete until the buyer knows what rights the company has to use, modify, host, and transfer every material component. Engineers often treat license review as a scanner task. Scanners help find packages, but they cannot establish who copied a file, whether a contractor assigned the work, or whether the seller complied with a commercial license tied to its current legal entity.

Generate a software bill of materials from every deployable artifact, not only the main repository. Include containers, mobile applications, browser extensions, infrastructure images, internal command-line tools, model files, fonts, images, and code generated by vendors. SPDX defines an SBOM as structured information about software components and their relationships. That relationship data matters: a package present only in a build stage creates a different exposure from a library distributed to every customer.

For each component, capture the resolved version, source, declared license, actual license files, modification status, distribution path, and whether it runs only on the seller's servers. Review copyleft obligations with qualified counsel, especially when software is distributed or linked in ways that may trigger source or notice duties. The engineering team should establish the facts; counsel should interpret the transaction's legal exposure.

Commercial components create a different trap. Read the order form, master terms, and amendments for database engines, UI libraries, observability services, data feeds, maps, fonts, fraud tools, and embedded SDKs. Check entity restrictions, user or core limits, minimum commitments, audit clauses, change-of-control language, and assignment rights. A license that cannot transfer may force a new contract at current pricing on closing day. That cost belongs in the deal model.

Ownership can fail even when every dependency has a permissive license. Match repository contributors to employee and contractor agreements. Look for commits from personal accounts, acquired code, outsourced prototypes, and code imported from a founder's earlier venture. Confirm invention assignment and confidentiality terms for the period when each person contributed. A present-day signature does not automatically cure a historical ownership gap, so let counsel decide what remediation works.

AI-generated code deserves the same provenance discipline. Ask which coding assistants, model providers, and account types the team used; what data they sent; whether prompts included customer information; and how engineers review suggested code. Do not make the fashionable mistake of declaring all assisted code contaminated. The practical risk comes from absent policy, unknown provenance, privacy violations, and copied output that nobody reviewed.

A material rights gap should produce a specific response: replace the component before closing, obtain a transferable license, secure an assignment, create a special indemnity, fund an escrow, or reduce price by the expected replacement cost plus migration risk. "Legal to review" is not a completed technical finding.

Key-person risk can be measured in recovery time

Key-person risk exists when the business cannot perform an important operation without one named person's memory, access, or judgment. An org chart does not reveal it. Measure it by asking a second person to execute real operating tasks while the usual owner stays silent.

Choose tasks that would hurt during the first month after close: deploy a normal release, roll back a bad one, restore a database to a clean environment, rotate a production credential, renew a certificate, reconcile a billing discrepancy, answer a serious support escalation, and explain a large customer's custom configuration. Observe who can finish, which approvals they need, where instructions fail, and how long recovery takes.

The test should use existing documentation and normal access paths. Do not let the founder whisper missing commands or temporarily share a personal password. Record the first blocking point. If the backup engineer can deploy only after the lead engineer approves a device from a personal phone, the company still depends on the lead engineer. If a restore runbook omits the encryption key location, the backup is not operationally useful.

Repository knowledge also concentrates. Use version-control history to map ownership of critical areas, then challenge the apparent coverage. Two people committing to the same service does not prove two people understand its failure modes. Ask each person to explain data ownership, external dependencies, queue behavior, retry rules, and the safest rollback boundary. Compare the answers with production configuration and incident records.

Founder-run support is easy to miss because it looks like excellent customer care. Search support tickets and customer communication for private channels, personal messaging accounts, and promises absent from the contract. A founder may manually repair data, run custom reports, or waive limits for a major account. Those actions reduce visible churn while creating labor the buyer has not budgeted. Put recurring exceptions into the operating forecast.

Retention bonuses can keep a person employed, but they do not transfer knowledge by themselves. Tie transition obligations to observable deliverables: successful restore drills, current system diagrams, access moved to company-controlled accounts, recorded customer exceptions, and independent execution by the successor. If the business still needs the seller six months later to restart a failed queue, the transition plan failed even if every document was delivered.

Quantify the exposure as time and money. Estimate how long the company would operate in a degraded state, the revenue at risk during that period, the contractor or hiring cost, and the work postponed while the team learns the system. Use that amount to set a transition holdback or post-close budget. Calling the risk "high" gives the buyer nothing to negotiate.

Production must work without the seller's accounts

The buyer needs evidence that production can operate under company control on the day ownership changes. A clean architecture diagram means little if cloud billing, domain registration, certificates, source control, app-store accounts, analytics, or backup encryption depend on the seller's personal identity.

Build an access register from the systems themselves. For each production service, record the legal account owner, billing owner, administrators, identity provider, recovery methods, hardware tokens, API credentials, and transfer procedure. Compare it with the employee list and vendor contracts. Shared accounts should trigger remediation, but personal recovery paths deserve equal attention. A company email address that recovers through a founder's private phone is still personal control.

Then follow one release from approved change to production. Confirm that the repository contains the deployed revision, continuous integration uses company-owned credentials, tests run, artifacts have immutable identifiers, approvals are recorded, and rollback has been exercised. Manual deployment is not automatically unacceptable for a small SaaS company. Undocumented manual deployment by one person creates a direct continuity risk.

Backups require a restore result, not a screenshot of a green job. Ask the team to restore production-like data into an isolated environment, verify record counts and application behavior, and report recovery time. Check whether logs, object storage, search indexes, secrets, and customer-uploaded files have separate recovery paths. Many teams back up the primary database and discover during an incident that the product also depends on objects or indexes nobody can reconstruct.

Capacity and cost deserve a paired test. Reconcile infrastructure invoices to customer and workload growth for at least a year. Identify committed spend, credits that expire after closing, per-seat tools, data-egress exposure, idle environments, and services priced under a founder's startup program. A seller may report attractive gross margin while excluding engineering labor used to babysit unreliable jobs. Include that labor when comparing architecture choices.

Read incident records for repeated patterns. One outage followed by a clear fix may carry less risk than ten small incidents dismissed as user error. Compare post-incident actions with later deployments and tickets. If the same queue saturation or certificate lapse returns, management is accepting the risk rather than resolving it. Price the expected work, not the quality of the incident template.

Before closing, transfer or recreate control of domains, cloud organizations, source repositories, package registries, signing keys, email delivery, monitoring, billing, and customer support. Some services cannot transfer between legal entities, so sequence the migration and test it before the seller loses access. The purchase agreement should make completion a closing condition where failure would interrupt revenue.

Security findings matter when they create obligations

A vulnerability list becomes useful in a transaction only when it connects a plausible failure to customer duties, regulatory exposure, remediation cost, or interrupted revenue. Counting scanner findings rewards noise. Start with data, trust boundaries, privileged paths, and promises already made to customers.

Map what personal, financial, authentication, and customer-confidential data the service collects. Record where it enters, where it is stored, who can access it, which vendors receive it, how long it remains, and how deletion works. Compare that map with privacy notices, data-processing agreements, security questionnaires, and enterprise contracts. The dangerous gap is often not an exotic exploit. It is a confident contractual answer that the actual system does not support.

Test a few high-consequence paths manually. Can support staff impersonate customers, and does the system record that action? Can one tenant request another tenant's object by changing an identifier? Do exports include deleted records? Can an old employee still access production? Are secrets present in repositories, build logs, ticket attachments, or shared documents? Follow evidence far enough to determine scope instead of filing a generic recommendation.

OWASP's Application Security Verification Standard separates broad security claims into testable requirements. Use that idea even if the company never pursued formal verification: identify which controls the product needs for its risk level, then preserve the evidence for the controls you actually tested. Do not award maturity points for a policy that nobody follows.

Incident history requires careful language. Ask for security alerts, customer complaints, suspicious login investigations, fraud cases, lost devices, vendor notices, insurance claims, and communications with authorities. Compare those records with logs and ticket systems. Absence of a declared breach does not prove absence of incidents; it may mean the company never had enough logging to decide. State the uncertainty and price the work needed to reduce it.

Customer commitments can turn remediation into a deadline. A contract may require notice within a defined period, annual penetration testing, deletion after termination, a particular hosting region, or prior approval for subprocessors. Build a commitments matrix with the evidence of compliance and the cost of closing each gap. Let privacy and transaction counsel determine disclosure and liability. The technical team should not improvise legal conclusions.

Separate three amounts in the deal model: immediate containment before close, planned remediation after close, and contingent exposure if a past failure produces a claim. A buyer can accept old dependencies with a funded upgrade plan. It should hesitate when the seller cannot identify its data, administrators, or customer promises, because the range of possible cost remains too wide to price cleanly.

Technical debt gets a price only through business impact

Technical debt is not a discount category by itself. Every software company has old code, awkward boundaries, and deferred upgrades. The buyer should adjust price when that condition increases required cash, delays the investment plan, threatens contracted revenue, or blocks a necessary operating change.

Start with the buyer's thesis. If the plan depends on doubling sales without adding support staff, inspect automation, tenancy boundaries, provisioning, billing, and support tooling. If the plan depends on entering regulated accounts, inspect audit logs, access controls, data location, deletion, and evidence collection. If the plan depends on combining products, inspect identity, data models, APIs, and migration paths. The same repository can be acceptable for a cash-yield acquisition and unsuitable for a rapid integration.

Estimate remediation as a range with assumptions. Include engineering time, specialist help, vendor charges, parallel infrastructure, customer migration, testing, support load, and delayed roadmap work. Add uncertainty when nobody can reproduce the build or explain the data model. Avoid false precision. A range of twelve to sixteen engineer-weeks tied to named work is more defensible than a single dollar amount produced by counting code smells.

Distinguish maintenance burden from change risk. A stable old service with tests and predictable operations may deserve little discount. A fashionable stack with weak isolation and no rollback may deserve much more. Buyers often prefer modernization because it sounds clean. A full rewrite is usually the wrong default: it postpones customer work, recreates undocumented behavior, and concentrates risk in one long program. Replace components when the existing design blocks a measured business requirement.

Use defect and delivery history to test estimates. Review cycle time for comparable changes, escaped defects, rollback frequency, support load, and the amount of unplanned work. Do not compare the team with a generic benchmark. Compare its demonstrated capacity with the buyer's operating plan. If the plan needs four major integrations per quarter and the team has never completed one without months of custom work, budget and valuation need to change.

Headcount deserves the same discipline. Do not assume every manual process should receive an AI agent, and do not assume the current team must remain unchanged. Map recurring work, interruption load, ownership, and required judgment. In my Team & AI Audit work, I look for work that can be removed or automated without weakening production ownership, then put the remaining roles against the actual delivery plan. The acquisition model should carry the cost of that future organization, not blindly copy the seller's payroll or an optimistic automation target.

Create one finding for each business consequence. "Monolith" is an observation. "The shared release train adds an estimated six weeks to the contracted enterprise isolation work, delaying the planned launch and requiring two temporary engineers" is a finding that the deal team can price. Architecture vocabulary should never substitute for economic analysis.

Findings should change price or terms

The final diligence report should make negotiation easier by connecting evidence, uncertainty, business effect, remedy, owner, timing, and deal treatment. A long issue register without treatment forces the investment team to repeat the technical work under deadline pressure.

Use a schedule like this for every material item:

Avoid adding every cleanup item to the price reduction. Some costs already sit in the buyer's operating plan, some are ordinary maintenance, and some overlap. Separate base-case work from incremental work caused by an undisclosed condition. State whether estimates include internal labor and whether several findings share the same remedy.

Uncertainty also needs treatment. If the seller cannot produce customer-level history, the answer is not to assume the dashboard is right or to assign a dramatic worst case. Use a conservative forecast, extend diligence, require a representation, hold back consideration, or structure an earnout around collected revenue. Choose the mechanism that matches who can control the outcome. An earnout tied to retention may be unfair if the buyer plans a rapid price increase after closing.

Rank closing conditions sparingly. Transfer of production control, proof of intellectual-property ownership, a necessary third-party consent, and containment of an active security exposure can justify delaying close. A framework upgrade usually belongs in the post-close plan. Too many conditions create a closing process nobody can administer.

The technical lead should review the disclosure schedules and relevant purchase-agreement language with counsel. Make sure defined terms match the systems tested, listed exceptions match known facts, and promised remediation has an acceptance test. Engineers should not draft legal warranties alone, but counsel cannot describe a production dependency that the technical team never surfaced.

Keep a signed baseline of the evidence used for the decision: exports, dependency manifests, access registers, contract inventories, test results, and the final adjustment model. Re-run volatile checks shortly before closing because customer churn, privileged access, incidents, and vendor consent can change during negotiation. The deal is priced on a living business, not the repository snapshot copied at the start of diligence.

The handover is the last diligence test

The handover proves whether the acquired company can function without the transaction team translating every detail. Treat the period between signing and closing as an operational test, with clear owners and acceptance criteria for revenue reporting, customer obligations, production control, and knowledge transfer.

Prepare a first-day authority map. It should show who can approve releases, spend, refunds, customer credits, security actions, vendor changes, and emergency access. The buyer must know which decisions remain with the seller under the agreement and which move at closing. Ambiguity here creates either operational paralysis or an accidental breach of the transaction terms.

Build the first 30-day plan around verified risks rather than generic integration rituals. Schedule the consent that protects the largest revenue account, the credential transfer that prevents lockout, the restore drill that removes founder dependency, and the license purchase needed for continued operation. Defer cosmetic architecture work until the team controls production and can measure normal behavior.

Watch customer behavior through the close. Reconcile new sales, expansions, contractions, late payments, cancellation requests, support escalation, and usage changes against the diligence baseline. Sellers should disclose material movement, and buyers should avoid surprising customers with premature integration. A clean signing model can become stale after one large nonrenewal.

Set a cadence for unresolved findings with a named buyer owner, seller owner, due date, evidence requirement, and deal consequence. Close findings only on evidence. A document uploaded to the data room is not completion if the successor cannot use it. A vendor email is not consent if the contract requires a signed assignment.

The strongest acquisition teams remain willing to walk away when they cannot establish ownership, revenue quality, or control of production. Most findings do not kill a deal. They change the amount paid, the cash held back, the obligations imposed before closing, and the work funded afterward. That is the purpose of technical diligence: turn uncertainty into terms before the buyer inherits it.