Companies across the globe are intensively re-architecting their revenue recognition processes and policies as a result of the new ASC 606 guidance. Companies who sell their software by subscription (Software-as-a-Service or Saas) need to be particularly careful to ensure they are revising their policies appropriately for the new guidance. Below are a few scenarios and case studies that can help clarify some important considerations unique to SaaS companies.
Most financial professionals are now familiar with the ASC 606 five-step process:
Consider potential standard elements in SaaS arrangements: subscriptions services, implementation services, setup fees, service-level agreements, consulting services, and fixed- and volume-based fees. The expected accounting treatment for ASC 606 appears straightforward: ratable recognition for subscription elements and as-delivered recognition for nonrecurring elements. However, there are several subtle changes to the SaaS revenue recognition model that require consideration.
Summary of old and new jargon
The semantics of revenue recognition are changing. Here are some example changes in jargon (and abbreviation) that you can expect from your accountants and advisors:
Case study one—Contingent revenue from escalating subscription fees
What’s the accounting right now? Current accounting guidance precludes the recognition of revenue that is contingent upon future performance (often referred to as the “contingent cap”). If you have only legally earned $1,000 of revenue to date, then you can’t record more than $1,000 revenue. The future revenue is “contingent” upon the performance of the remainder of the contract. SaaS companies frequently run into contingent revenue when multi-year contracts have escalating prices.
For example, we sell a three-year subscription to a customer for annual fees of $10,000, $12,000, and $14,000. If not for the contingent revenue cap, revenue would be recognized evenly over the contract ($12,000 per year over three years). However, the existence of contingent revenue caps your revenue for year 1 at the $10,000 contractually earned. The remaining $2,000 of contingent revenue is not recognized under current accounting guidance.
What’s changing under ASC 606? Under ASC 606, we recognize $12,000 in revenue in the first year as the contingent revenue cap no longer applies: cash of $10,000, and a contract asset of $2,000. A contract asset is essentially money that we’ve earned but don’t have the right to invoice for yet. This is the opposite of a contract liability (formerly known as deferred revenue) that is money we’ve received, but haven’t earned yet. In this example, we’ve performed to earn the $2,000 of revenue, but won’t have the contractual right to invoice for these services until later.
Currently, many SaaS entities simply recognize revenue according to the annual contract amounts because of the contingent revenue rules. This simplification will go away and many entities may now have to begin reallocating their contract revenue between years.
Case study two—Contingent revenue from subscription and implementation
What’s the accounting right now? Contingent revenue is also common in the SaaS model when a company delivers both subscription and professional services. For example, we sell a one-year subscription to a customer for $12,000, payable monthly in advance. We also agree to provide an implementation service for $2,000 that we normally sell for $3,000. The total contract revenue is allocated to each deliverable based on their estimated selling price (VSOE or BESP today). The intention of this allocation is to ensure that all products within a contract have the same discount or premium for the estimated sales price. The following table illustrates the calculation of the allocation:
Without the contingent revenue cap, revenue recorded after one month of the subscription and the completion of the implementation services would be $3,733 ($11,200 / 12 months = $933, plus $2,800 for the implementation service). However, only $3,000 has been contractually earned at this point of the contract ($1,000 for one month of subscription and $2,000 for the implementation fee). Thus we will record $3,000 of revenue with $733 of unrecognized contingent revenue.
What’s changing under ASC 606? There is no change to the allocation under ASC 606. The distinct POBs are allocated contract revenue proportionate to their SSP, but the constraint of contingent revenue goes away under ASC 606. Under the new guidance, we will record $3,733 of revenue, with a corresponding $3,000 in cash and $733 of contract asset. The removal of the concept of contingent revenue may impact the timing of revenue recognition.
Case study three—Combining performance obligations
What’s the accounting right now? Currently, each deliverable with standalone value is accounted for separately. Consider again the example in Case 2 above, with the change that the implementation services will significantly integrate the subscription services into the customer’s existing systems on a turnkey basis.
Under current guidance, we have identical accounting to Case 2 above. We will record two deliverables with standalone value, a subscription and an implementation service. At the end of the first month, we have potential revenue of $3,733 and only $3,000 has been contractually earned. Therefore, we will record $3,000 of revenue with $733 of unrecognized contingent revenue.
What’s changing under ASC 606? There is an additional criterion for a “deliverable with standalone value” to be considered a “distinct POB” under ASC 606: the POB must be distinct from other POBs provided to the client. A common example used to demonstrate this concept is the construction of a home. When building a home, many of the individual parts that you can find down at the local hardware store (i.e., have standalone value): nails, paint, a kitchen sink and plenty of other things. However, under ASC 606, the goods and services are not distinct from other promises in the contract, as the overall promise is to transfer a combined item—the house.
So, what are some things that tell you that a POB isn’t distinct from other POBs? Each contract is different but some key indicators to consider include significant integrations, modifications, or customization, or high amounts of interdependencies between POBs. For SaaS subscriptions, a critical factor to consider is how much the customer can benefit from the software prior to implementation. Are your implementation services mainly configuration, training and setup, or do they require significant customization? These are highly judgmental and may change company by company.
Let’s assume that our implementation is so significant that we determine the integration and the subscription services are one combined POB in the contract. That $14,000 is going to be recognized over the combined term of 12 months.
Revenue recorded after one month of the subscription and the completion of the implementation services could potentially be $1,167 ($14,000 / 12 months). Because we’ve invoiced for $3,000 under the terms of the contract, we will also record a contract liability of $1,833 representing cash we’ve received but haven’t delivered the service. When combining professional services and subscription services into one POB, it is likely that revenue recognized will be slower under ASC 606.
Case study four—Setup (or upfront) fees
What’s the accounting right now? Let’s take the same example from Case 2, but instead of an implementation service, the $2,000 billing is a setup fee. These may be treated a few different ways in practice today, but it’s common for setup fees to be recognized ratably over the life of a customer. Say that customer’s life is four years. After one month, we’ll record $1,042 of revenue ($12,000 / 12 months for the subscription, and $2,000 / 48 months = $42 for the setup fee). Since we billed $3,000 for the subscription and the upfront fee, we will have recorded $1,958 of deferred revenue for the cash we’ve received but haven’t yet earned.
What’s changing under ASC 606? The key change under ASC 606 is that setup fees are no longer considered a down payment by the customer for services to be delivered over the entire customer life. Instead, upfront fees are considered part of the current contract and allocated to the POBs in the contract. In our case, the only POB is the subscription service. After one month, we’ll record $1,167 of revenue ($14,000 / 12 months), $3,000 of billings, and $1,833 of contract liability.
In summary, setup fees will be recognized proportionate to the revenue recognized under the contract rather than over the customer life. This will typically speed up revenue recognition for SaaS companies.
While the changes for SaaS companies may seem straightforward, there are many nuances to consider that may impact the timing and amounts of revenue recognition. In addition to the examples above, other significant issues you should consider include:
- Options to acquire future goods or services that may provide material rights to customers, such as opt-ins, opt-outs, discounts on future purchases;
- Significant setup fees that provide material rights to customers;
- Contracts with variable consideration;
- Contract modifications; and
- Capitalization and amortization of contract origination costs, such as sales commissions.
ASC 606 is breaking new ground in many ways. These case studies can help clarify some of the important considerations unique to SaaS companies and raise your proficiency both in understanding and in what internal questions need to be asked.
Jacob Sperry is a Director in Connor Group's Technical Accounting and IPO Practice. Jagan Reddy is SVP of RevPro at Zuora.