Arron Bennett, Founder of Bennett Financials
The letter of intent feels like the finish line. It isn't. It's the start of due diligence, the 45 to 90 days where a buyer checks everything you told them, and often finds a few things you didn't.
Technical founders tend to expect the code review and dread the finance questions. In practice, the code is rarely what moves the price. Messy revenue data, missing paperwork and a couple of large customers do that.
This post covers what buyers ask for, how to rebuild your MRR history in SQL before they do, and the findings that most often cut the price.
Key takeaways
- Due diligence checks revenue quality, the code and its ownership, contracts and people. Revenue is where most price cuts start.
- Have a month-by-month MRR rollforward ready: new, expansion, contraction and churn. It should tie to your billing system and your books.
- Every contractor and employee who wrote code should have signed an IP assignment. Missing ones get fixed before closing, at your cost.
- Customer concentration, deferred revenue and open-source licences are the usual surprises.
What is SaaS due diligence?
SaaS due diligence is the buyer's check of your business after you sign a letter of intent and before the deal closes. They verify revenue and retention, review the code and who owns it, read customer and vendor contracts, and look at security, infrastructure and people. Anything that doesn't match what you told them becomes a price cut, an escrow or a reason to walk away.
What financial data will buyers ask for?
Expect requests for monthly P&L and balance sheets for two to three years, a customer list with MRR by customer, an MRR rollforward, churn and retention by cohort, deferred revenue, and your billing system export. The buyer will rebuild your numbers from raw billing data. If their numbers don't match yours, they'll trust theirs.
That's why the most useful thing you can do before a sale is build the rollforward yourself. This query works on a table with one row per customer per month and their MRR that month (PostgreSQL):
-- MRR rollforward: new, expansion, contraction and churn by month
WITH m AS (
SELECT customer_id, month, mrr,
LAG(mrr) OVER (PARTITION BY customer_id ORDER BY month) AS prev_mrr,
LAG(month) OVER (PARTITION BY customer_id ORDER BY month) AS prev_month
FROM customer_mrr -- one row per customer per month with mrr >= 0
)
SELECT month,
SUM(CASE WHEN prev_mrr IS NULL OR prev_month < month - INTERVAL '1 month'
THEN mrr ELSE 0 END) AS new_mrr,
SUM(CASE WHEN prev_mrr > 0 AND mrr > prev_mrr
AND prev_month = month - INTERVAL '1 month'
THEN mrr - prev_mrr ELSE 0 END) AS expansion,
SUM(CASE WHEN prev_mrr > 0 AND mrr > 0 AND mrr < prev_mrr
AND prev_month = month - INTERVAL '1 month'
THEN mrr - prev_mrr ELSE 0 END) AS contraction,
SUM(CASE WHEN prev_mrr > 0 AND mrr = 0
AND prev_month = month - INTERVAL '1 month'
THEN -prev_mrr ELSE 0 END) AS churn,
SUM(mrr) AS ending_mrr
FROM m
GROUP BY month
ORDER BY month;
For this to count churn, a cancelled customer needs a row with mrr = 0 in the month after they leave. A returning customer after a gap shows as new MRR, which is how most buyers treat reactivations. Check that each month's opening MRR plus new, expansion, contraction and churn equals the ending MRR. Then check the totals tie to revenue in your books. If they don't, find out why before the buyer does.
What will buyers check in the code?
Less about style, more about risk. Expect questions on:
- Ownership. Who wrote the code, and did each of them sign an IP assignment?
- Open-source licences. A scan for copyleft licences that could force you to release your own code if you distribute it.
- Security. Past incidents, pen test results, access controls and how secrets are stored.
- Infrastructure. What it costs to run, what's documented, and whether it depends on one person's personal accounts.
- Bus factor. Whether the product survives if one engineer, often you, leaves after the sale.
Run a licence scan and list every person who's committed code before you list the company. Both are cheap to do early and slow to do mid-deal.
What findings cut the price?
Here's a hypothetical example. Every number is made up to show the mechanics.
A compliance-automation SaaS has $1.43 million of ARR. A buyer signs an LOI at 4.2 times ARR, about $6.0 million. Diligence finds three issues.
- Deferred revenue. Customers prepaid $310,000 for service still to be delivered. The buyer will have to deliver it without being paid again, so they treat it as a debt-like item and want it deducted from the price.
- IP assignments. Two former contract developers never signed one. The buyer makes signed assignments a condition of closing.
- Customer concentration. One customer is 14% of ARR, with a contract that renews in four months.
After negotiation, the founders agree to a $5.6 million price and pay a lawyer to track down the two contractors. They also lose a few weeks. The code review, which they'd worried about most, found nothing that changed the price.
I talk about the gap between a business that's an asset and one that's a job in this video. Buyers pay for the asset. Diligence is how they find out which one they're buying.
How do you prepare before you sell?
Start six to twelve months before you plan to sell. Build the MRR rollforward and reconcile it to your books. Collect signed IP assignments from everyone who has written code. Run a licence scan. Move infrastructure out of personal accounts. Write down how to deploy and run the product. Reduce your reliance on any one customer where you can. And know which items on your balance sheet a buyer will treat like debt. I've written a fuller guide on debt-like items in a business sale.
What should you do on Monday?
Run the rollforward query on your billing data and check it against last year's revenue in your books. Then list every person who has committed to your main repository and confirm you have a signed IP assignment for each. Those two checks catch the problems that most often cost founders money in diligence.
FAQ
How long does SaaS due diligence take?
Often 45 to 90 days from the signed LOI, longer if the data room is incomplete or the buyer finds issues that need fixing.
What is a data room?
A shared folder of documents buyers review during diligence: financials, contracts, cap table, IP assignments, security reports and policies.
Do buyers review the source code?
Usually, either directly or through a third-party code scan for licences, security and quality. Smaller buyers sometimes rely on a scan and a call with the lead engineer.
Why is deferred revenue treated as debt in a sale?
Because the buyer must deliver service customers have already paid for, without receiving that cash. Some buyers deduct the full amount and some only the cost to deliver it, so it's a point to negotiate.
Top comments (0)