Common ASC 606 Issues: Software Entities
Software entities face unique issues as they apply ASC 606. Gain a deeper understanding of how to navigate these key issues.
In 2018, the Accounting Standards Codification (ASC) Topic 606 became effective for all public companies. This major overhaul of revenue recognition has affected almost every industry, and software companies are no exception. This article provides a quick review of the key issues software companies must consider when applying the standard.
The AICPA and the Big Four accounting firms have written industry-specific revenue recognition guides that may be useful to software companies. For direct access to selected guides, see:
- AICPA: Audit & Accounting Guide—Revenue Recognition
- EY: Technical Line: How the revenue standard affects technology entities
- KPMG: Revenue for Software and SaaS—Q&A
- PWC: In depth: Revenue: Implementation in the software sector
For each of the issues we examine below, we also provide references to related RevenueHub articles that dig deeper into those issues. See our RevenueHub article, The Five-Step Method, for more general information.
1. Determining Whether a License of IP is Distinct within a Contract
The second step in the ASC 606 revenue-recognition model is to identify the separate performance obligations within a contract. Each promised good or service, or bundle of related goods or services, must meet the following two criteria to be considered a distinct obligation: (1) the customer can derive benefit from the offering either on its own or with readily available resources, and (2) the offering is able to be separated from the other offerings in the contract. The first requirement determines if the offering is capable of being distinct, while the second determines if the offering is distinct within the context of the contract.
In hosting, software as a service (SaaS), and hybrid-cloud arrangements, a software license exists as a distinct performance obligation if the licensee can derive economic benefit independent of the other products or services within the contract. Under ASC 606, the licensing implementation guidance is not applicable in a SaaS arrangement. According to the KPMG firm guide, SaaS arrangements are accounted for as service obligations, not as a transfer of a license to intellectual property (IP). In order to determine if a license falls under a hosting or SaaS arrangement, the guidance in ASC 985-20-15-5 must be reviewed. ASC 985-20-15-5 defines the two criteria that must be met for the software license to be accounted for as a hosting arrangement:
- The customer has the right to take possession of the software at any point during the hosting period without significant penalty
- It is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software
If these requirements are met, the software is part of a hosting arrangement and will likely be considered distinct. Otherwise, the software is, by default, a SaaS arrangement, and will therefore likely not be considered distinct. Significant judgment is required in assessing a software license against the two requirements.
Once the license is determined to be distinct, the next step is to determine if the license is separately identifiable from the other goods or services within the context of the contract. A license is distinct within a contract if it is not significantly related to or dependent on the other goods or services in the contract. To determine if a license is distinct within a contract, the entity may consider, but is not limited to, the following factors:
- The extent to which the licensor performs significant integration services on the goods or services before the customer receives the goods or services
- The effect two or more promised goods or services have on each other
- The utility the customer can derive from each individual promised good or service
Hosted Software
In a hosting arrangement, the licensee has as-needed access to software and related services located on third-party servers. The entity (provider) should first assess if the license meets the criteria of ASC 985-20-15-5. The AICPA Financial Reporting Executive Committee (FinREC) has concluded that software IP subject to a hosting arrangement generally meets the criteria to be distinct within a contract because the licensee derives benefit from the software, independent of other promised goods or services, throughout the license period (AICPA Audit and Accounting Guide on Revenue Recognition, Chapter 9 – Software Entities (AAG REV): 9.2.11).
SaaS
With SaaS, software IP is generally accessible to a licensee through the provider’s cloud systems. Unlike many hosting arrangements, Saas arrangements allow the licensee to access the software code only during the contracted-use term. SaaS arrangements typically do not meet the qualifications to be considered distinct because licensees do not obtain the right to use the software code on their own servers, thus these arrangements will result in revenue recognized over time in accordance with the criteria in ASC 606-10-25-27.
Hybrid Software and SaaS
In a hybrid arrangement, the licensee usually receives a combination of on-site and SaaS software IP. The entity should analyze the interdependency of and the separate utility to be obtained from the downloaded and the SaaS software.
2. Determining if Post-Contract Customer Support is a Separate Performance Obligation
Entities will need to evaluate the potential relationships between the two general categories of post-contract customer support (PCS)—technical support and software updates—and the licensed software. Two or more promised goods and services may be combined into a single performance obligation if all use the same measure of progress towards satisfaction. Factors such as high interdependency or interrelatedness between the PCS and the software may indicate the potential to combine the provided service with the software into a single performance obligation.
See our comprehensive Case Study for real-world examples and a more in-depth discussion on this topic.
3. Option to Purchase or Use Additional Software
This issue relates to whether a customer’s right to purchase additional copies/uses of software constitutes an option to purchase or variable consideration attached to existing purchased software rights.
If the vendor offers additional copies or uses of software for consideration, and the customer did not previously control those additional copies or uses, then the right to purchase may be accounted for as a sale. In contrast, if the vendor is entitled to additional consideration based on the level of usage by a customer who already had control of the software, and there are no additional rights included, the additional consideration is accounted for as a usage-based royalty. The determination of whether the right to purchase additional copies or uses represents an optional sale or variable consideration requires significant judgment of the individual facts and circumstances of the contract.
In a sale to an end-customer, FinREC states that generally the option to purchase additional copies or uses of software that the customer already controls is not a measure of software usage, and the option should be accounted for under the ASC 606 guidance for determining separate performance obligations (AAG REV: 9.2.19 through 9.2.22). If the right to purchase is considered a measure of usage, then accounting for the purchase as a usage-based fee would be appropriate.
In sales to resellers, if the reseller is merely purchasing and reselling the software product, the transaction is accounted for as a regular tangible-product sale. However, according to FinREC, if the reseller is doing more than just purchasing and reselling (e.g., purchasing the software to be part of a larger software program such that the purchased software loses its stand-alone identity), then the transaction should be analyzed like the end-user sale model explained above (AAG REV: 9.2.23 through 9.2.28).
4. Estimating the Standalone Selling Price of Options
When a software company provides an option to obtain future goods or services at a material discount to what other customers would pay, that option is treated as a separate performance obligation and part of the contract’s transaction price is allocated to that discount. The AICPA guide suggests two methods for allocating the transaction price to a material option:
- Include the option as a distinct performance obligation, and allocate the transaction price based on the option’s determined value (ASC 606-10-55-44)
- Exercise the practical expedient of “looking through” the option by calculating a hypothetical estimated transaction price of the promised future good or service, which considers the probability the option will be exercised and the value of the future goods and services to be covered by the option, and then using that estimate as an input for the allocation of the transaction price (ASC 606-10-55-45)
The entity must consider the facts and circumstances surrounding the contract to determine which of the two methods should be used to determine the standalone selling price of the options.
See our comprehensive Case Study for an in-depth example of estimating standalone selling prices.
5. Using the Residual Method to Estimate Standalone Selling Price
In the software industry, a software license is typically not sold on a standalone basis (i.e., software is usually bundled with maintenance services or other products), so its standalone selling price is not always readily available. With a highly variable or uncertain standalone selling price, the residual approach may be used if at least one of the following two conditions in ASC 606-10-32-34 are met:
- The entity sells the same good or service to different customers (at or near the same time) for a broad range of amounts (that is, the selling price is highly variable because a representative standalone selling price is not discernible from past transactions or other observable evidence)
- The entity has not yet established a price for that good or service, and the good or service has not previously been sold on a standalone basis (that is, the selling price is uncertain)
With the residual approach, the standalone value of the performance obligation is calculated as the transaction price less the sum of the observable standalone values of the remaining performance obligations in the contract. The entity should consider any historical pattern in selling price, reasonableness of the estimate, and selling price for a similar good, service, or bundle in the entity’s industry.
The requirements for establishing vendor-specific objective evidence (VSOE) under the old revenue recognition standard were stricter than the criteria to qualify for the residual approach. So, FinREC has concluded that previously established VSOE is considered an observable standalone selling price (AAG REV: 9.4.16 through 9.4.19). When VSOE exists, it is preferred and should be used instead of the residual approach.
6. Establishing a Range of Values as the Standalone Selling Price
Standalone selling prices are needed to allocate the contract’s transaction price to each of the identified performance obligations. A range developed to represent the standalone selling price should represent the price at which management would be willing to sell the standalone good or service. Management must find a range that accurately covers a high percentage of possible price points while not allowing the range to become too wide, so as to comply with ASC 606-10-32-28.
If the stated contractual price for a distinct good or service falls outside the range used to estimate the standalone selling price, FinREC believes the use of a consistent point in the range to allocate the transaction price is appropriate (AAG REV: 9.4.41).
7. Price Concessions
When a vendor accepts a lesser amount than was originally agreed upon in the contract, it must be determined if that lesser amount is a result of a price concession or simply a product of customer credit risk. If it is determined that the reduced consideration is the result of a price concession, then that reduced amount is accounted for as variable consideration which reduces the transaction price. The price concession then follows the guidance on variable consideration as it contributes to the determination of a contract’s transaction price.
Price concessions are a form of variable consideration that are often implied or assumed, as opposed to being explicit within the contract. Variable consideration is an amount—often explicitly stated in the contract—that is not contractually guaranteed to be received in full because it is contingent on the occurrence or nonoccurrence of other factors. Per ASC 606-10-32-6, those other factors may include “discounts, rebates, refunds, credits, price concessions, incentives, performance bonuses, penalties, or other similar items.” For a more detailed explanation of variable consideration, please see our article on the subject, Variable Consideration and the Constraint. In contrast to price concessions or other forms of variable consideration, a significant credit risk may lead the entity to conclude that there is not a valid contract in place. The facts and circumstances surrounding an entity’s decision to offer extended payments—including historical collection patterns, current market conditions, and forecasts—should be evaluated in the classification of the extended payments as a price concession.
Potential price concessions may be valued using the portfolio approach if the results are not materially different from those calculated on an individual contract basis.
8. Assessing the Significance of a Financing Component
When determining the existence of a significant financing component in a software license contract, entities must first decide at what point it is required to assess significance. Entities should consider strictly the significance of financing components at the individual contract level, not whether the effects of the financing component are material to a portfolio of contracts. If the financing component is material at the individual contract level, the transaction price must be adjusted.
Entities are required to evaluate (a) the difference between the amount of the promised consideration as well as the cash selling price of the promised goods or services and (b) the combined effects of (1) the length of time between when the goods or services are transferred and when payment is received and (2) the prevailing interest rate in the market. This quantitative analysis, combined with qualitative factors, will help entities to determine the significance of a financing component to the contract.
9. Transferring Control of a Software License
The transfer of control from licensor to licensee is a key determinant in the timing of revenue recognition under ASC 606. Some common instances within the industry that merit further analysis include: requiring the vendor to provide an access code, point-in-time transfer of control criteria, customer-specific acceptance provisions, timing of the transfer in a hosting arrangement, and contracting to provide software that is not yet available.
In accordance with indicators in ASC 606-10-25-30 and 55-58C, software entities may conclude that control has transferred when the customer has both access to use the software code and the legal right to such use. Even if the customer has not yet downloaded the software, FinREC believes that if a customer has received the passcode or key, it may be appropriate for the software entity to conclude that control has transferred (AAG REV: 9.5.13). Entities should consider the following questions:
- Have you provided (or made available) the software to the customer?
- Has the period of software usage rights begun?
- Do you have a present right to receive payment?
- Does the customer have the ability to direct the use of, and obtain substantially all the remaining benefits from, the software?
- Has the customer accepted the software?
- Does the customer bear the significant risks and rewards of ownership of the asset?
Answering these questions with the help of contractual agreements will help software entities to determine if control has transferred.
Conclusion
Software license arrangements can be organized as a hosting arrangement, SaaS, a hybrid of both hosting and SaaS, or direct delivery to the customer—all of which have different implications for the application of the revenue recognition model. Software companies are often tasked with deconstructing the typical bundles of product and services and then determining the separate selling price of each of those elements. These bundled deliverables complicate an entity’s ability to reasonably estimate the value of each promised good or service within the contract.
It is likely that many other issues and questions will arise within the software industry as entities continue to apply the revenue recognition standard. This article serves as a base reference point for your research into some of the focal issues. Similar industry-specific issues and resources are available on the RevenueHub site for all major industries.