Guide · Published 2026-11-04
Software company acquisition due diligence: a buyer's checklist for small software and data businesses.
Due diligence on a software company tests the same thing as on any business, whether the seller's figures and claims survive the documents, plus four areas specific to software: whether recurring revenue is really recurring, whether the company owns its code and its data, whether customer contracts transfer to a new owner, and whether its security matches what customers were promised. The checklist below lists what to request and how to test each item.
What makes a software deal different
In a services or distribution business most of the value sits in customers and people you can meet. In a small software or data business much of it sits in things that are hard to see in a CIM: a codebase, a database, a set of subscription contracts and the security promises made in those contracts. A buyer who reads only the financials can miss all four.
The financial work does not go away. Revenue still has to tie between the CIM, the statements and the tax return, add-backs still need support, and a lender still applies its own rules. Those checks are covered in QoE testing: what reviewers check and the data room checklist. This guide adds the software layer on top.
It is written for a buyer of a small company, such as a search fund, an independent sponsor or an individual acquirer, who may have no technical team. Where an item needs a specialist, it says so.
The checklist
Use the table as a request list and a test list. Drop rows that do not apply; a single-product company with a dozen customers needs less than a platform with thousands. No row replaces a lawyer's review of the contracts or a technical review of the code where the deal depends on them.
| Area | What to request | How to test it |
|---|---|---|
| Recurring revenue | Revenue by customer by period, the billing system export, the seller's definition of recurring revenue. | Rebuild recurring revenue from the billing export and compare it with the CIM. Check whether one-off fees, services or usage charges are counted as recurring. |
| Retention and churn | A customer list with start date, end date and revenue per period. | Compute retention yourself from the list, using one written definition. See key metrics for a SaaS acquisition. |
| Customer contracts | The top customer agreements, standard terms, any side letters. | Look for change-of-control and assignment clauses, termination for convenience, price caps and security commitments. |
| Code and IP | Who wrote the code, contractor agreements, IP assignment clauses, a list of open-source components and their licenses. | Confirm every developer, employee or contractor, signed an assignment. Ask a specialist to review open-source licenses if the product is distributed to customers. |
| Data rights | Privacy policy, data processing agreements with customers, the list of subprocessors, where data is hosted. | Check the company may keep and use the data after a change of owner, and that hosting matches what contracts promise. |
| Security and SOC 2 | Any SOC 2 or other assurance report, the security questionnaire answers given to customers, incident history. | Compare what customers were told with what the report covers. See SOC 2 in an acquisition. |
| Infrastructure and vendors | Hosting and key vendor contracts, who holds the admin accounts, domain and app store ownership. | Check the accounts are held by the company, not by the founder personally, and can move at closing. |
| Product and roadmap | Roadmap commitments made to customers, open support tickets, known defects. | Look for features promised in contracts that do not exist yet. |
| People | Organization chart, who maintains which part of the code, contractor dependence. | Find out who could keep the product running if the founder left on day one. |
| Financials and tax | Statements, tax returns, add-back schedule, deferred revenue schedule. | Tie revenue across documents and check how annual prepayments are recognized. |
Data businesses: three extra questions
When the product is the data itself, such as a dataset, a data feed or an analytics service, three questions decide much of the value, and none of them is answered by the financial statements.
- Where does the data come from, and on what terms? Ask for every licence, scraping policy, partner agreement and consent mechanism behind the main datasets. A source the company may not use after a change of owner is a source you are not buying.
- Does personal data run through it? If so, data protection law applies to the transfer. For EU personal data, processing on the company's behalf must be governed by a contract that meets GDPR Article 28, and transfers outside the EU must meet the conditions of Chapter V (Article 44). Ask a privacy lawyer which rules apply to this deal.
- Can the data actually be exported and used without the founder? Test it. A claim that an export is easy is a claim, not a test; the worked example below shows the sample brief catching exactly that.
Order of work: cheap checks first
The same staging used in the search fund due diligence budget applies here. Read the CIM against the financials, the customer list and the billing export first. A deal whose recurring revenue does not tie, or whose top contracts cannot be assigned, can fail at that stage without a paid code review.
Paid technical work, such as a code review, a penetration test or an open-source licence scan, belongs after a signed LOI, when the scope can be written against what the first pass found. The phases from LOI to close are in the LOI to close timeline.
What software can do here, and what it cannot
Software that reads documents can tie revenue figures across the CIM, statements and tax return, list contract clauses that need a lawyer's eye, and compare what management said on a call with what the documents support. It cannot review source code it was not given, judge the quality of an engineering team, or give a legal opinion on licences.
Deal OS is diligence software for buyers of small companies. You upload the CIM and the rest of the data room and get a brief in which each claim cites its source page; a verifier discards claims it cannot tie to a passage, and the brief lists what was discarded. See AI due diligence software for the criteria to judge any tool, the sample brief for real output, and pricing for how a single deal is priced.
Worked example from the sample brief
The sample brief is a synthetic fire and life-safety company, not a software business. These four findings are quoted from it because they are the same kind a software buyer meets: a data claim, a contract question and a recurring revenue definition.
- A data claim contradicted by the documents. On the management call the seller said "exporting the data out is no problem at all". The brief marks the statement contradicted, because the CIM says on page 16 that "the seller notes that data export from this system has not been tested."
- A data risk turned into a diligence step. The brief files the same point as missing information, "Core operating data may not be exportable", and says to test data export during diligence, not after close.
- Contract transfer left open by the seller. Contract assignability is unreviewed: "The seller has not undertaken a review of change-of-control or assignment provisions across the contract base" (CIM page 19).
- A definition that changes what a number means. Page 7 says about 78% of revenue is recurring. Page 22 defines recurring as all revenue from accounts with an active inspection agreement, including repair and call-out work. The brief flags the two passages as inconsistent and asks for a revenue cut that separates fixed billings from variable work.
The example is Sentinel Fire & Safety, Inc., a synthetic company built to show the product. Nothing in it describes a real business, and the same output shape applies to a real data room. See the whole thing at /sample-brief.
Questions
Frequently asked questions.
What is different about due diligence on a software company?
The financial checks are the same, but four areas matter more: whether recurring revenue is really recurring, whether the company owns its code and data, whether customer contracts transfer to a new owner, and whether security matches what customers were promised.
Do I need a code review to buy a small software company?
It depends on how much of the value sits in the code and how it is distributed. Many buyers run the document checks first and scope a technical review after a signed LOI, against what the first pass found.
What documents should a software company's data room include?
Financial statements and tax returns, revenue by customer, the billing system export, the main customer contracts, IP assignment agreements, an open-source component list, data processing agreements, the subprocessor list and any security assurance report such as SOC 2.
How do I check recurring revenue in a software acquisition?
Rebuild it from the billing system export using one written definition, and compare the result with the figure in the CIM. Look for one-off fees, services or usage charges counted as recurring.
Can AI due diligence software review source code?
Tools that read deal documents, such as Deal OS, work on the CIM, financials, contracts and call notes, not on source code. A code review is separate technical work.
Keep reading
See it on a deal.
Open a real brief on a synthetic deal without an account, or check how a single deal is priced.
