SaaS accounting and finance are the tools you need to invest your cash for growth. Here's a guide to the fundamentals, including your crucial SaaS metrics in the finance world - bookings, revenue, collections, etc.Read More
Revenue Recognition and SaaS Accounting for Subscription Businesses
Patrick Campbell Nov 4 2015
The moment cash lands in your bank account from a customer, it can be very tempting to immediately update your revenue line in your accounts with all that sweet, sweet cash.
But cash isn’t revenue, and treating them the same could be fatal for your business. You might get cash up-front, but you don’t get revenue until you've earned it. Until then it is a liability — money that your customer can ask for back at any point if you don’t deliver your service. If you’ve spent their money but haven't delivered their service, it’ll quickly spell the end of your SaaS business.
This is the concept of revenue recognition, and it’s absolutely critical for every SaaS founder to understand.
Here we’ll take you through revenue recognition, how it applies to SaaS companies, some of the complications that are unique to subscription businesses, and what the future looks like for SaaS and revenue recognition.
1. What is Revenue Recognition?
2. Revenue Recognition for SaaS Accounting: Key Complications
3. The Further Complications of Revenue Recognition in SaaS
4. The Future of Revenue Recognition
What is Revenue Recognition?
The basic idea of revenue recognition is this: no matter when a customer's cash arrives in your bank account, you don’t count it as revenue until you have delivered the product or service that it paid for.
Revenue recognition is a generally accepted accounting principle (GAAP) and a fundamental aspect of the accrual basis of SaaS accounting — you should only record revenue when you have completed a revenue generating process.
In many businesses the difference between the cash collection and the revenue recognition is subtle, as you would deliver the product when the customer pays for it and that transaction is the revenue generating process.
Consider the traditional software model. If you wanted to buy a copy of a CRM product 10 years ago, you would buy a physical disk with the software on, install on your computer and away you’d go, until the company brought out an updated version next year.
The Financial Accounting Standards Board (FASB) has codified specific accounting standards for recognizing revenue for software companies. The guidance states that two criteria must be satisfied:
The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
It is feasible for the customer to either run the software on their own hardware or contract with another party unrelated to the vendor to host the software.
Because the customer can take possession of the software immediately, and they are allowed to run it on their own hardware, the CRM company can recognize the revenue immediately. If they brought out their new software in January, and you purchased and received it in January, the CRM company would book the sale and recognize the revenue in the same month.
So far, so straightforward.
If your company sells a product that is a one-time deal, like buying candy in the store, then you will be able to recognize your revenue in the simplest manner. You can recognize that revenue as soon as you can be confident that you’ll get paid for your product, in the same accounting period as when you provided the product.
But even with this simple version, it’s vital that you understand the difference between cash and revenue. Even if the transaction take place immediately, the two are not the same. Mistaking cash with revenue is the biggest mistake SaaS companies make when transitioning from SaaS metrics to GAAP (generally accepted accounting principles) metrics.
Revenue Recognition for SaaS Accounting: Key Complications
However, SaaS companies often can’t satisfy those FASB criteria. Your customers never take possession of the software during their subscription period, and it’s certainly not feasible for them to run the software on their own machines. The whole point of SaaS is that you host the software for them, giving them constant 24/7/365 access to the latest version of the program/software.
This means that SaaS falls between the gaps of GAAP. There aren’t any specific accounting standards for SaaS businesses.
That doesn’t mean you can ignore it, or make it up as you go along though. Revenue recognition is vital to correctly determine the financial health of your company, and you still need to recognize your revenue only when you earn it.
For accounting purposes, SaaS subscription revenues should be considered 'non-refundable up-front fees’. This means that, according to the SEC, revenue should not be recognized until:
“Persuasive evidence of an arrangement exists.”
“The seller’s price to the buyer is fixed or determinable.”
“Collectibility is reasonably assured.”
“Delivery has occurred or services have been rendered.”
The terms of most SaaS companies satisfy the first three conditions. The fact that a customer has signed up to your service, even if it’s through a self-serve product with no actual contract, is evidence that an arrangement exists. The selling price of your service, either monthly or yearly is fixed, and as you will usually collect the subscriptions fees up-front, your collectibility is typically assured.
This leaves only the delivery of the service. For SaaS companies, this means recognizing revenue on a straight-line basis. If you’ve got a yearly plan, then, though you’ll get all that sweet, sweet cash the moment the customer clicks ‘confirm’, you don’t get to recognize it as revenue at that instant.
Why? You have to earn it. You earn it by delivering your service, and you deliver your service throughout their entire plan, from day 1 to day 365. If you book a customer on your annual plan of $10,000, then you’ll recognize $833.33 each month, or $27.40 each day:
What happens to the rest of the money before you get to recognize it? Until revenue is recognized, any advance (cash that might have been paid up-front) is considered a liability, and marked as deferred revenue. This means that though you might have the cash in the bank, you haven’t earned it though delivery of the product or service.
Recognizing revenue on a straight-line basis, not all in one go, is how most revenue is going to be recognized for SaaS services. This is where a number of SaaS companies trip up, failing to realize that they have to recognize the revenue for a service incrementally throughout the time window for that service.
You earn the revenue for delivering your service every day that you deliver it to your customer. If you claim all of the booking and up-front payment as revenue immediately, and then spend the cash, you’re liable for any problems with the service. If you don’t deliver your service as you agreed to do, your customers can come asking for their money back — which you no longer have, leading to serious cash flows problems and probably dissolution of your business entity.
The Further Complications of Revenue Recognition in SaaS
The above example shows a straightforward SaaS business — one with simple yearly or monthly plans as the only revenue stream. But some SaaS companies, particularly those significantly geared towards the enterprise market, offer additional services in multi-element arrangements.
Revenue recognition in SaaS gets more complicated when you factor in these bundled features:
These might be optional, like consultancy services, or they might be obligatory, like a set-up fee. How the revenue from these services will be recognized will be determined by whether any of these services have standalone value, and are considered separate units of accounting.
For instance, a SaaS company charges $10,000 annually for their CRM software, and each customer has to pay an extra $5,000 one-off fee for set-up and customization services. If the company doesn’t offer these as separate services and they are obligatory for any customer who is starting to use their CRM software, then they aren’t separate units of accounting. Though they might be packaged and priced separately, as far as revenue goes, they are all part of the same service.
Even though the set-up and customization would be delivered early on in the plan, as they are not a separate unit of accounting they would be recognized over the lifetime of the whole plan, along with the CRM software.
What if the SaaS company does offer these services separately? Then they are considered separate units of accounting, and would be recognized differently from the main CRM plan.
Say the SaaS company also offers a 6-month consulting service for $5,000. It is offered on a standalone basis, regardless of whether the customer is using the CRM. This would be a separate unit of accounting, even if it was sold along with the CRM software. The revenue would be recognized on its own straight-line basis:
It usually makes sense to recognize on this straight-line basis, spreading the revenue out throughout the delivery period of the service. However, you can recognize using a different pattern if that better describes how the service or product is delivered.
Looking at how each of the services you provide is delivered, and whether they are standalone services with their own intrinsic value, is one of the most important parts of revenue recognition for sophisticated SaaS businesses. If you are offering set-up or consultancy services, then these will also need to be recognized over the lifetime of the service as you deliver them and earn the revenue.
Trying to count the cash from these as revenue immediately, or not as its actually earned will lead you to making serious mistakes in your financial reporting, leaving you thinking you have more money than you do and leading you to spend money that isn’t yours. The opposite is also true — not understanding that you can recognize different services over different time frames could lead to leaving money on the table, and not investing cash that is rightfully yours.
Either way, by not understanding revenue recognition, you’re not allowing your company to grow to its full potential.
The Future of Revenue Recognition
This is how revenue is recognized at the moment. However, partly due to the confusion over SaaS companies and the subscription economy (and partly due to some of the more aggressive ways companies have used the nuances of revenue recognition in the past), the governing bodies like the FASB and its international counterpart, the IASB, are developing a converged revenue recognition standard to get everyone on the same page.
5-step process for SaaS-Accounting-Friendly Revenue Recognition
After December 16, 2016, a new 5-step process for recognizing revenue will apply for public companies (nonpublic can adopt the standard then, or defer for another year):
Identify the contract with a customer
This doesn’t have to be a written contract. It can be a verbal contract or implied through your terms and conditions that your customer’s agree to when they sign up.
Identify the separate performance obligations in the contract
A performance obligation is a distinct service that your customer can benefit from on its own, or when used with other services you provide, and is separate from other goods or services in the contract.
Determine the transaction price
How much you expect to receive for your entire service.
Allocate the transaction price to the separate performance obligations in the contract
You will make estimates of stand-alone selling prices for each of the performance obligations in your contract.
Recognize revenue when (or as) the entity satisfies
Revenue is then recognized over time for each of the performance obligations.
So you set your contract with a customer, separate out different services you will provide, decide the total price for your service, parcel this out to price your individual services, and then recognize each of those revenue streams separately as you deliver each of the separate services.
By setting out specific steps that have to be completed to recognize revenue properly, it means that everyone in the company has to understand how their decisions implicate how revenue is recognized. Sales, operations, marketing, and management will all have to make specific judgments on their contracts, obligations, and delivery and feed these into the accounting department so they know exactly how the revenue will be recognized.
Don’t wait around for the new standard to be implemented — you can start preparing now. In doing so you’ll recognize your revenue more effectively and accurately, increase transparency across the board, and make your company run more smoothly. Getting your finances in order is one of the most important things you can do to keep your company on track for growth.
The whole idea of the company is to provide a service and make revenue, so if everyone understands how what they do feeds into the ultimate revenue decisions then you can gear everything in your business to this ultimate aim.
Revenue recognition is a central element that separates your SaaS accounting process from SaaS revenue. Whereas you might update your MRR and ARR as soon as a new customer signs on, and you get their cash up-front, you can’t update your recognized revenue until you’ve delivered your service.
This distinction can trip up a lot of people in SaaS, who don’t realize that a new account increasing ARR by $20,000 does not equal $20,000 in revenue there and then.
But understanding your finances and knowing exactly when you can recognize your revenue allows you to know the exact foundations of your business and better position yourself for growth. By knowing exactly where you stand financially, you can start to plan your future expansion and re-invest that money back into your company, safe in the knowledge that you’ve truly earned that growth.
By Patrick Campbell
Founder & CEO of ProfitWell, the software for helping subscription companies with their monetization and retention strategies, as well as providing free turnkey subscription financial metrics for over 20,000 companies. Prior to ProfitWell Patrick led Strategic Initiatives for Boston-based Gemvara and was an Economist at Google and the US Intelligence community.