The Ultimate SaaS Due Diligence Checklist for Sellers (2026 Edition)

Due diligence is the examination you must pass to sell your software company. Buyers will not stop at your bank statements — they will read your code architecture, trace your IP ownership back to every contractor who ever touched the repository, and rebuild your churn cohorts from raw data.

Being unprepared is the single most common reason deal value falls after a Letter of Intent is signed. This checklist covers what buyers ask for in each of the four diligence workstreams, what they are actually testing, and how to assemble the evidence before anyone requests it.

What is due diligence in a software acquisition?

Due diligence is the buyer’s verification period, typically running 45 to 90 days after the LOI is signed. The buyer confirms that the financial, technical, legal, and commercial claims that justified their offer are true. Anything they cannot verify becomes a reason to reduce price, expand the escrow, or walk.

The critical asymmetry: by the time diligence starts, you have already agreed to a price. From that moment, every finding moves the number in one direction. Preparation is not administrative housekeeping — it is the last stage at which you still control the outcome. Understanding which clauses in a Letter of Intent shape that leverage before you sign one is time well spent.

What financial documents will a buyer ask for?

Buyers want to reconstruct your revenue from source data rather than accept your summary of it. Expect requests for three years of monthly financials on an accrual basis, a customer-level revenue dataset, and cohort retention analysis. Cash-basis books prepared for tax purposes will not survive this stage.

• Monthly P&Ls, three years, accrual basis. Cash-basis statements must be converted before the process begins, not during it.
• ARR by customer. An anonymized dataset with contract start dates, renewal dates, expansions, and churn events — enough for the buyer to rebuild your ARR bridge independently.
• Cohort retention analysis. Gross and net revenue retention by signup cohort. Blended averages hide the pattern buyers are looking for.
• CAC and payback. Sales and marketing spend against new ARR booked, with the allocation methodology stated explicitly.
• Deferred revenue and billing schedules. Reconciled to the balance sheet.
• Contractor and employee census. Roles, comp, start dates, and classification.

Two areas cause disproportionate trouble. The first is the difference between committed and recognized revenue — get clear on how ARR and MRR each affect valuation before a buyer’s analyst reconciles them for you. The second is normalized earnings, which is why many sellers commission a sell-side quality of earnings report rather than let the buyer’s accountants define the adjustments unopposed.

What happens in technical due diligence?

Technical diligence assesses whether the product can be maintained and scaled by someone other than you. A buyer’s engineers or an outside firm will review architecture, code quality, security posture, and open-source exposure — usually across several sessions with your engineering leadership.

• Architecture diagram. Services, data flow, third-party dependencies, and hosting topology.
• Open-source inventory. A software composition analysis report (FOSSA, Black Duck, or equivalent) listing every library and its license.
• Security evidence. Penetration test results, vulnerability scan history, incident log, and SOC 2 report if you hold one.
• Technical debt log. A candid assessment of what needs refactoring, with rough effort estimates.
• Development process. Code review practice, test coverage, CI/CD pipeline, and release cadence.
• Key-person concentration. Which systems only one engineer understands.

Copyleft licenses deserve specific attention. A GPL or AGPL dependency inside a distributed product can, in the buyer’s counsel’s reading, oblige you to release your own source. It is a findable, fixable problem months ahead of a deal and an expensive one to discover mid-diligence. If your product incorporates machine learning, the licensing questions that open-source models and fine-tuning raise are more involved still.

The sessions themselves are also a test of your team. Preparing your engineers well — what to expect in code reviews and architecture discussions — changes how the buyer reads the same codebase.

What legal and IP documents do buyers require?

Legal diligence establishes that the company actually owns what it is selling. In software transactions, this is where deals most often break, because IP ownership defects are common, invisible in normal operations, and cannot be fixed retroactively without the cooperation of people who no longer work for you.

• IP assignment agreements from 100% of contributors — employees and contractors, current and former.
• Cap table, fully diluted. Including options, warrants, SAFEs, and convertible notes.
• Customer contracts. MSAs, order forms, and any agreement containing assignment or change-of-control provisions.
• Vendor and partner agreements. Particularly any with exclusivity or most-favored-nation terms.
• Corporate records. Formation documents, board minutes, and stock issuance history.
• Litigation and claims history. Including threatened claims.
• Privacy and compliance documentation. DPAs, subprocessor lists, and your GDPR or CCPA position.

The contractor problem is worth stating plainly, because founders consistently underestimate it. In the United States, work-for-hire does not automatically transfer copyright from an independent contractor to the company — absent a signed written assignment, the contractor retains ownership of the code they wrote. A freelancer from 2019 can therefore hold rights in a core module. This is recoverable, but the remedies available when early contractors never signed IP assignments get harder and more expensive the later they are attempted.

If your company handles significant customer data, expect the compliance request list to be long and specific — what acquirers expect for privacy, security, and SOC 2 documentation is a useful scope check. And because diligence requires handing your most sensitive assets to a party who may also be a competitor, structuring how your IP is disclosed during the process matters as much as having the documents.

What sales and marketing data do buyers examine?

Commercial diligence tests whether growth is repeatable without the founder. Buyers examine pipeline quality, sales productivity, and customer concentration — looking for evidence that revenue comes from a functioning system rather than from relationships that leave when you do.

• Weighted pipeline report. With historical conversion rates by stage, so the weighting can be validated.
• Sales compensation plans. Quotas, commission structures, and attainment history by rep.
• Customer concentration. Revenue share held by the top 5 and top 10 accounts.
• Win/loss analysis. An honest account of where you win and where you lose.
• Marketing attribution. Channel-level spend and pipeline contribution.

Customer concentration is the finding most likely to change deal structure rather than price. A buyer looking at 40% of revenue in three accounts will typically respond by shifting consideration into an earn-out, which is why it is worth understanding how earn-outs are structured before the topic arrives as a proposal.

What findings most often reduce the price?

The re-trade almost always traces to one of a small number of recurring findings: unassigned IP, revenue that cannot be reconciled to source data, undisclosed customer concentration, copyleft license exposure, or a security incident that surfaces late. None of these are exotic, and all of them are discoverable in advance.

What distinguishes a manageable finding from a damaging one is usually disclosure timing. A problem you surface yourself, with a remediation plan attached, is a negotiation. The same problem discovered by the buyer’s counsel in week six is a credibility event that colors every subsequent request. The red flags buyers most often surface in legal and financial review is the closest thing to the buyer’s own list.

Companies with an AI product face an additional workstream. Buyers now ask detailed questions about model provenance and training data, and whether copyrighted or scraped training data creates acquisition risk is now a standard line of inquiry rather than an edge case.

How should you prepare before diligence starts?

Begin six to twelve months before going to market. Convert the books to accrual, run a software composition analysis, audit IP assignments against a full contributor list, and resolve the gaps while the people involved are still reachable. Then build the data room so that requests are answered rather than researched.

Organization matters more than founders expect: a buyer who can find documents forms a different view of the company than one who waits four days for each response. How to structure a data room for a software or AI company covers the folder architecture and the must-have documents in detail.

Diligence also runs while you are still operating the business, often without the wider team knowing. Keeping the team steady while diligence proceeds quietly is a real part of the work, not a footnote to it. And the same preparation that clears diligence tends to raise the number in the first place — the operational levers that increase valuation before a sale overlap substantially with this checklist.

Get the full exit-ready audit

At iMerge Advisors we run a predictive diligence process for our clients — identifying and resolving these issues before we take a company to market, so the buyer’s findings hold no surprises and the agreed price is the price that closes.

Don’t let a paperwork error cost you millions. Contact us to prepare your data room correctly.

This is part of our coverage on the M&A process and due diligence in the Founder's Exit Guide.