This article focuses on five practical considerations as to how the new revenue standard ASC 606 will apply to technology companies, specifically those that sell software.
In future posts we'll take a deeper dive into each of these topics.
#1 - Licenses: Timing of revenue recognition depends on nature of license.
For the most part, the new standard does away with all of the industry-specific guidance that existed under the old guidance. Still though, the technology industry receives a head nod of sorts when it comes to licenses, as ASC 606 dedicates a specific section to licenses.
Right to use vs. Right to access
Under the license guidance, the distinction between whether the customer is purchasing the right to use the license or the right to access the license is an important one, as it impacts timing of revenue recognition.
Right to use licenses will be recognized at the point-in-time in which control transfers to the customer (similar to perpetual licenses under the existing guidance).
On the other hand, if your customer is purchasing a right to access the license, you’ll recognize revenue over the license period.
The Board is currently drafting a final ASU (Identifying Performance Obligations and Licensing) which distinguished intellectual property between functional and symbolic, and this distinction should be taken into consideration when determining the nature of the license.
Functional vs Symbolic IP
Functional IP is defined as intellectual property that has significant standalone functionality, such as the ability to process a transaction, perform a function or task, or be played or aired.
Functional IP is indicative of a license that should be recognized at a point-in-time.
Symbolic IP is defined as intellectual property that does not have significant standalone functionality. Substantially all of the utility of symbolic intellectual property is derived from its association with the entity’s past or ongoing activities, including its ordinary business activities.
Symbolic IP is indicative of a license that should be recognized over time.
#2 - Specified upgrades will no longer hold up revenue recognition.
You might have just sold a software license to a customer for $1M, and you might have also promised to upgrade the customer to the newest version coming out next year for free. Under existing GAAP, you're not going to recognize a dollar on that sale until the customer has upgraded (assuming of course that you fall in the most likely scenario of not having a history of standalone sales on the specified upgrade).
Under the new guidance, transaction price is to be allocated amongst performance obligations based on standalone selling price, which is the price a promised good or service would be sold separately to a customer.
But here's the kicker:
If standalone selling price is not directly observable, you can estimate the standalone selling price.
Three methods are noted as being suitable for estimating standalone selling price.
- Adjusted market assessment approach
- Expected cost plus margin approach
- Residual approach
The residual approach can only be used if the promised good or service is sold to different customers for a broad range of amounts, or if a price has yet to be established for the promised good or service. The latter condition will apply to the majority of specified upgrades.
#3 - In many cases, post-contract support (PCS) will no longer be viewed as a single component.
24x7 customer support; when-and-if-available enhancements; bug fixes.
Each of these are typical of the kinds of activities that are recognized as a single component known as post-contract support (AKA maintenance) under existing GAAP.
The concept of post-contract support will soon vanish. ASC 606 doesn't explicitly define post-contract support as a single performance obligation, so you'll instead need to consider whether these post-contract support activities should be broken up into separate performance obligations.
So long, post-contract support. What a long, strange trip it's been.
It gets a slightly more convoluted when you consider that each of these components may not even be performance obligations to be recognized as revenue. A company could determine that bug fixes, for example, is merely an activity to ensure that the software complies with agreed-upon specifications, in which case it may be considered a non-revenue component of a warranty and should be accounted for under Suptopic 460-10 on Guarantees.
Bottom line: the term post-contract support will soon fall by the wayside much like curglaff, beef-witted, and snout-fair have in centuries past.
#4 - Extended payment terms will no longer prevent revenue recognition; you'll just have to present-value it.
You ever sold software with a 6-month implementation to go-live, at which point payments will become due in equal installments over the next year and a half?
While the concept of extended payment terms wasn't stated under the general existing revenue guidance; the software-specific ASC 985-605, Software: Revenue Recognition explicitly called it out.
And under that existing guidance, you probably would've had to put your auditor in a choke hold to recognize that revenue, as the fees likely wouldn't have been considered fixed or determinable.
Good news for you (better news for your auditor), you can recognize this revenue now. You just have to consider whether a signfiicant financing component exists to the arrangement.
In general, you should recognize an amount as revenue reflective of what your customer would've paid for in cold, hard cash.
ASC 606 doesn't explicitly reference whether to include as consideration the brief case that may have carried the cash, so use your best judgment there.
#5 - There are two ways to account for renewal options offered at a discount.
If your company offers discounted renewal options, there's a new framework in place for allocating the transaction price to the renewal option. If offered at a discount, these will likely be considered material rights to be identified as a separate performance obligation.
If not directly observable, you'll need to estimate what the option would be sold at on a standalone basis, which takes into account the discount the customer will receive upon renewal as well as the liklihood the customer will renew.
But under the new standard, there's another route you could take.
The practical alternative - which you can choose to elect - will allow you to gross up the revenue to be recognized over the expected renewal periods in your initial transaction price. Essentially, you would assume the option will be exercised, and include the additional incremental goods or services in the original transaction price to be allocated over the contract period (which includes the assumed renewal periods). Check out Illustration 6-1 on page 82 of E&Y's Revenue From Contracts With Customers for an example of how this works in practice.