SaaS Exit Readiness: What Belongs in a Data Room?

Decide what the room must help a buyer verify

The purpose is to let a buyer test the business story: what generates revenue, how durable it is, what is owned, what depends on third parties and what would be required to operate the business after a transaction.

Start with an index, not a bulk upload. For each item, record its owner, reporting period, source system, last update, review status and disclosure permission. Maintain a separate question log linking buyer questions to the relevant evidence and unresolved follow-up.

Acquire.com's seller guidance describes diligence as collecting supporting evidence across business functions and selectively sharing it with buyer decision-makers. That is a useful example of the process, not proof that every buyer will ask for the same documents. [1]

Agree the actual scope with the buyer and advisers. An asset purchase, company acquisition and minority investment can require different records and approvals. This guide is a preparation framework, not jurisdiction-specific legal, tax or valuation advice.

Build a small, navigable evidence index

Use folders that answer distinct questions. Keep originals, working schedules and approved disclosure copies distinguishable, with clear version names and dates. An example structure is:

Mark missing evidence as missing. A file called “final” should not conceal estimates, expired contracts or unresolved differences. The index should help reviewers find uncertainty as easily as they find the headline metrics.

Separate cash, revenue and recurring metrics

Prepare a consistent monthly financial schedule for the period requested, with its currency, accounting basis and source references. Identify revenue categories, refunds, disputes, processor fees, operating expenses and unusual items. Keep proposed adjustments separate from the recorded results and explain each one.

Stripe documents reporting tools for payments, payouts, fees and balance activity, including payout reconciliation. Such exports can support a reconciliation, but a processor screenshot alone is not a complete set of accounts or independent assurance. [2]

Define MRR separately from cash collected. Stripe's Billing documentation uses monthly-normalized subscription values and allows some metric-definition settings to be configured. Save the definitions and relevant settings used in your schedules rather than assuming a dashboard label is self-explanatory. [3]

Include a bridge between reported metrics and source records, explaining timing differences, annual prepayments, one-off services, taxes, discounts and other relevant exclusions. Do not force unlike measures to match by changing labels.

Have an appropriate accounting adviser review material differences and proposed adjustments. File organization is not an accounting opinion, and a prospective buyer may ask for further financial diligence even when every schedule is supplied.

Show customer durability without exposing unnecessary data

Prepare customer and subscription schedules with stable internal identifiers, the period covered and documented inclusion rules. Start with aggregate or appropriately de-identified information where it answers the question; keep identifying records in a more restricted disclosure tier when needed.

Useful schedules can include revenue concentration, plan distribution, billing frequency, cancellations, refunds, expansion, contraction and retention by cohort. Distinguish a customer from a user, account or subscription. A large free-user count does not establish a large paying-customer base.

Show the calculation behind each retention or churn claim. Name the starting population, what counts as loss or expansion, how reactivations are handled and which period is being measured. Separate recurring subscriptions from services and lifetime purchases instead of presenting them as one recurring revenue pool.

For important customer agreements, prepare a summary of term, renewal, unusual commitments and provisions needing professional review in the proposed transaction. Do not assume a customer relationship transfers simply because the customer appears in an export.

Record known risks, including a concentrated customer base or unresolved support obligations. A clear explanation is more useful than a selective chart that cannot be reproduced.

Document what is owned, licensed or dependent on consent

Create an asset register covering code, domains, trademarks or brand assets, content, designs, data, app listings and material third-party accounts. For each, name the recorded owner, supporting agreement, administrative controller and any restriction requiring review.

Collect relevant founder, employee, contractor and supplier agreements for legal review. Possession of a repository or payment of an invoice should not be treated as a substitute for checking the rights your business can demonstrate and the transaction can convey.

Be explicit about licensed or white-label software. Identify the provider, agreement, permitted uses, support dependency and any transfer or change-of-control questions. Do not describe a licensed platform as proprietary source code that your business owns if that is not what the records establish.

Include entity and ownership records appropriate to the transaction, along with known disputes and commitments. Let qualified counsel determine the required documents, approvals and legal effect. The readiness task is to locate evidence and flag questions, not to invent missing assignments or backdate paperwork.

Make technical and operational dependence visible

Prepare an architecture overview, dependency inventory, deployment process, infrastructure cost schedule and operating runbooks. Explain who can release a change, restore a backup, handle a customer incident and maintain integrations. Where a process only exists in the founder's memory, record that gap.

Supply proportionate evidence for security and reliability claims: the scope and date of an assessment, known incidents, remediation status and actual recovery-test records. Do not label a backup as proven recoverable without a test or present a limited assessment as a blanket certification.

Repository transfer is only one part of handover. GitHub documents that associated webhooks, secrets and deploy keys remain with a transferred repository. An authorized transfer plan should therefore review integrations and access, not assume that moving the repository safely completes the whole transaction. [4]

Keep live credentials out of the general data room. Record the account and responsible owner, then plan any approved access transition through a separate controlled process. Review provider-specific transfer rules before promising that every account can simply be handed over.

Stage disclosure and review data-sharing decisions

Use an initial summary tier, a controlled diligence tier and a separately authorized closing or handover process. These are suggested disclosure stages, not a mandatory deal sequence. Restrict access to named participants with a legitimate review role and record what was shared.

An NDA can support confidentiality arrangements, but it does not by itself settle every data-protection, contractual or security question. Before sharing customer or employee records, have the responsible advisers review the purpose, applicable rules, necessary fields, recipients and safeguards.

The UK ICO's acquisition guidance specifically addresses diligence when a transaction changes or adds a data controller. It highlights original purposes, lawful basis, documentation, transparency and security. The retrieved guidance is marked under review following legislative changes; it is a UK-specific reference, not a universal permission to transfer customer data. [5]

Prefer a restricted, redacted copy where it meets the diligence need. Set access expiry and an exit process, while recognizing that revoking a link cannot retrieve a copy already downloaded. Avoid placing payment credentials, password lists or unnecessary personal details in a broadly accessible folder.

Worked example: turn a headline metric into a verifiable claim

Consider an invented subscription business reporting $11,000 ending MRR. Its proposed roll-forward is $10,000 opening MRR, plus $1,500 new MRR and $500 expansion, less $200 contraction and $800 churn. It has no reactivation or foreign-exchange movement in this example.

The arithmetic reaches $11,000, but arithmetic alone is not verification. Link each movement to the relevant subscription records, check the period and preserve the metric definitions. Separately reconcile invoices, processor activity and bank receipts; these measures need not equal ending MRR.

Now suppose the buyer finds an annual prepayment and a one-time onboarding invoice in a cash export. The response should explain their treatment and provide the bridge, not reclassify all receipts as recurring revenue. Under an explicitly monthly-normalized illustration, a $12,000 annual subscription contributes $1,000 monthly, while the separate onboarding charge does not become subscription MRR.

If one movement cannot be supported, add an open issue with an owner and resolution date. Correct the schedule transparently if the evidence changes it. This is an original preparation example, not a client result, accounting conclusion or indication of sale value.

Buy a readiness deliverable, not an exit promise

When hiring help, distinguish document organization, financial review, legal advice, technical diligence and transaction representation. A provider offering one does not automatically supply the others.

A bounded data-room readiness scope might include an inventory, agreed folder structure, metric-definition schedule, source mapping, gap register and handover readout. Specify the periods and systems included, client inputs, revision limits and exclusions. Confirm who can actually review accounting, legal or technical conclusions.

Ask for a sample deliverable showing how an unsupported claim is flagged. Avoid judging the work by the number of uploaded files or accepting a promise that a polished room will secure a particular valuation, buyer or closing date.

TechLithic operates HowToBuySaaS and offers related readiness services. That relationship does not change the evidence standard. Use the same checklist with any marketplace, adviser or provider, and verify the actual engagement terms before relying on claimed services.

Accept the room through an evidence walkthrough

Select a few material claims and ask someone other than the preparer to trace them through the room. The following are proposed acceptance checks:

• Can the reviewer locate the source, reporting period, definition and owner?
• Do financial and subscription schedules reproduce from the approved inputs, with differences explained?
• Are owned assets distinguished from licensed services and unresolved rights questions?
• Are technical dependencies, costs and founder-held processes visible?
• Are sensitive documents restricted to their approved disclosure stage?
• Does the gap register assign an owner and next action without concealing unresolved issues?
• Does the transfer register name assets, dependencies, approvals and post-transfer checks?

If the room fails those tests, resolve the evidence or scope the uncertainty before expanding disclosure. Do not rush a listing simply because the folder structure is complete.

The goal is a business story that can be checked and a handover that can be planned. For the other side of the decision, the SaaS buying due-diligence guide covers workflow, portability and operating fit.

Frequently asked questions