The SaaS due diligence checklist buyers actually use
What buyers check before acquiring a small SaaS: financials, revenue quality, tech, legal and IP, operations and customers, with what good looks like.
Published , 5 minute read
Due diligence is the buyer checking that the business is what the seller says it is. In small SaaS acquisitions it usually happens in two passes. Before the letter of intent, the buyer checks enough to be confident about a price. After it, they go deeper, confirm everything, and look for anything that would change the terms.
This checklist is organized the way most buyers work through it. If you are selling, use it to find your own gaps before a buyer does. If you are buying, use it as a starting point and adapt it to the deal.
Financial
The question here is simple: is the profit real, and will it continue after the sale?
| Item | What the buyer checks | What good looks like |
|---|---|---|
| Monthly P&L, 24 to 36 months | Trends, seasonality, one-off spikes | Monthly detail, consistent categories, cash or accrual basis stated |
| Add-backs | Whether each adjustment is genuinely discretionary or one-off | Itemized with a reason and supporting receipts |
| Bank statements | That revenue in the P&L actually arrived in the bank | Deposits that match billing payouts; business and personal kept apart |
| Expenses | Costs that will rise after the sale | Every recurring cost listed, with any below-market deals flagged |
| Tax filings | That reported revenue matches what was filed | Filings that reconcile to the P&L, or a clear explanation of differences |
| Liabilities | Deferred revenue, refunds owed, unpaid taxes, debts | Annual prepayments disclosed; how they are handled at closing agreed early |
Deferred revenue catches many first-time sellers out. If customers paid annually in advance, part of that cash is for months the buyer will serve. Buyers often ask for a price adjustment to cover it. Better to raise it yourself than have it discovered.
Revenue quality
Two businesses with the same MRR can be worth very different amounts. Buyers look at how durable the revenue is.
- MRR, calculated consistently. Annual plans divided by twelve, trials and one-time charges excluded, discounts reflected. Our guide on how buyers verify MRR goes through the adjustments.
- Churn. Logo churn (customers lost) and revenue churn (MRR lost, net of expansion). Monthly figures for at least a year.
- Cohorts. Do customers who joined 18 months ago still pay? Cohort retention shows whether churn is improving or getting worse.
- Concentration. If one customer is a large share of revenue, losing them after the sale could change the business. Buyers look at the top 1, 5 and 10.
- Payment health. Failed payments, involuntary churn, refunds, and dispute rates.
- Pricing history. Recent price increases can inflate MRR before churn catches up. Buyers ask when prices changed and what happened next.
- Payout reconciliation. Billing payouts matched to bank deposits. See reconciling Stripe payouts with bank deposits.
Technology
- Architecture overview, stack, and hosting setup
- Code quality, usually checked by the buyer's developer on a walkthrough or after the LOI with repository access
- Dependencies: third-party APIs, their terms, and whether any could be withdrawn or repriced
- Infrastructure costs and how they scale with customers
- Security: how secrets are stored, who has production access, past incidents
- Deploy process and how much of it depends on the founder's machine
- Bus factor: whether anyone other than the founder understands the system
| Red flag | Why it matters |
|---|---|
| Core feature depends on an API with a personal or non-transferable account | The feature may stop working at handover |
| No way to deploy without the founder | The buyer inherits a business they cannot operate |
| Customer data stored in ways that conflict with the privacy policy | Legal exposure that transfers with the business |
| Copyleft code in a closed-source product | May create license obligations the buyer did not expect |
Legal and IP
- The entity owns the code, domains and trademarks, and the seller has the right to sell them
- Every contractor and early contributor signed an IP assignment
- Open source license review
- Terms of service and privacy policy, and whether the product actually follows them
- Customer contracts with unusual terms: change of control clauses, exclusivity, custom SLAs
- Any disputes, claims, chargeback abuse or takedown notices
- Whether the deal is an asset sale or share sale, which changes what liabilities transfer
In many small SaaS deals the buyer buys assets rather than the company, which leaves most historical liabilities with the seller. It is still worth disclosing anything material. Surprises found after closing tend to end up as claims against the seller.
Operations
- How many hours a week the business really takes, and what those hours are spent on
- Written procedures for support, billing, onboarding and releases
- Support volume, response times and common issues
- Contractors: what they do, their agreements, and whether they will stay
- Every tool and account in use, and whether each one can be transferred
- The seller's transition offer: how long, how many hours, and what is included
Customers and market
- Anonymized customer list with plan, start date and MRR, before the LOI
- Named customer list, after the LOI
- Customer interviews or reference calls, if the buyer asks, usually late and with the seller's agreement
- Acquisition channels, from analytics: where customers come from and how dependent the business is on one channel
- Competitors and how the product is positioned
- Reviews and public reputation
How long it takes
Timelines depend on deal size, the buyer, and how organized the seller is. The seller's preparation is the part you control. A data room where every number traces back to a source, and every question has a written answer, removes weeks of back and forth. See what to put in a SaaS data room for how to lay it out.
Using this checklist with Arrhis
A Arrhis room covers the parts of this list that can be verified from source systems: revenue and payouts from Stripe, deposits from your bank, traffic from Google Analytics, and a reconciliation of payouts against deposits, each labelled with where it came from. Everything else is uploaded by the seller and labelled that way. Buyers ask questions in one place and see the answers alongside the data. Named customers and bank statements stay locked until the seller marks the buyer's LOI signed.
Create a deal room, open the demo room, or see pricing.
Related guides
- How buyers verify MRR, and why screenshots are not enoughHow acquirers check a SaaS's MRR: annual plans, trials, coupons, failed payments, revenue versus MRR, and matching payouts to bank deposits. 5 minute read.
- How to create a read-only restricted key in StripeStep by step: create a Stripe restricted key with read-only access for due diligence, which permissions to grant, and how to delete it afterwards. 6 minute read.
- Reconciling Stripe payouts with bank deposits before a saleHow to match Stripe payouts to bank deposits before selling a SaaS: payout timing, what gets netted out, failed payouts, and explaining unmatched items. 6 minute read.