13 minute guide · Updated 2026-09-15

Startup Buyer Due Diligence Checklist

A practical checklist for validating revenue quality, customer concentration, technology, operations, and transferability.

Due diligence tests whether the business you can buy is the business you think you are buying. For SaaS, that means reconstructing revenue, confirming ownership and transferability, reviewing the product and security, and proving operations can continue after the founder leaves. Identify uncertainty early enough to walk away, require a fix, adjust value, or allocate the risk.

This guide is an operating framework, not legal, tax, accounting, cybersecurity, or investment advice. Use professionals who understand the transaction structure and applicable jurisdictions.

Start with an acquisition thesis

Write down what must be true for the purchase to work. For example, one buyer’s screening thesis might require:

  • at least 85% of revenue is genuinely recurring;
  • no single customer represents an unacceptable share of revenue;
  • the product can run within your technical competence and budget;
  • core code, domains, data rights, contracts, and accounts can transfer;
  • the business can operate within a defined weekly workload after transition;
  • downside cash flow can support any debt or seller note.

Turn each into a test, evidence request, and failure threshold.

Browse startups for sale to form hypotheses, not conclusions. RevenueBug asking prices are seller-provided. RevenueBug is evidence, not an audit or broker; its methodology describes what a displayed verification does and does not establish.

Run diligence in stages

Do not ask for every sensitive document on day one. Stage the work so each round earns the time and disclosure required for the next.

Stage 1: screen the opportunity

Use the listing, an introductory call, and redacted evidence to confirm what is being sold, why now, metric definitions, owner workload, customers, technology, asking price, and transition. Request at least 24 months of monthly revenue, expenses, anonymized concentration, traffic by channel, and an asset list. Stop if the economics or deal perimeter cannot work.

Stage 2: validate under confidentiality

Under appropriate confidentiality terms, request raw billing exports, payouts, bank evidence, financial statements, customer schedules, key contracts, source and dependency summaries, access inventories, and runbooks. Rebuild the metrics and sample records in both directions: customer to cash and bank deposit to underlying transactions.

Stage 3: specialist review and confirmatory testing

If the economics still work, review corporate authority, IP, contracts, privacy, employment, disputes, architecture, code, infrastructure, supply chain, access, incidents, recoverability, earnings quality, liabilities, and tax structure. Use relevant specialists. Source review does not require production credentials; customer interviews or live-system testing require agreed scope and timing.

Stage 4: convert findings into closing conditions

Maintain an issue log with evidence, impact, owner, response, and deadline. Distinguish:

  • facts the seller must correct;
  • consents or assignments required before closing;
  • risks reflected in price or payment timing;
  • liabilities excluded or specifically allocated in the agreement;
  • post-close work with a funded budget;
  • unresolved conditions that require walking away.

Reconcile revenue from customer to cash

Treat seller dashboards as leads. Build the result from source records.

  1. Obtain transaction-level billing exports, not screenshots alone.
  2. Recalculate gross billings by month and currency.
  3. Separate sales tax, discounts, credits, refunds, disputes, processor fees, and reserves.
  4. Tie net settlements to processor payout reports.
  5. Tie payouts to bank deposits, allowing for timing and foreign exchange.
  6. Tie earned revenue to financial statements and tax records, explaining cash-versus-accrual differences and deferred revenue.
  7. Rebuild MRR: beginning MRR plus new and expansion, minus contraction and churn, equals ending MRR.

Define metrics first. Exclude setup fees, consulting, lifetime deals, affiliate income, and other one-time sales from recurring revenue. Identify failed payments, pauses, free accounts, test charges, scheduled cancellations, and annual plans approaching renewal.

Use the MRR and ARR calculator to test a consistent recurring-revenue definition. Do not simply multiply the best month by 12. ARR is a run-rate operating metric, not the same thing as revenue recognized during a period or cash collected.

Reconstruct expenses from bank, card, payroll, and vendor records. Challenge add-backs and estimate replacement cost for founder labor, support, development, sales, bookkeeping, compliance, and expiring vendor discounts.

For U.S. asset acquisitions, the IRS instructions for Form 8594 explain that buyer and seller may have to report purchase-price allocation among asset classes. Ask tax advisers to model structure and allocation before the documents harden; this guide does not determine what applies.

Test cohorts, concentration, and demand quality

Aggregate growth can hide a leaking base. Build cohorts by first paid month or contract start and inspect retained logos and recurring revenue. Segment by billing interval, sales motion, plan, customer size, geography, or channel.

Calculate both gross revenue retention and net revenue retention, and show expansion separately from contraction and churn. Check renewal-month cliffs for annual contracts. Review cancellation requests that have not yet become effective and customers retained through unusually deep discounts.

Measure concentration using current MRR, trailing revenue, and cash collected. For top customers, review term, renewal, payments, usage, support, discounts, and termination or change-of-control rights. There is no universal safe percentage; model the downside.

Do the same for channels and vendors. Organic traffic concentrated in a few pages, an app-store ranking, one affiliate, one paid campaign, or one API can be customer-concentration risk in another form. Verify analytics ownership, historical changes, attribution definitions, and whether ad, marketplace, social, and search-console accounts can transfer.

Review product and technology

Determine whether the product works, can be safely changed, and can run at your assumed cost and staffing. Request architecture and data-flow diagrams, repositories, deployment process, hosting bills, third parties, dependencies, tests, monitoring, incidents, roadmap, and known debt. Observe a non-production deployment and rollback.

Investigate:

  • components only the founder understands;
  • unsupported runtimes or materially outdated dependencies;
  • manual jobs represented as automation;
  • missing tests around billing, permissions, and data loss;
  • hard-coded secrets or shared administrator accounts;
  • infrastructure or domains held in personal accounts;
  • restrictive open-source or commercial licenses;
  • cost spikes at plausible growth levels;
  • backlogs that contradict product-quality claims.

Estimate a 100-day remediation budget with owners and effort. An opaque system with no recoverability may be unacceptable.

Evaluate security and privacy evidence

Use a risk-based framework. NIST SP 800-218 organizes secure development around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. CISA’s Software Acquisition Guide provides acquisition questions across software supply chains, development, deployment, and vulnerability management.

Ask for evidence of:

  • multifactor authentication, least privilege, access reviews, and prompt offboarding;
  • secret storage, code review, dependency scanning, patching, and vulnerability handling;
  • encrypted transport, appropriate storage protection, logging, alerting, and retention;
  • tested backups, recovery objectives, incident response, and prior incident records;
  • a data inventory, subprocessors, retention and deletion practices, privacy notices, and customer commitments;
  • security questionnaires, audits, attestations, penetration tests, or compliance claims the seller has given customers.

For audits and scans, confirm scope, date, exceptions, and remediation. Compare practice with contracts and marketing claims. Unknown incidents are not no incidents.

Confirm legal ownership and transferability

Create an asset-and-contract matrix. For every material item, record who owns it, documentary proof, restrictions, consent requirement, transfer procedure, and consequence if unavailable.

Review founder, employee, contractor, and agency IP assignments. Match names and dates to repository history and product creation. Technology M&A counsel warns that inbound licenses, joint-development rights, “springing” licenses, government or university funding, and anti-assignment or change-of-control clauses can limit what a buyer receives.

Examine customer and vendor agreements, terms of service, privacy and data-processing terms, debt and liens, disputes and claims, employment and contractor arrangements, permits, trademarks, domains, and open-source notices. Confirm which entity contracted and which entity owns the asset. An asset purchase and an equity purchase may produce different consent, liability, and tax results; have counsel analyze the proposed structure.

Verify operations and the handover

Compare a two-to-four-week seller time log with support, releases, sales, bookkeeping, refunds, and vendor management. Identify tasks dependent on personal reputation or undocumented judgment.

Run scenario tests: a failed deployment, payment-provider hold, database restore, key vendor outage, high-severity support case, and the largest customer threatening cancellation. Who notices, who acts, what access is needed, and how long does recovery take?

Create a transition plan with systems, deliverables, hours, and acceptance criteria. Cover credentials, domains, vendors, customer communications, repositories, documentation, billing, administrator changes, and post-close support.

Map each risk to a deal response

Do not use a discount as the answer to every problem.

  • Fix before close: missing IP assignment, required consent, broken backup, inaccurate schedule, or transferable account setup.
  • Closing condition: delivery of assets, key-customer consent, lien release, or successful migration test.
  • Price adjustment: lower sustainable MRR, understated recurring costs, deferred maintenance, or lost contract.
  • Holdback or escrow: a specific, time-bounded exposure where recovery terms can be clearly documented.
  • Earn-out or contingent payment: uncertainty in future performance, with definitions, control rights, measurement data, and dispute mechanics drafted carefully.
  • Seller financing: aligns payment over time but creates credit, priority, covenant, and enforcement questions.
  • Representation, warranty, covenant, or indemnity: legal allocation of a defined risk, subject to negotiated scope and limitations.
  • Longer transition: concentrated seller knowledge or relationships that can realistically be transferred.
  • Walk away: ownership, legality, honesty, security, or economics cannot be made acceptable.

Deal terms do not repair a business. A small escrow is poor compensation for code you cannot lawfully use or a product you cannot safely operate.

Use the SaaS valuation calculator to model changed assumptions, not to outsource judgment. Compare base, downside, and severe cases for churn, concentration loss, replacement labor, hosting, remediation, and financing.

Then use the startup acquisition ROI calculator to test whether debt service and buyer equity still work under those revised assumptions.

Sample diligence questions

Ask questions that require a definition and evidence:

  • Show how December ending MRR ties to every active subscription and the January opening balance.
  • Which customers have canceled but remain active through a paid period?
  • Trace three sampled bank deposits back to processor settlements and customer charges.
  • What percentage of trailing revenue comes from the top one, five, and ten customers?
  • Which annual contracts renew in the next 120 days, and what happened at prior renewals?
  • Who wrote each major product component, and where is the signed assignment?
  • Which contracts require consent for an asset sale, assignment, or change of control?
  • Demonstrate a backup restore and a non-production rollback.
  • List all people with production, billing, domain, repository, and customer-data access.
  • Describe the most serious incident or outage, including corrective actions.
  • Which operating task would fail first if the founder disappeared for 30 days?
  • Which listed asset or account is held personally or cannot be transferred?
  • What commitments have been made to customers that are absent from the roadmap?
  • What cost is currently free, discounted, deferred, or paid personally?
  • What fact would you want to investigate first if you were the buyer?

Walk-away conditions

Set these before exclusivity. Common reasons to stop include:

  • the seller will not provide raw evidence needed to validate a material claim;
  • revenue, cash, tax records, or customer schedules differ materially without a credible reconciliation;
  • deliberate misrepresentation or repeated metric-definition changes destroy trust;
  • core IP ownership is unresolved and cannot be cured;
  • a critical contract, license, account, domain, or dataset cannot lawfully transfer or be replaced;
  • undisclosed liabilities, disputes, security incidents, or privacy practices create unacceptable exposure;
  • concentration or churn breaks the downside case;
  • the product cannot be restored, secured, or operated within the available capability and budget;
  • financing depends on aggressive assumptions rather than downside cash flow;
  • pressure to skip professional review, contact customers prematurely, or send funds outside agreed controls.

A walk-away threshold is useful only if you honor it. Sunk diligence cost is not a reason to buy a different business from the one you underwrote.

For a view of what organized sellers should provide, read how to prepare a startup for sale. Sellers ready to build a verified public profile can submit a startup.

Frequently asked questions

Is verified revenue enough to make an offer?

It may justify further investigation or a conditional indication of interest. It is not enough to close. RevenueBug is evidence, not an audit or broker; independently verify financial, customer, technical, legal, security, and operational facts.

How much financial history should I request?

Usually request at least 24 months, and 36 months when available, so seasonality, annual renewals, pricing changes, and cohorts are visible. A younger business should provide its complete history.

Should I rely on the seller’s asking price?

No. Asking prices on RevenueBug are seller-provided. Build an independent range from sustainable cash flow or recurring revenue, growth, retention, concentration, replacement labor, transfer risk, and the exact deal terms.

When should I contact customers?

Normally late in diligence, after material records have been validated and with the seller’s agreement. Use a small, risk-based sample and a coordinated script. Premature outreach can damage the business you may buy.

Do I need specialists for a small acquisition?

The SBA’s buyer guidance recommends thorough, objective investigation and notes the roles of attorneys and accountants. Scale the team to the risks: financial reconciliation, IP and contract review, tax structure, and product security can require expertise even when the purchase price is modest.

Sources