Cash is not revenue.

The process of converting bookings (and the subsequent cash from those bookings) into revenue within your business is called revenue recognition.

There are a set of rules and guidelines focused around how businesses calculate and recognize revenue, and if you report earnings to investors or other business stakeholders, they’ll want to see this. Revenue recognition is a critical piece of accounting for any business, and compliance with official standards is not optional!

For a SaaS or subscription business, revenue recognition can be complex, mainly because of the service-oriented nature of the product. While your customers may pay you a lump sum upfront for a year’s worth of usage, you won’t be able to categorize that entire amount of cash as revenue right away.

Fresh standards changes are approaching fast in the form of ASC 606 (and the jointly-developed IFRS 15), and now’s the perfect time to get compliant. Thankfully, the new ASC 606 standards simplify and clarify a lot of accounting principles when it comes to SaaS, so read on for an overview of what that means for you, and guidance on how you can implement it.

A recognized revenue chart in ChartMogul

What is ASC 606?

ASC 606 (and IFRS 15) are standards jointly issued by The Financial Accounting Standards Board (FASB) and the International Accounting Standards Board (IASB). The goal of this standard is to smooth over how contracted revenue is recognized across industries and around the world.

They both fall under US Generally Accepted Accounting Principles (GAAP).

“The standard provides a comprehensive, industry-neutral revenue recognition model intended to increase financial statement comparability across companies and industries and significantly reduce the complexity inherent in today’s revenue recognition guidance.”

(PWC)

For SaaS businesses specifically, ASC 606 will unify and simplify the approach to accounting. Whereas before a variety of interpretations of the guidelines existed, from 2018 we should see the end of such discrepancies, leaving less room for different interpretation — because, as mentioned earlier, compliance is with ASC 606 is not optional.

In practice, the guidelines are designed to ensure that companies recognize revenue at the time when goods and services are transferred to the customer, in an amount that’s proportionate to how much has been delivered at that point.

Who does ASC 606 apply to?

The new reporting framework applies to any situation where there is a contract for goods and services. If you’re a SaaS business, this definitely applies to you.

What’s the deadline for reporting?

If you’re a public company, December 15th 2017 is your deadline. All annual reporting after this date must comply with ASC 606. Because most reporting periods start January 1st, this effectively means that from January 1st 2018, it will affect your reporting.
If you’re a private company, the deadline is December 15th 2018 — so from January 1st 2019 you’ll need to be reporting in this way.

In reality, you probably want to implement this right now if you haven’t already. Investors and VCs are already looking for ASC 606-compliant metrics when evaluating businesses, and it’s always good to meet the needs of your investors.

How to recognize revenue under ASC 606

The model for revenue recognition under ASC 606 is outlined in 5 steps:

1. Identifying the contract with the customer

Customer contracts are reasonably straightforward for SaaS businesses — the cost and value exchange is defined upfront on the website, and there’s little deviance from the pre-defined structure. There’s one complexity here though: In the subscription world, the terms of a contract can change frequently. This includes:

When a customer upgrades (expands) their subscription
When a customer downgrades (contracts) their subscription
When an add-on is purchased, e.g. additional seats

These changes could mean creation of a separate contract, but in many cases it’s just a modification of the original.

2. Identifying the performance obligations

The term “performance obligations” may seem overly vague at first, but it basically just refers to the product (or service) you’re actually delivering to the customer, i.e. what are they getting for their money? The answer is most likely “a month’s worth of access to my service.”

In a non-SaaS world, performance obligations can be more complex as the customer is owning the product outright with a perpetual license. Because of this, performance obligations are a bigger focus upfront in the transaction.

3. Determining the transaction price

With the exception of some custom enterprise deals, the price of most SaaS contracts is a known quantity — it’s clearly defined upfront (on the pricing page). When we talk about transaction price here, we’re always talking about the net price.

There are a few small complexities to think about here though:

Discounts or rebates against the listed price
Discounts based on usage, i.e. the customer can move up to “volume” plans the more capacity they require, which results in them paying less per unit. The problem with this is that it’s not known upfront — you don’t know until the usage actually occurs.
Anything else that would cause the price to deviate from the standard listed price, such as reward or referral systems etc.

4. Allocating the transaction price to separate performance obligations

For SaaS, the product is delivered continually (“as a service”). This means that there aren’t really separate performance obligations — rather one continuous performance obligation.

What we do here is allocate a share of the billing value to each month that contains at least some part of the service period. The share of the value assigned to a month equals the share of the billing period that falls into this month.

When it comes to reporting the revenue, we only need to do that month-by-month. For internal reporting and analysis, it can be useful to calculate these on a more granular basis. For example, Revenue Recognition in ChartMogul does this.

5. Recognizing the revenue as each performance obligation is satisfied

This is the big one — this is where we actually get to turn our billings into recognized revenue! But before we do that, it’s worth looking at some criteria for revenue recognition.

Can I recognize the revenue yet?

Thre are actually five criteria for recognizing revenue as per ASC 606. If the prerequisites are not all met, you cannot recognize the billings as revenue.

Risks and rewards have been transferred from the seller to the buyer
The seller has no control over the goods sold
The collection of payment is reasonably assured
The amount of revenue can be reasonably measured
The costs of earning the revenue can be reasonably measured

In the example below, we’ll take you through a typical revenue recognition scenario for a SaaS business, and show how criteria apply in their context.

Deferred revenue

Any amount you’ve invoiced that has not yet been recognized is called deferred revenue, and is classed as a liability for the business. A common example of this is when a customer pays for a year’s service upfront, but you haven’t yet delivered the full year’s service.

For example:

I collect $12K today for a new annual subscription (new business)
My deferred revenue today is $12k
For each month following the purchase, my deferred revenue decreases by $1k as we recognize it over the course of the service period.

It’s important to correctly identify and categorize deferred revenue, because investors or auditors will want to take this into account as a liability when assessing your business — either for due diligence, credit-worthiness or other reasons.

Example revenue recognition scenario for SaaS

TIME OF PURCHASE, 23rd January

CONTEXT: The customer “ZenTicket” has signed up for a monthly subscription on your website, entered their credit card details and hit the confirm button. You get a notification from your billing system that the payment has been processed and the money has left the customer’s account.

Have the risks and rewards been transferred from the seller to the buyer? – ❌ NO, we haven’t transferred risks and rewards to the buyer until we’ve delivered them a month of service.
Does the seller have no control over the goods sold? – ❌ NO. We, the seller, have complete control over the goods we’re selling.
Is collection of payment reasonably assured? – ✅ YES, at least in the scenario where we’re accepting credit cards, we can be fairly certain (within reason) that we’ll collect the payment.
Can the amount of revenue be reasonably measured? – ❌ NO, we generally can’t measure because of the possibility of pro-rated refunds. If your business doesn’t do pro-rated refunds, you should be able to put a ✅ here.
Can the cost of earning the revenue be reasonably measured? – ✅ YES. in SaaS, the incremental cost to service a new customer is usually negligible, with the exception of huge volume deals or custom implementations.

CLOSING OF BOOKS, 31st January

CONTEXT: The customer “ZenTicket” has been actively using your product for 8 days since purchasing. It’s time to do the accounting for January.

Have the risks and rewards been transferred from the seller to the buyer? – ❌ NO (although this is partially fulfilled – for the part of the billing period that was in January)
Does the seller have no control over the goods sold? – ❌ NO (again, partially-fulfilled at this stage)
Is collection of payment reasonably assured? – ✅ YES
Can the amount of revenue be reasonably measured? – ❌ NO (partially-fulfilled)
Can the cost of earning the revenue be reasonably measured? – ✅ YES

CLOSING OF BOOKS, 28th February

CONTEXT: The customer “ZenTicket” has been using your product for over one month. They’ve recently been billed for their 2nd month of service.

Now that the customer is into their second month of service, can we recognize revenue from their first month?

Have the risks and rewards been transferred from the seller to the buyer? – ✅ YES
Does the seller have no control over the goods sold? – ✅ YES
Is collection of payment reasonably assured? – ✅ YES
Can the amount of revenue be reasonably measured? – ✅ YES
Can the cost of earning the revenue be reasonably measured? – ✅ YES

In this scenario, we can now recognize the revenue from the first month of service for this customer!

Tracking and analyzing recognized revenue

While most businesses will likely start out with a basic spreadsheet, there are a number of ways you can track revenue recognition that go beyond simple tables, and help make the connection between cashflow and revenue.

Revenue waterfalls

A revenue waterfall is useful to see how billing amounts turn into revenue over time. Due to different billing cycles, payment terms and other complexities, the amount billed in a single month may not all be recognized as revenue until some months later.

In summary

Revenue recognition for SaaS businesses is inherently complex, and depends on your specific revenue model. Fortunately for most businesses, ASC 606 brings a level of consistency and clarity that did not exist before in SaaS accounting — the Wild West is being tamed, and that’s a good thing for all of us.

Take the time to:

Understand the five-step model for ASC 606
Determine if any aspects of your customers contracts add complexity to your “performance obligations” (consulting fees, one-off setup costs, etc.)
Consider using a tool to automate at least part of the recognition process, save time and reduce risk.

If your investors and business stakeholders are not already expecting ASC 606-compliant revenue recognition, they will be before long. Now’s the time to get ahead of the deadline and get compliant!

The complete guide to SaaS revenue recognition with ASC 606