AI & SaaS M&A

Buying a software or AI company is a bet on two things: customers will keep paying for the product, and you can run and extend it at a profit. Recurring billing and a strong demo are where diligence starts. The most important thing to establish is what the target owns that a competitor with the same AI models could not copy.

This guide connects commercial, technical, and financial diligence so the investment committee can see what exists today and what you would have to build after closing. It applies to mature software platforms, usage-priced products, and early AI businesses; only the weight on each workstream changes.

Choose the acquisition thesis before choosing the metric

What you are buying decides which evidence matters most.

State the thesis as a sentence that could be proven wrong: “The target's workflow cuts an enterprise customer's document review effort enough to support paid expansion, and our sales force can reach those customers without rebuilding the product.” Diligence must test every clause, including whether your sales force actually reaches the person who owns the budget.

Agree one revenue definition first

Finance should approve a dictionary of metrics before anyone compares numbers. Define each of these separately:

• Annual recurring revenue (ARR)
• Contracted commitments and remaining obligations
• Consumption (usage) revenue
• Bookings and deferred revenue

Then reconcile customer-level schedules to billing and the general ledger. Look for free periods, ramped contracts, reseller sell-through, cancellation rights, refunds, and services sold as software.

Measure retention on a fixed starting group of customers:

Net revenue retention = (opening recurring revenue + expansion − contraction − churn) / opening recurring revenue

New customers never enter the numerator. Report gross revenue retention and logo retention next to it, and use one policy for currency and for which businesses sit inside the deal perimeter. For usage-priced products, show actual usage and commitments separately. Annualizing one strong month can overstate what repeats.

The table shows the evidence that most often changes the price, and what moves in the model when that evidence is weak.

Test the AI on real work at full cost

Have your own technical reviewers reproduce performance on representative tasks the target has not seen. Include the cases that break AI products:

• Noisy documents and, where relevant, uncommon languages
• Incomplete inputs and adversarial prompts
• Long, multi-step workflows
• Cases where the right answer is to decline

Define acceptable errors by what they cost the customer. An average accuracy score can hide one failure that makes the product unusable for a large account.

Then measure the full cost of each task: model calls, retries, retrieval, indexing, external tools, storage, human review, support, and customer credits. Price it at the customer's expected usage pattern, including the heaviest users, whose economics can look very different from the average. Test dependence on one model provider: fallback quality, rate limits, and the work needed to replace a critical model or API.

Build these costs into an editable workbook with cohorts and contribution by workload, and keep any missing usage or cost allocation as an open input. The AI in M&A guide explains the source-to-workbook method.

For a shared vocabulary on AI risk, NIST publishes a voluntary AI Risk Management Framework and a generative AI profile. They give the review a structure; they do not certify product quality. NIST AI Risk Management Framework.

Try to rebuild the headline feature with off-the-shelf models

Every AI deal turns on one question: what could a capable competitor copy, how fast, and how hard would it be for customers to switch? Management will point to “our models.” Yet many AI products run on general-purpose models that competitors can license too. The advantage usually sits elsewhere: proprietary data, the product's place in the customer's daily workflow, integrations, evaluation data, or distribution.

The most direct way to find it is to try to copy the product yourself. An AI assistant can play a competitor's engineer, working only with a general-purpose model and public documents of the same kind the demo uses. Whatever it can rebuild deserves no premium. Whatever it cannot rebuild shows where to spend diligence.

A good answer separates features from advantages. An abridged, hypothetical excerpt for a contract-review product:

Rows marked “yes” are features: value them as capabilities competitors will match. Rows marked “no” or “partly” become the diligence plan. Confirm the data rights in the next section, and check retention among the customers who use those capabilities most. The one check that matters: a failed rebuild may just be a weak attempt. Before you count a “no” as an advantage, find the missing ingredient in the data room, whether that is the data license, the integration certification, or the evaluation set.

Review data rights for the use you intend

List each kind of data separately: training, fine-tuning, evaluation, retrieval, and customer production data. For each, record where it came from, what permission covers it, its restrictions, retention and deletion terms, and any change-of-control questions for counsel. Permission to process customer data to deliver a service covers that service. Using the same data to build a new product may need separate permission.

Apply the same discipline to open-source components, code written by contractors, university work, licensed datasets, and model outputs. Ask counsel to resolve the transaction and intended-use issues, then connect their conclusions to the technical plan. Keep any “data synergy” out of the committed case until both the rights and the usefulness are established.

Value the cash flows and compare with building

Model customers, recurring revenue, gross margin, acquisition spending, development investment, working capital, and cash taxes. Cross-check the result against truly comparable businesses, using dated evidence and the same revenue definitions. An ARR multiple, or a growth-plus-margin shortcut such as the “Rule of 40,” should never set the bid by itself.

Compare buying with building, partnering, licensing, and waiting, against the same customer outcome and time horizon. Include integration spending, retention awards, revenue lost in migration, and the cost of delay. Count the acquired revenue once: as standalone cash flow or as part of a customer-base premium, never both.

In the downside case, link the risks that travel together: a slower sales ramp, higher AI running costs, weaker retention, and delayed migration. A product that needs more human review has worse margins and a weaker customer offer at the same time.

Example: an AI product whose margin left out the review work

This case is fictional; the figures illustrate the method.

A target reports $30 million of annualized revenue and a 75% gross margin. Finance finds that $6 million comes from one recent deployment whose usage has not settled. Technical diligence finds human review and retry costs left out of the reported margin.

The buyer replaces the single “$30 million of durable ARR” with customer scenarios. It assigns delivery costs to the workloads that cause them and models a price increase only where customer interviews support one. Engineering has a plan to cut running costs, but that saving stays in the upside case until it is tested on production-like workloads.

The bid now rests on observed economics and a funded improvement plan. If the seller wants to be paid at signing for the full cost-reduction upside, the committee can see exactly which unproven assumption it is being asked to finance.

Integrate around what customers pay for

Before signing, agree who decides what:

• Product and engineering: which capabilities stay independent, which APIs connect first, and which product is the master record for identity, entitlements, billing, and support
• Sales leadership: eligible accounts, compensation credit, enablement, and service capacity
• HR: clear roles, and competitive, role-appropriate retention for critical people

After closing, sequence the work by its real dependencies: identity and security controls, financial visibility, customer continuity, then product integration. A shared logo integrates the brand, not the product. A cross-sell launch needs a working combined solution, an accountable owner, and a support team that can fix problems across both products.

Review these signals together: renewal cohorts, deployment success, paid usage, contribution margin by workload, critical defects, integration spending, and roadmap delivery. Escalate if retention falls while bookings rise, or if new usage deepens losses. Either signal is the moment to adjust prices, product scope, or integration pace, while the original thesis can still be recovered.

Related resources

Continue with AI in M&A, Cybersecurity M&A, and DCF Analysis.