Newsletter – March 2019

New Revenue Recognition Standard (ASC 606) – Practical applications within the software industry

Chip Steppacher, Director, CFO Consulting Partners

Overview 

Revenue recognition within the software industry has generally been a complex topic with many industry-specific standards and interpretations. With this new single revenue recognition standard (ASC 606) replacing the industry-specific standards, the software industry has been one of the most impacted. The effective date for ASC 606 for private companies is the annual reporting periods beginning after December 15, 2018 and interim periods thereafter. For most public business entities, the effective date was their annual reporting period beginning after December 15, 2017.

This article summarizes some of the most common implementation challenges faced by CFO’s in the software industry across the five core principles in ASC 606:

  1. Identify the contract with the customer
  2. Identify the performance obligations
  3. Determine the transaction price
  4. Allocate the transaction price to distinct performance obligations
  5. Recognize revenue

Identify the contract with the customer

In addition to requiring that the contract has been approved by both parties, one of the challenges in determining whether the software contract meets all of the criteria of ASC 606 is the assessment of collectability provisions of the standard. The concept of considering the credit risk of the customer within the collectability provisions of the standard is important in determining whether collection is probable. If the software company concludes that it is not probable that it will collect a portion of the expected consideration in the contract, then the amount of revenue recognized will be reduced from the contracted amount until the collectability criteria is met.

Identify the performance obligations 

Identifying separate performance obligations under ASC 606 is a significant change for the software industry. Software arrangements are generally comprised of:

  • SaaS – cloud computing or hosted software
  • On-premises software – licenses run on customer premises
  • Post-contract support – updates and maintenance
  • Professional services – such as installation services, consulting or technical services

Under the new standard, the software company must determine whether these promised goods and services are distinct. If the goods and services are determined to be distinct, then each distinct performance obligation will be allocated a portion of the transaction price and revenue recognition assessed separately. However, in many software contracts this determination requires a series of management judgments on which products and services are combined for purposes of this principle. These combined performance obligations will ultimately determine whether the obligation is satisfied at a point in time or satisfied over time.

Determine the transaction price

The transaction price includes only those amounts where the software company has enforceable rights under the contract. If the contract price is fixed, then its application is straightforward. If the contract price is variable or there are service level agreements in place, there are additional considerations. The most significant challenge is estimating the variable consideration over the contract period based on expected value, including a determination that it is probable that there will not be a significant downward adjustment of the revenue recognized over time. Compared to the previous software standards, this estimate of variable consideration may result in earlier revenue recognition under ASC 606.

Allocate the transaction price to distinct performance obligations 

After the software company identifies the distinct performance obligations and determines the transaction price of each contract under the standard, the next challenge is allocating the transaction price to these obligations. The standard introduces the concept of relative standalone selling price or SSP.   If the products or services are sold separately in similar circumstances, then the determination of the SSP and allocation is straightforward. If the SSP is not directly observable, then the SSP will need to be estimated. Since software vendors tend to bundle their software licenses with other products and services, this determination of the SSP for each performance obligation will require management to exercise expert judgment, appropriate internal governance and detailed documentation of their conclusions. These determinations could materially impact the revenue recognized.

Recognize revenue

The timing of revenue recognition for software products and services is based on when control is transferred to the customer. Management should evaluate transfer of control primarily from the customer’s perspective and assess whether control transfers at a point in time or over time. The complexities of implementation manifest when performance obligations are combined or the software license fees are based on sales or usage royalties. This may require further estimates and management judgment to determine revenue recognition under the new standard.  

Conclusion

CFO Consulting Partners has worked with its clients to interpret and implement ASC 606 and ensure that the client is ready for full implementation and audit preparedness of the standard. As part of our work, we can assist in working through the implementation challenges, choosing the transition method, as well as determining the required disclosures. We have experience in establishing appropriate corporate governance to support management judgments and ensuring consistency in the estimation methods employed. It is also important that policies and procedures for ASC 606 and revenue recognition are documented around the end-to-end accounting and reporting process.