By: Billy Pritchard

What is Deferred Revenue?

If a software company offers its customers the ability to prepay on longer-term contracts, Deferred Revenue becomes an important consideration during the transaction process.  Generally, a prepayment from the customer creates a future liability for that company to service the customer over the life or term of the contract.  That future liability is commonly referred to as Deferred Revenue.

Accounting Issues with a Transaction

If a company is operating under a cash-basis accounting methodology, a prepaid annual contract would result in the company recognizing the full amount of that contract at the time of payment.  However, the cash-basis balance sheet would not reflect the continued liability of servicing that customer moving forward.  We often see founder led businesses operate under a cash-basis methodology, thus the Deferred Revenue concept is largely ignored.

In accrual-basis accounting, a prepaid annual contract is treated differently in a few ways.  First, the revenue would be recognized over the life of the contract or “as the revenue is earned.”  With most software contracts, this would result in a pro-rated monthly revenue recognition over the life of the contract.  Second, the prepaid annual contract would create the Deferred Revenue liability on the Balance Sheet.  Each month as the revenue is recognized, the Deferred Revenue liability would be reduced by the same amount.

Most private equity and strategic buyers operate under an accrual-based accounting methodology.  Therefore, when going through a transaction process, a Buyer & Seller can face challenges resulting from this accounting conversion at the time of closing and during the post-closing integration period. 

Deferred Revenue & Closing Impacts

Aside from these accounting nuances discussed above, Deferred Revenue can present proceeds impacts for the Seller at the closing table.  Depending on the timing of a prepaid contract in relation to a transaction close date, buyers can view those prepayments as penalizing to them – the Seller gets the benefit of 100% of the cash from that customer contract, yet the buyer is on the hook for the future service of that contract post close.  In most cases, this is why Buyers push to quantify the outstanding amount of Deferred Revenue and negotiate that impact into the transaction.  By treating Deferred Revenue as a liability in the transaction (either as true Indebtedness or in the Net Working Capital considerations), Buyers are able to offset some or all of that future liability through a reduction in Seller Proceeds or through a more favorable Net Working Capital structure for the buyer.

Key Considerations

We actively encourage Sellers to have a full understanding of any Deferred Revenue in their business before diving into detailed legal discussions.  While we generally are comfortable agreeing that there is some liability associated with servicing & supporting those customers moving forward, it is overly penalizing to a Seller to quantify that full prepayment amount as a true liability.  Good software businesses operate at attractive margins.  Therefore, $1 of revenue does not create $1 of future liability to service that customer.

A generally agreed up middle ground approach in software transactions is to look at the “Cost of Service” for those customers moving forward.  We look to work with Sellers to understand the Cost of Service by focusing on the true costs the buyer will incur post-closing (hosting, customer support, payment processing, etc.).  A software business that tracks and allocates expenses appropriately for its Gross Margin metrics is well positioned to support and defend a reduced Deferred Revenue liability.  Often times, this “Cost of Service” approach can save significant dollars at the closing table, which is why it is crucial for Sellers to have full awareness of Deferred Revenue when diving into transaction negotiations.

Below is an Illustrative Example on the various ways Deferred Revenue can impact a transaction from a closing proceeds perspective: