The Securities and Exchange Commission disclaims responsibility for any private publication or statement of any SEC employee or Commissioner.  This speech expresses the author's views and does not necessarily reflect those of the Commission, the Commissioners, or other members of the staff.

Introduction

Good morning. I am excited to be here today. I would like to share some broad observations from consultations received this past year on the new revenue standard[1] as well as specific observations from a recent consultation.  

Identification of Performance Obligations

Looking back at the consultations our office has worked on over the past year, the top two revenue consultation topics were (1) determining whether an entity is a principal or an agent; and (2) identifying the performance obligations in a revenue contract. My colleague, and the head of our revenue topic team, Lauren Alexander, will share observations on the principal versus agent assessment, and I will focus on one particular part of identifying performance obligations in a revenue contract. Specifically, I’ll share observations for considering whether a promise to transfer a good or service to the customer is separately identifiable, or “distinct within the context of the contract.”[2]

Let me start by acknowledging that this is an area of the guidance that often requires significant judgment.

A “Solution”

The objective of the “separately identifiable” assessment is to determine whether the nature of the promise, within the context of the contract, is to transfer each of the goods or services individually or, instead, to transfer a combined item for which the promised goods or services are inputs.[3] At last year’s conference, a staff member shared a fact pattern where we did not object to a registrant’s conclusion that it was providing a significant integration service that transformed equipment and services into a combined “commercial security solution.”[4] 

While the majority of registrants that consult with us on the identification of performance obligations provide a robust analysis addressing the factors in Topic 606,[5] we sometimes hear registrants support their conclusion in consultation submissions or responses to comment letters from the Division of Corporation Finance by simply stating that they are providing a “solution,” that the customer wants a combined “solution,” or that there is only one promise in the contract to provide a “solution.”

While I understand that the term “solution” is commonly used nomenclature,[6] I would observe that the staff is not persuaded that promises should be combined into a single performance obligation simply because a registrant labels those promises as a “solution” that the “customer wants.” Rather, a registrant must support its assertion that its promises to transfer goods or services are not separately identifiable based on the guidance in ASC 606‑10‑25-21, which describes the objective of the analysis and provides factors to consider.

In addition to the guidance in ASC 606, I think it is also helpful to remember the discussion in the Basis for Conclusions of ASU 2016-10. I think that the notion of considering if the registrant’s combined output is greater than or substantively different from the sum of the parts is helpful in many cases.[7] 

Software and updates

Keeping this guidance in mind, let me share observations from a recent consultation where the staff did not object to the registrant’s conclusion that its software and software updates represent a single, combined performance obligation and elaborate on some considerations the staff found helpful in its analysis.

In this particular consultation, the registrant licenses software that allows its customers, application (“app”) developers, to build and deploy, and therefore monetize, their own apps on various third-party platforms. The third-party platforms include phones as well as home entertainment systems, which, as you can imagine, are frequently undergoing their own updates. The registrant’s software and updates ensure that the app built using the software is compatible with all platforms that it supports, both when the app is initially deployed on a platform and over time as that platform is updated. Therefore, the registrant partners with the third-party platforms to understand their timelines for internal updates so that the registrant can ensure compatibility by initiating corresponding updates to its software. Without these updates, the customer’s ability to benefit from the software would be significantly limited over the contract term.

Ultimately, the staff did not object to the registrant’s conclusion that the software and updates represent a single performance obligation. In the staff’s view, the registrant’s promises to provide the software and the updates are, in effect, inputs that together fulfill a single promise to the customer – that is, to continually be able to deploy and monetize content using third-party platforms of the customer’s choice in a rapidly changing environment – and that the updates are integral to maintaining the utility of the software. In other words, in this fact pattern, the staff thinks that the combined output (whether or not you label it a “solution”) is greater than, or substantively different than, the individual promises (that is, the software and the updates).

Thank you for your attention and I hope you enjoy the remainder of the conference.

[1] FASB Accounting Standards Codification (“ASC”) Topic 606, Revenue from Contracts with Customers.

[2] ASC 606-10-25-19(b). This speech does not address ASC 606-10-25-19(a).

[3] ASC 606-10-25-21.

[4] Sheri L. York, Professional Accounting Fellow, Office of the Chief Accountant, U.S. Securities and Exchange Commission, Remarks before the 2018 AICPA Conference on Current SEC and PCAOB Developments (Dec. 10, 2018), available at https://www.sec.gov/news/speech/speech-york-2019-12-10.

[5] ASC 606-10-25-21.

[6] See, for example, par. BC 33 of ASU 2016-10, Revenue from Contracts with Customers: Identification of Performance Obligations and Licensing.

[7] Par. BC 29 of ASU 2016-10, Revenue from Contracts with Customers: Identification of Performance Obligations and Licensing.