I wouldn’t recognise revenue if it slapped me in the face
There are any number of jokes about start-up companies that are pre-revenue: so early stage that they have neither products nor customers. A particular favourite of mine is hearing a company described as “unencumbered by revenue recognition problems”.
The difference between Orders (a commitment to buy a product or service at a defined price on defined terms) and Sales (the shipment of the product or
the provision of the service in compliance with the agreed terms) is pretty
clear and understood. But a Sale might be disconnected from the Revenue (the point when the sale is taken into the company’s books, after the product has been delivered and services provided). For example, if an airline sells you a plane ticket the revenue is likely to be only recognised once you have flown, even if the airline sold you the ticket some time previously.
The issue of revenue recognition came to prominence in the 1990s with US software companies, especially those listed on the NASDAQ market. Being creative with deal terms enabled revenues and earnings to be flattered — earnings management it was called — to meet market expectations of the company’s progress. If a specialist software licence costs for example $100 per seat per month, it was easy enough to sell an annual licence at the discounted price of $1,000 and benefit from $1,000 of sales, rather than just $100. This is terrible for the poor shareholders, who really had no idea how badly or well the company they had invested in was actually doing. At the heyday of ‘earnings management’, there were bundles (including services and products into a single offering at one price), buyouts (one-off licence fees in lieu of a rental), overstocks (deliberately over-ordering, then returning much of the order in the next fiscal year for credit); even revenue swaps (two companies licensing each other software neither had any intention of using).
Customers learnt that the best prices could be achieved at the end of the
quarter, as suppliers became desperate to hit targets and incentives
proliferated. One VP sales liked to joke that at the end of the quarter you
could qualify a sales lead by asking the prospect just two questions: “Do
you have $100,000?” And the second question, “do you have it on you?”. The CFO of one well-known large software company was phoned on the last day of the quarter by an analyst to hear how the quarter had panned out. “Too early to say”, was the reply.
So the US authorities worked hard to bring some order and structure to
revenue recognition, placing rules around when revenue could be recognised and when it had be counted as ‘Deferred Revenue’, a liability on the balance sheet. This has the effect of separating the point in time when the sale is made and the profit occurs.
(It’s perhaps not immediately obvious why Deferred Revenue is a liability,
so here’s what’s happening on the Balance Sheet: when a sale is made, Assets increase by the value of the transaction (either Cash or Accounts
Receivable) and Retained Earnings increased by the profit from the sale. If
the revenue cannot be recognised yet, Assets still increase in the same way
but Deferred Revenue is credited instead of Retained Earnings. When the
revenue is recognised, the amount is moved from Deferred Revenue To Retained Earnings and the profit is thus made. Deferred Revenue can also be
considered the equivalent of negative Work in Progress, if that helps).
All this might seem less than relevant to most companies, but it can come
back to bite when a company is sold. Buyers may want financial accounts and reports restated to reflect international revenue recognition standards,
which may delay the transaction, incur costs or even result in a reduction
in the company’s valuation.
So here are some best practices on revenue recognition, which apply to every company, software or not:
- Have a price book, with product descriptions and prices and keep it up to
date. It will keep the sales team focused on selling what the company has
available for sale and on what terms - If a sale happens at a different (lower) price, record this as a discount
off the book price - Recognise product revenue when the product has been shipped, installed (if relevant) and accepted (if relevant) by the customer, which may not be when the invoice has been raised
- Recognise service and maintenance revenue as and when it is performed.
This can be approximate: if it’s a three month project, for example, you
might want to recognise a third each month, especially if it’s not easy to
say how much work is actually done in each month. Again, the revenue
recognition is likely to take place at a different time to the invoice.
Most importantly, have a price book. It’ll make revenue recognition much
more straightforward and help the sales team achieve higher margins.
