Most purchase price conversations in software deals happen at the level of an EBITDA multiple. The number that actually lands in the seller's bank account is determined somewhere else, in the definitions section of the purchase agreement, and one of the lines that moves it most is deferred revenue. It rarely gets the attention in early diligence that it gets in the final week of negotiation, which is exactly the wrong way around.
For a lower middle-market software business that bills annually in advance, deferred revenue can be one of the largest liabilities on the balance sheet. How it is treated, as working capital, as debt, or as something in between, can shift the effective price by a meaningful percentage of enterprise value. Buyers who have not formed a view on it before the LOI usually end up negotiating it from a weaker position after.
What deferred revenue actually represents to a buyer
When a customer pays an annual maintenance or subscription invoice up front, the seller receives the cash and records a liability for the service still owed. At closing, the buyer inherits that obligation. For the remaining months of each contract, the buyer's team will support the customer, run the servers, and ship the updates, and it will receive no new cash for doing so because the seller already collected it.
That is the core of the argument. The seller has been paid for work the buyer will perform. Whether that should reduce the purchase price, and by how much, is where the two sides predictably disagree.
The three common treatments
Treated as working capital. Deferred revenue stays inside the net working capital definition and flows through the peg. If the peg is set on a normalized trailing average, the buyer is protected only against changes in the balance, not against the balance itself. Sellers generally prefer this treatment because it is the least visible.
Treated as debt-like, in full. The entire balance is deducted from enterprise value at closing, dollar for dollar. Buyers sometimes open with this position, but it tends to overstate the cost, because the buyer does not have to refund the cash. It only has to deliver the service, which costs far less than the revenue collected.
Treated as debt-like, at cost to service. The balance is deducted at the estimated cost of fulfilling the obligation, usually the relevant cost of revenue plus a portion of support and hosting, rather than at face value. This is often where reasonable parties land, and it is the treatment that most rewards having done the underlying analysis before the negotiation starts.
Where the number can move without anyone noticing
Deferred revenue is sensitive to billing behavior, and billing behavior is something a seller controls in the months before a sale. A few patterns are worth testing directly.
- Billing calendar shifts. If renewals historically concentrated in one quarter and the closing date falls just after that quarter, the balance at close will be high and the cash will already have gone to the seller. Map billings by month for at least two years and see where the close date falls in the cycle.
- Pulled-forward or multi-year billing. Offering customers a discount to prepay two or three years in the run-up to a sale converts future cash into present cash for the seller and leaves the buyer servicing the contracts for free. Ask for any invoices covering more than twelve months and any recent changes to payment terms.
- Discounts to accelerate collections. A spike in early-payment discounts can make cash conversion look excellent in the last twelve months while depressing the revenue the buyer will actually recognize going forward.
- Revenue recognition inconsistencies. Smaller businesses sometimes recognize implementation or license revenue up front when it should be deferred, or the reverse. A recognition policy that changed recently deserves a line-by-line look at a sample of contracts.
The cash versus GAAP question in the model
Deferred revenue also shows up in the model itself, and it is easy to get wrong. A growing software business that bills in advance will usually generate more cash than EBITDA, because billings run ahead of recognized revenue. That favorable working capital dynamic is real, but it is a function of growth. If growth slows after close, the cash benefit shrinks or reverses, and a model that holds the historical cash conversion ratio flat will overstate free cash flow and debt capacity.
The fix is simple: model billings, collections, and revenue recognition as separate lines, drive deferred revenue from them, and let cash conversion fall out of the assumptions rather than hard-coding it. It adds a few rows and removes a common source of optimism in LBO returns.
The acquisition accounting wrinkle
Buyers reporting under US GAAP should also be aware that current accounting standards generally carry acquired contract liabilities forward at their existing value, which removed much of the old "deferred revenue haircut" that used to depress reported revenue after an acquisition. The practical point is that post-close reported revenue should now track the target's historical pattern more closely, but lenders and investors reading the first year of combined financials should still be walked through how the acquired balance was handled. Confirm the treatment with your accountants early rather than discovering it in the first board pack.
What to do before the LOI
- Get monthly billings and the deferred revenue roll-forward for at least twenty-four months, reconciled to the balance sheet.
- Estimate the cost to service the balance: hosting, support headcount, and the share of engineering that maintains existing functionality.
- Model the balance at your expected close date, not at the last reported month end, using the billing calendar.
- Decide your position on treatment and put it in the LOI, even in a single sentence, so it is part of the price discussion rather than a surprise in the purchase agreement.
Deferred revenue is not a trick and it is not a reason to walk away from a good business. It is simply a part of the price that gets set late, by default, unless someone decides to set it early. In lower middle-market software deals, that someone should be the buyer.