Screen the Opportunity
Decide whether the business fits your acquisition criteria before asking for detailed information.
Use this working checklist to examine the financial, recurring revenue, customer, product, technical, legal, security, operating, commercial, and transfer risks that can matter before acquiring a SaaS business.
Mark items complete as evidence is reviewed rather than reading another generic acquisition article.
Move beyond revenue and review customers, product, technology, legal, security, operations, and transferability.
Add notes under every category and keep them locally in your browser while you work.
Use your browser print dialog to print the completed checklist or save it as a PDF for your own records.
The objective is not to reach 100 percent as quickly as possible. The objective is to understand what you can verify, what remains uncertain, what requires specialist review, and whether unresolved risks affect the transaction.
Decide whether the business fits your acquisition criteria before asking for detailed information.
Ask for records that support the claims material to your evaluation rather than relying only on seller summaries.
Compare financial, customer, technical, product, contractual, and operating information for consistency.
Move legal, tax, accounting, technical, privacy, or security questions to qualified specialists when needed.
Decide whether unanswered questions should change price, terms, conditions, structure, or your decision to proceed.
Work through the categories below. A checked item means you have reviewed it to the level appropriate for your transaction, not that the underlying business has automatically passed the review.
The appropriate evidence depends on the transaction, but important claims should generally be supported by records that let you understand how the seller arrived at them.
Accounting records, profit and loss statements, bank records, payment processor reports, invoices, tax records where appropriate, and supporting schedules.
Whether reported revenue, expenses, profitability, liabilities, and adjustments are reasonably supported.
Subscription exports, billing records, customer-level recurring revenue data, plan information, cancellations, refunds, and cohort records.
Whether MRR, ARR, churn, retention, expansion, and concentration are being calculated consistently.
Customer contracts, renewal terms, support records, customer lists where appropriate, major account history, and concentration analysis.
Whether revenue is durable and whether major customers create material dependency.
Architecture documentation, repositories, infrastructure inventory, dependency lists, issue trackers, deployment documentation, and technical walkthroughs.
Whether the product is maintainable, transferable, scalable enough for your plan, and understood by people beyond the founder.
Incorporation documents, capitalization information, employment and contractor agreements, IP assignments, licenses, customer contracts, and material vendor agreements.
Whether the seller owns or controls what the transaction intends to transfer and whether material obligations exist.
Account inventory, access matrix, vendor list, domain ownership, repository ownership, cloud ownership, billing systems, operating procedures, and transition plan.
Whether the business can actually change control without breaking important systems or relationships.
These situations do not automatically make a SaaS business unattractive. They are reasons to investigate the underlying facts before deciding how much weight to give them.
Revenue, customer counts, recurring revenue, or profitability differ materially between presentations, billing systems, accounting data, or supporting records.
A major customer relationship may materially change business economics if it is lost, renegotiated, or cannot transfer cleanly.
Critical deployment, sales, customer, technical, or operational knowledge exists primarily with the founder and has not been documented.
Cloud, app marketplace, payment, advertising, social, domain, or vendor accounts may have ownership or transfer restrictions.
Former contractors, agencies, employees, open-source licenses, or third-party components create uncertainty around intellectual-property rights.
The business relies heavily on one search ranking, integration partner, advertising account, marketplace, reseller, affiliate, or founder relationship.
A checklist helps organize questions. It does not turn the buyer into an accountant, lawyer, tax adviser, software architect, or cybersecurity professional.
Before closing, buyers and sellers should also understand how payment, legal ownership, access, customer relationships, systems, and post-close support will move from one side to the other.
The parties should understand the relationship between signed agreements, closing conditions, payment, and transfer obligations.
Transfer planning should cover the systems and relationships required for the SaaS business to continue operating after closing.
Completing this checklist does not verify a business, certify financial information, guarantee that all risks have been identified, determine valuation, recommend an acquisition, or guarantee a successful transaction. Buyers and sellers remain responsible for their own evaluation, professional advice, agreements, payment arrangements, transfer process, and transaction decisions. HTBS may facilitate marketplace discovery and deal conversations, but marketplace participation or listing review should not be treated as independent transaction diligence.
Depending on the business and transaction, diligence commonly includes financial performance, recurring revenue quality, churn and retention, customer concentration, product and technology, security and privacy, intellectual property, contracts, team dependencies, sales and marketing, transaction terms, and transfer readiness.
No. MRR and ARR can help describe recurring revenue, but a buyer may also need to understand how those figures are calculated, retention, churn, concentration, margins, customer contracts, non-recurring revenue, and the records supporting the reported figures.
The depth should be proportionate to the transaction, but a smaller purchase price does not automatically eliminate important risks. Ownership of code, revenue quality, payment accounts, platform dependencies, customer concentration, and transferability can matter even for very small SaaS businesses.
No blanket independent verification should be assumed. HTBS may review founder submissions and request clarification as part of its marketplace process, but that review is not an accounting audit, legal due diligence, technical certification, security assessment, valuation opinion, or investment recommendation.
Technical diligence may require enough access or evidence to understand architecture, maintainability, dependencies, ownership, and technical risk. The exact access, timing, confidentiality protections, and reviewer should be agreed by the parties based on the transaction.
An NDA may be appropriate when a conversation progresses toward commercially sensitive information. It is not automatically required for every initial discussion, and the parties should obtain legal advice if they need help deciding what confidentiality terms are appropriate.
Yes. The checklist includes transaction structure, payment timing, closing conditions, possible third-party payment arrangements, account transferability, credentials, domains, infrastructure, customer communication, and transition support.
Yes. Your selections and category notes are stored locally in your current browser. You can also use the Print or Save PDF button to open your browser's print dialog and save a copy as a PDF if your browser supports that option.
Use the checklist to organize your evaluation, involve specialists where necessary, and separate what has been verified from what still needs answers before you decide whether to proceed.
