The ninth law in Bessemer’s Top 10 Computing Laws is all about accounting and how to recognize revenue. In the traditional software business, the software license revenue is recognized at the time of delivery, while in the SaaS world the scenario is very different. I mentioned in my prior posts that I have been/I still am in enterprise software sales (besides SaaS), and have to deal with both of these models. Let’s review this law in greater detail what it means for a SaaS company. In my prior blog entries about Bessemer Top 10 Cloud Computing Laws and the Business Model Canvas, I have opened the financial side of a SaaS vendor, but in this case we will be looking at how the overall revenue recognition is seen in the SaaS world.
Law #9: Mind the GAAP! Cloud accounting is all about matching revenue and costs to consumption…well, except for professional services!
With enterprise software, revenue is recognized at the time of the delivery (like for example with a CD/DVD) and the software vendor can immediately have that sales in the income statement. This is both good and bad for software vendors. The good side of the thing is that large deals can fund further development and some of the money can be funneled back into marketing. The bad thing is that large deals can also put the software sales organization to sleep, almost paralyzing the entire organization. I have been part of this so many times so this statement is based on my own experience. The other negative side of these large deals is that enterprise software sales is very cyclical with long sales cycles: A software company might be going without deals for months and then gets a large deal that kind of saves the entire year. Yet again, I have personal experiences of this as well. In the enterprise software deal, the support/maintenance revenue is typically recognized on monthly basis based on the length of the maintenance contract. So if you have an annual contract, the support/maintenance will be recognized each month for the entire year. In similar manner, services revenue is recognized after delivery of the service and the common billing cycle is either biweekly or on a monthly basis.
Let’s look at the revenue recognition of cloud computing revenue. There are typically two types of revenue streams in a cloud computing: subscription revenue and professional service revenue. The subscription revenue is recognized based on consumption, whereby the SaaS vendor can start recognizing the revenue when the end user organization starts using the software. What is very different in the SaaS world when compared with the enterprise software world is the revenue recognition of professional services. Based on best practices and audits by the top for auditing companies, revenue recognition of professional services should be recognized with the length of the contract, and some recommendations say that even over the lifetime of the customer. The practical amortization time for these types of contracts is 5-6 years if the customer churn is reasonable. Within the GAAP (Generally Accepted Accounting Principles) world, the SaaS vendor should match revenue with the corresponding costs and this might not be the case in this kind of 5-6 year amortization scenario.
Also, there is an exception to any rule in life. In cases where the software company trains the end user client either 3 months before the delivery of the solution or after the renewal date of the contract, this revenue can be considered as it can be said not be tied or associated with the delivery of the solution. This rule of 3 months seems to have been approved by the top 4 auditing companies as best practices based on the Bessemer blog entry.
The final mention from Bessemer is to exclude deferred revenue from Quick Ratio calculations as this is booked as liability in the balance sheet. Quick Ratio is calculated by dividing total assets with total liabilities. This ratio shows how quickly the company can cover the liabilities with cash or quick assets that can be quickly liquidated. Another term “Acid test” is when you add up cash or cash equivalent, marketable securities and accounts receivable and divide these with current liabilities you get a number that shows you whether you can cover you current liabilities… when the ratio is 1 or better it is considered to be a feasible ratio. Less than 1, you have more debt that you can currently cover.
This makes sense to me as it is revenue that the company (excluding customer churn) will recognize throughout the lifetime of the contract whereby the liability /deferred revenue gets smaller by being moved to income statement whenever the revenue is recognized. Obviously in high growth cases, the SaaS company deferred revenue should only grow as new contracts are signed. This suggestion is specifically important for companies looking for venture funding to avoid financial covenants. Getting paid from customer in advance is a good thing and should not be seen as liability. Let’s review how this law impacts the Business Model Canvas.
Summary of our findings in respect to Business Model Canvas
This law has a direct impact on both Cost Structure (CS) and Revenue Streams (RS) as the law has to do with money and how it is recognized. When you review the Business Model Canvas, the two building blocks are side by side to remind us that the costs of running and serving the client needs to be aligned with the revenues that are generated from the end user client. The only big thing in my mind, and slightly surprising, is the need to recognize the revenue from professional services for the entire lifetime (or 5-6 years) of the contract. In the old software licensing world, this type of thinking would be out of question and the invoice for the entire install is expected to be paid and recognized at the very latest when the work has been performed. Not so in the SaaS model. Some SaaS vendors have made their contracts shorter to be able to get around this issue, but if the entire lifetime of the client is taken as foundation, it really does not matter if the contract is split in my mind.
I wonder how many starting ISVs recognize this and know this rule. Phil Wainewright discusses of this issue in his blog entry “Auditors backtrack on SaaS revenue recognition” by giving the example of Taleo’s restatement of financials that made auditors nervous in the SaaS field. The Taleo case was widely reported by Reuter as well as other news sources such as Barron.
There is a set of blog entries by Jeffrey Werner of questions that were posted after a web-cast concerning revenue recognition. These five blog entries and topics were as follows:
Blog 2 – Estimated Selling Price
Blog 4 – Stand-Alone Value for Delivered and Undelivered Items – Part 1
Blog 5 – Stand-Alone Value – Delivered and Undelivered Items -Part 2
These five blog entries demonstrate extremely well that the area of revenue recognition is not easy and there are lots of possibilities to different interpretation on this issue. Also, based on the information in the blogs, one of the key things that seem to be important is whether the item that has a price tag is needed as part of the SaaS solution delivery. If so, it is considered as part of the revenue recognition rules set for SaaS delivery. If not, then one can always argue that it is a separate item that can be recognized at delivery. This has also been the case in traditional software delivery. Auditors have always wanted to know if something that was delivered was needed for the software to function properly and in these cases it was about tax laws (could be even state specific in the US) that kicked in some scenarios. What I have learned from the past is to talk to auditors to make sure that you do everything according to the book.
The purpose of this blog entry is to demonstrate that there is still lots of room for best practices and only time will tell how auditors and practitioners will interpret the accounting rules/revenue recognition of different types of revenue in a SaaS delivery.
I believe one of the most important task when moving from traditional business model to SaaS is to develope an indicator (kind of base for all other indicators or business driver) to guide all business decisions to be made whether they are strategic or not. Revenues come in relatively longer period than costs are paid out. This is why traditional indicators such as EBITDA, revenues, Cash flow etc. do not present how business model is operating.
For example our business driver is recurring revenues/fixed costs. This means that every investment should either create more recurring revenues or reduce fixed costs. For example investment to CRM system might make our customer service better (longer customer relations> more recurring revenue) and at the same time streamline our support service processes (reduced fixed costs).
When business model is more complicated it can be quite difficult to find a proper driver indicator, but definitely everyone should put enough effort to generate an own one when starting a Saas model software business.