Technical Line: How the new revenue standard affects technology

What you need to know

• The standard has changed the timing of revenue recognition for many technology

entities. For example, it requires earlier recognition of revenue for most term-based

software licenses than legacy guidance.

• Technology entities have had to perform more analysis and exercise more judgment to

identify the promises in a contract, evaluate whether they are separate performance

obligations and allocate the transaction price to the identified performance obligations.

• Many technology entities have had to change their accounting for costs to obtain a

contract because the standard requires entities to capitalize the incremental costs of

obtaining a contract with a customer that they expect to recover. Under legacy

guidance, capitalization of costs that were both direct and incremental was

permitted, but not required, and many entities chose not to capitalize these costs.

• This publication has been updated to reflect emerging implementation issues for

technology entities, such as the accounting for contract modifications for licenses of

intellectual property and the accounting for virtual goods, among other things.

Overview

The new revenue recognition standard

issued by the Financial Accounting Standards Board

(FASB or Board) requires entities in the technology industry to make additional judgments

and estimates, such as estimating standalone selling prices of the distinct goods or services

underlying performance obligations that were not accounted for as separate units of accounting

under legacy guidance.

No. 2017-24

Updated 10 July 2020

Technical Line

FASB — final guidance

How the new revenue standard

affects technology entities

EY AccountingLink |

ey.com/us/accountinglink

2 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

This publication highlights key aspects of applying the FASB’s standard to a technology entity’s

contracts with its customers, addresses significant changes to legacy practice and reflects the

latest implementation insights.

As a reminder, the FASB deferred

the effective date to annual periods beginning after

15 December 2019 and interim periods in annual periods beginning after 15 December 2020,

for entities that had not yet issued (or made available for issuance) financial statements that

reflected the standard as of 3 June 2020 (i.e., certain private and not-for-profit entities).

Early adoption is permitted. The deferral is intended to give these entities more time to

implement the standard, given the operational and financial reporting challenges of the

COVID-19 pandemic. Public entities, as defined by the standard, and some private and not-

for-profit entities were already required to adopt the standard.

This publication, which contains a summary of the standard in Appendix A, supplements

our Financial reporting developments (FRD) publication,

Revenue from contracts with customers

(ASC 606), and should be read in conjunction with it. The views we express in this publication

may continue to evolve as implementation continues and additional issues are identified.

Technology entities should also keep in mind that, when they adopt the new credit impairment

standard,

they will need to estimate full lifetime expected credit losses for their accounts

receivable and contract assets. As a reminder, they will need to do this after assessing

collectibility under the revenue guidance to determine whether they have a contract with a

customer. Refer to our FRD publication,

Credit impairment for short-term receivables under

ASC 326, for more information.

Technology contracts can include software as a service (SaaS), cloud computing, hosted

software or other cloud services (collectively referred to as cloud services throughout this

publication; see the “Cloud services

” section of this publication for more details, including a

description of the most common types of cloud services); licenses of software that are run

from servers on the customer’s premises (often referred to as on-premises software or on-

premise software); hardware; networking equipment; or a mix of these goods and services.

Technology entities often sell updates to licensed software that are transferred on a when-

and-if-available basis, bug fixes and telephone support (collectively referred to as post-

contract customer support or PCS). Technology entities also offer professional services

ranging from information technology (IT) consulting services to technical support services.

Because the standard provides specific guidance on the recognition of revenue from licenses

of intellectual property (IP), it is important for entities to determine whether a contract

contains a license of IP. Therefore, this publication starts with a section on evaluating whether

a contract contains a license of IP and then addresses the accounting guidance required by the

standard for licenses of IP. It is important to note that entities with licenses of IP still follow

other aspects of the standard’s five-step model for contracts because the licensing guidance

does not address all aspects of the model. Therefore, the sections of this publication on

identifying performance obligations and additional considerations apply to all technology

contracts, including those that contain licenses of IP.

EY AccountingLink |

ey.com/us/accountinglink

3 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Contents

Overview .............................................................................................................................. 1

Determining whether a contract contains a license of IP ...................................................... 5

Licenses of IP ...................................................................................................................... 5

Determining whether a license is distinct (updated January 2020) ....................................... 5

Determining whether the license in a hybrid-SaaS contract is distinct................................. 7

Capable of being distinct ........................................................................................... 7

Distinct within the context of the contract (updated January 2020) .............................. 7

Vendor-specific objective evidence of fair value is no longer required

(updated January 2020) ................................................................................................. 8

Determining the nature of the entity’s promise in software arrangements ............................ 9

Functional IP.................................................................................................................... 9

Symbolic IP ...................................................................................................................... 9

IFRS ................................................................................................................................ 9

Recognition of revenue from a license of IP ......................................................................... 9

Electronic delivery (added January 2020) ...................................................................... 10

Extension of a term-based license ..................................................................................... 11

Contract modifications of term-based software licenses (added January 2020) ............... 11

Sales- or usage-based royalties (updated January 2020) ................................................... 12

Estimating sales- or usage-based royalty received on a lag (updated January 2020) ........ 13

Purchase or use additional copies of software ................................................................. 13

Estimating standalone selling prices (updated January 2020) ............................................ 14

Estimating standalone selling prices in perpetual license contracts .................................. 14

Estimating standalone selling prices in term-based license contracts

(updated January 2020) .............................................................................................. 15

Customized software (added January 2020) ..................................................................... 15

Provision for loss ........................................................................................................... 16

Migrating from on-premise software to SaaS (added January 2020) .................................. 16

Cloud services (added January 2020) ................................................................................ 17

Determining the nature of the entity’s promise in cloud service arrangements .................... 17

Applying the series guidance .......................................................................................... 18

Allocating variable consideration under the series guidance ............................................ 20

Recognition of revenue from cloud service arrangements (added January 2020) ............... 21

Fixed-fee arrangements (added January 2020) .............................................................. 21

Fixed-fee arrangements with overages (added January 2020) ........................................ 22

Variable fee arrangements based on usage (added January 2020) .................................. 23

User-based arrangements (added January 2020) ........................................................... 24

Estimating standalone selling prices in cloud service contracts (added January 2020) .............. 25

Hardware sold with cloud services (added January 2020) .................................................. 26

Identifying other performance obligations commonly found in technology contracts .......... 27

Material rights (updated January 2020) ............................................................................ 28

Nonrefundable up-front fees (updated January 2020) ....................................................... 30

Implementation services (updated January 2020) ............................................................. 31

Post-contract customer support or maintenance services (updated January 2020) ............... 33

Specified upgrades (updated January 2020) ..................................................................... 34

Distinguishing between specified and unspecified upgrades (added January 2020) .......... 34

EY AccountingLink |

ey.com/us/accountinglink

4 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Unspecified additional software products (updated January 2020) .................................... 36

Remix rights (updated January 2020) ............................................................................... 37

Significant financing component (added January 2020) .................................................... 39

Virtual goods (added January 2020) ................................................................................. 39

Identifying the contract and performance obligations ...................................................... 40

Satisfaction of the performance obligation...................................................................... 40

Changes to estimated period of performance ............................................................ 41

Additional considerations for technology contracts............................................................ 42

Enforceable rights and obligations (updated January 2020) .............................................. 42

Termination clauses ....................................................................................................... 42

Contract modifications (updated January 2020) ............................................................. 44

New contracts with existing customers (added January 2020) ................................... 45

Collectibility ..................................................................................................................... 46

Principal versus agent (updated January 2020) ................................................................ 47

Determining gross revenue as a principal when selling through an intermediary

(added January 2020) ................................................................................................. 50

Variable consideration ...................................................................................................... 52

Implied price concessions (updated January 2020) ......................................................... 52

Extended payment terms ............................................................................................... 53

Reseller and distributor contracts ................................................................................... 53

Variable consideration and options for additional goods and services ............................... 53

Recognition of revenue..................................................................................................... 54

Measuring progress in a combined performance obligation .............................................. 54

Contract costs .................................................................................................................. 55

Costs to obtain a contract .............................................................................................. 55

Identifying costs to obtain a contract that are required to be capitalized ..................... 55

Amortization of capitalized costs to obtain a contract (updated January 2020) ........... 56

Allocating capitalized costs to obtain a contract to individual performance obligations ... 59

Impairment of capitalized costs to obtain a contract (updated January 2020) ............. 59

Costs to fulfill a contract (updated January 2020) .......................................................... 60

Disclosure requirements (updated January 2020) ............................................................. 62

Appendix A: The five-step revenue model and contract costs............................................. 65

Definition of a contract .................................................................................................. 65

Contract combination .................................................................................................... 65

Contract modifications ................................................................................................... 65

Series guidance ............................................................................................................. 66

Customer options for additional goods or services .......................................................... 66

Principal versus agent considerations ............................................................................. 66

Variable consideration ................................................................................................... 67

Significant financing component ..................................................................................... 67

Noncash consideration ................................................................................................... 67

Consideration paid or payable to the customer ............................................................... 67

Appendix B: Additional topics ............................................................................................ 70

EY AccountingLink |

ey.com/us/accountinglink

5 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Determining whether a contract contains a license of IP

The standard provides guidance on the recognition of revenue from licenses of IP that goes

beyond the recognition model for other promised goods and services. When applying the

guidance on licenses of IP, a technology entity analyzes the facts and circumstances of each

contract (or type of contract) and may need to use more judgment than it did under legacy

GAAP. The units of accounting and timing of revenue recognition also may change.

To apply the revenue standard, technology entities first need to determine whether a contract

includes a promise of a license of IP. This assessment may be straightforward for contracts

that include licenses of on-premise software, but entities have to carefully evaluate the

contractual rights in contracts that include hosting services.

The criteria for making this assessment in hosted arrangements were carried forward from

Accounting Standards Codification (ASC) 985, Software. A separate promise of a license

exists when (1) the customer has the contractual right to take possession of the software at

any time during the hosting period without significant penalty and (2) the customer can run

the software on its own hardware or contract with another party unrelated to the vendor to

host the software.

(Refer to section I2.4.1 of the EY Accounting Manual for further

discussion of the term “significant penalty.”)

If both criteria are met, a separate promise of a license of IP exists in the contract. The FASB

emphasized in the Background Information and Basis for Conclusions of Accounting Standards

Update (ASU) 2016-10

that a contract must include a license of IP for an entity to apply the

licensing guidance in the standard.

Licenses of IP

Determining whether a license is distinct (updated January 2020)

After determining that a contract includes a license of IP, a technology entity must determine

whether the license and additional goods and services are distinct. To be distinct, a license

must be both (1) capable of being distinct and (2) separately identifiable (i.e., distinct within

the context of the contract).

A license is capable of being distinct if a customer can benefit from the license either on its

own or together with other resources that are readily available to the customer. If a license is

capable of being distinct, it is evaluated to determine whether it is distinct within the context

of the contract (i.e., whether the nature of the promise is to transfer the license and the other

goods or services individually or to transfer a combined item or items whose inputs are the

license and the other promised goods or services).

Consider Example 11, Case A,

in the standard, which describes a contract for a software

license that is transferred along with installation services, technical support and software

updates. The installation service is routinely performed by other entities and does not

significantly modify the software. The software license is delivered before the other goods

and services and has utility without the updates and technical support. The customer can

benefit from the technical support and updates together with the software license transferred

at the outset of the contract. The entity concludes that the customer can benefit from each of

the goods and services either on its own or together with other goods or services that are

readily available.

That is, each good or service, including the software license, is capable of

being distinct under ASC 606-10-25-19(a).

The entity then considers the factors in ASC 606-10-25-21 and determines that the promise to

transfer each good and service, including the software license, is distinct within the context of

the contract. In reaching this determination, the entity notes that the installation services are

Determining

whether a license

distinct may

require significant

judgment.

EY AccountingLink |

ey.com/us/accountinglink

6 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

routine and can be obtained from other providers, and software updates and technical support

aren’t necessary for the software to maintain a high level of utility to the customer during the

license period. Therefore, the installation services, software updates and technical support do

not significantly affect the customer’s ability to use and benefit from the software license.

The entity further observes that none of the promised goods or services significantly modify

or customize one another, and the entity is not providing a significant service of integrating

the software and services into one combined output. Lastly, the software and the services are

not deemed to be highly interdependent or highly interrelated because the entity can fulfill its

promise to transfer the initial software license independently from its promises to provide the

installation service, software updates and technical support. As a result, the entity identifies

four performance obligations: the software license, the installation services, the technical

support and the software updates.

When a license of IP is not distinct, it is combined with other goods and services as a single

performance obligation. Consider Example 10, Case C,

in the standard. In this example, the

entity grants a customer a three-year term license to antivirus software and promises to

provide the customer with unspecified updates to that software during the license period

when and if they become available. The entity frequently provides updates that are critical to

the continued utility of the software. Without the updates, the customer’s ability to benefit from

the software would decline significantly during the three-year contract. The entity concludes

that its promises to transfer the software license and to provide the updates, when and if available,

are not distinct within the context of the contract in accordance with ASC 606-10-25-19(b)

because the license and the updates are, in effect, inputs to a combined item (i.e., antivirus

protection) promised to the customer in the contract. The updates significantly modify the

functionality of the software (i.e., they permit the software to protect the customer from a

significant number of additional viruses that the software did not protect against previously)

and are integral to maintaining the utility of the software license to the customer. Consequently,

the license and updates fulfill a single promise to the customer in the contract (a promise to

provide protection from computer viruses for three years) and are accounted for as a single

performance obligation.

Refer to the “Customized software

” section for a discussion of contracts to deliver software

or a software system that requires significant production, modification or customization

(i.e., where the software license is not distinct from services that customize the software).

How we see it

Many software contracts are not directly analogous to the two examples the standard

provides of how to evaluate whether to combine a license and unspecified updates into a

single performance obligation. Each software entity needs to evaluate the specific terms of

its contracts to determine whether the license should be combined with the unspecified

updates or other promises in the contract.

We believe that to reach a conclusion that a license and unspecified updates are not

distinct within the context of the contract, an entity generally would need to demonstrate

that providing the updates significantly affects the utility of the software license. Many

technology entities have concluded that the license and unspecified updates are separate

performance obligations because the unspecified updates are not critical to maintain the

utility of the license and are not provided frequently enough for them to conclude that the

license and unspecified updates are highly interrelated or interdependent.

EY AccountingLink |

ey.com/us/accountinglink

7 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Determining whether the license in a hybrid-SaaS contract is distinct

Hybrid-SaaS offerings combine on-premise software and SaaS and result in some functionality

residing on the customer’s servers (i.e., on premises) or on the servers of the customer’s third-

party provider and some being accessed over the internet through the technology entity’s

(i.e., the vendor’s) servers or through the servers of the technology entity’s third-party provider.

Capable of being distinct

When an entity concludes that a hybrid-SaaS contract contains a software license for the on-

premise software, the software license and SaaS are often capable of being distinct because

the customer can obtain some utility from the software license without the SaaS and can benefit

from the SaaS with readily available resources (i.e., the software license that has already

been transferred to the customer).

Distinct within the context of the contract (updated January 2020)

Determining whether the software license is distinct within the context of the contract often

requires significant judgment. An entity should consider the level of interdependence and

interrelationship between the software license and the SaaS promised in the contract.

In some offerings, the licensed software and the SaaS may have limited functionality on their

own, but, when used together, the combined solution may contain the critical functionality

required by the customer. In these contracts, the technology entity may conclude that the

software license and the SaaS are highly interdependent or highly interrelated (i.e., not

distinct within the context of the contract) and should be combined into a single performance

obligation. For example, an entity may conclude a software license and SaaS are not distinct

within the context of the contract if the software license provides limited benefit to the

customer without the SaaS. In other contracts, the software license or the SaaS may have

significant functionality on its own and likely results in two performance obligations.

The focus of this evaluation is on the functionality that is delivered through the combination

of the SaaS and software license. To conclude that there is a single performance obligation,

the technology entity needs to establish that transferring the combined software license and

SaaS provides significantly more utility than transferring the software license and the SaaS

separately. That is, the technology entity needs to demonstrate that there is a significant two-

way dependency between the software license and the SaaS to conclude that the two

promises are highly interrelated or interdependent.

Often, gaining a sufficient understanding of the utility of the SaaS and software license will

require officials in the accounting department to have discussions with software engineers or

employees from other departments in order to evaluate the features and functionalities of

each product or service. An entity should also consider how its products and services are

described in publicly available information (e.g., the entity’s website, investor relations reports,

financial statement filings) because those descriptions may indicate customer expectations

and the functionalities that are critical to the overall offering.

The specific facts and circumstances of each contract have to be carefully considered. Below

are some factors that may assist in the evaluation of the interrelationship and interdependency

of the software license and SaaS. While the factors may help to support an entity’s assessment

of whether the software license and SaaS are distinct, they are meant to complement the

overall assessment of whether the promises are distinct and are not determinative.

EY AccountingLink |

ey.com/us/accountinglink

8 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Factors that may suggest the software license and SaaS are distinct within the context of the

contract include:

•

The SaaS functionalities are available from other vendors.

•

The software license or SaaS functionalities have utility on their own.

•

The functionalities provided by the SaaS can also be performed using only the software license.

Factors that may suggest the software license and SaaS have a significant two-way

dependency and, therefore, are not distinct within the context of the contract include:

•

The customer obtains significant utility from the entity’s integration of the software

license with the SaaS.

•

There are frequent and significant interactions between the software license and the SaaS

(e.g., certain important tasks can only be performed when the software is connected to

the SaaS).

How we see it

The evaluation of whether the software license and the SaaS in a hybrid-SaaS contract are

distinct within the context of the contract can be challenging for technology entities.

Determining that the software license and the SaaS are highly interrelated or highly

interdependent requires an entity to demonstrate a significant two-way dependency

between the two promises, not simply that one promise depends on the other or that the

SaaS complements the software.

Vendor-specific objective evidence of fair value is no longer required (updated January 2020)

Under the standard, technology entities assess whether promised goods or services in a software

licensing arrangement are capable of being distinct and are distinct within the context of the

contract (i.e., separately identifiable from the other promises in the contract). That is, to

separately account for elements in a software licensing contract, these entities no longer need

vendor-specific objective evidence (VSOE) of the fair value of the undelivered element(s).

As a result, technology entities that have adopted the standard may recognize revenue earlier

than they did under the legacy software guidance, especially for arrangements that involve

term-based licenses.

Under the standard, a software vendor that provides a term-based software license bundled with

coterminous PCS will conclude that there are two performance obligations if it determines that

each promise is distinct. Because the software license has standalone functionality, it is classified

as functional IP (see the “

Determining the nature of the entity’s promise in software

arrangements” section for a discussion of functional IP), and revenue is recognized at the point

in time when control transfers (see the “Recognition of revenue from a license of IP” section

below). Under the legacy accounting guidance for term-based licenses, by contrast, entities

typically had to combine elements in contracts that included coterminous, term-based software

licenses and PCS because they were not able to establish VSOE of the fair value of the PCS. As

a result, under legacy guidance, revenue for the combined element was generally recognized

as delivery of the last element took place (i.e., as PCS was delivered, which was typically over

the license period).

EY AccountingLink |

ey.com/us/accountinglink

9 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The elimination of the VSOE requirement has not changed the timing of revenue recognition

for perpetual software licenses. This is because, under legacy guidance, many entities were

able to establish VSOE of fair value for PCS from standalone sales of PCS renewals (since PCS is

typically sold in one-year increments), and therefore, they were able to account for a perpetual

software license and PCS as separate elements.

Determining the nature of the entity’s promise in software arrangements

Entities are required to classify IP as either functional or symbolic as part of their determination

of whether to recognize the revenue associated with the license of that IP at a point in time or

over time.

Functional IP

Functional IP has significant standalone functionality and a substantial portion of its utility

(i.e., the IP’s ability to provide benefit or value) relates to its standalone functionality. This

type of IP does not require the licensor to continue to support or maintain the IP as part of its

promise. Examples of functional IP include software licenses and patents. Revenue from

functional IP generally is recognized at a point in time.

A software license is typically considered to be functional IP because the software has standalone

functionality. That is, the customer can derive substantial benefit from the software on its

own, and its functionality is not expected to change substantively as a result of the licensor’s

ongoing activities that do not transfer a good or service to the customer. A technology entity

may promise to continue to support or maintain the software, with unspecified updates and

upgrades, but these activities are generally separate promises in the contract and, therefore,

do not significantly affect the functionality of the software promised to the customer. In making

this assessment, entities don’t consider whether a license is perpetual or for a specified term.

Symbolic IP

Symbolic IP does not have significant standalone functionality because its utility is derived

from the licensor’s ongoing or past support (e.g., activities that support the value of a brand

name). Examples of symbolic IP include brands and trade names. Revenue from symbolic IP is

recognized over time.

IFRS

IFRS 15 Revenue from Contracts with Customers, which is largely converged with the revenue

guidance in US GAAP, does not require entities to classify licenses of IP as either functional or

symbolic. Instead, entities that apply IFRS 15 must evaluate whether the contract requires, or

the customer reasonably expects, the entity to undertake activities that significantly affect

the IP to which the customer has rights. IFRS 15 also specifies that if the IP has significant

standalone functionality, the customer derives a substantial portion of the benefit of that IP

from that functionality and would not be significantly affected by the entity’s activities, unless

they change the form or functionality significantly.

The FASB and the International Accounting Standards Board (IASB) agreed that their approaches

generally would result in consistent answers, but there could be differences between US GAAP

and IFRS when entities license brand names that no longer have any related ongoing activities

(e.g., the license to the brand name of a defunct sports team, such as the Brooklyn Dodgers).

Recognition of revenue from a license of IP

The standard doesn’t allow entities to recognize revenue for a license of IP before both (1) they

provide the IP or make it available to the customer and (2) the beginning of the period during

which the customer is able to use and benefit from the license.

Entities have to

wait to recognize

revenue until the

beginning of a

license renewal

period.

EY AccountingLink |

ey.com/us/accountinglink

10 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Technology entities may make a copy of the software (functional IP) available to a customer

(e.g., enable the customer to electronically download it) upon contract inception but prior to

the start of the license period. The standard states that an entity would not recognize revenue

before the beginning of the license period, even if the entity provides the IP (or otherwise

makes it available) before that date. Assuming that all other criteria have been met, the

technology entity recognizes revenue from the software (the IP) at the point in time when the

customer is able to use and benefit from the software (i.e., the start of the license period).

Consider a technology entity that enters into a contract with a customer to provide a software

license for a three-year term beginning on 1 January 20X8 and then provides a copy of the

software to the customer on 29 December 20X7. Although the entity made a copy of the

software available to the customer on 29 December 20X7, the customer does not have the right

to use the licensed software until the license period begins on 1 January 20X8. Therefore, the

entity recognizes revenue related to the software license on 1 January 20X8, assuming the

entity has concluded that control of the license has transferred.

Electronic delivery (added January 2020)

Many software vendors deliver licensed software products electronically. When software is

delivered electronically, we believe that control of the software transfers when the customer

has the reasonable ability to access the licensed software (i.e., the software vendor has made

the software available to the customer). This typically occurs when the vendor provides the

necessary codes to the customer that allows the customer to commence downloading of the

licensed software, the vendor’s server is functioning, and the license period has begun.

We note that even if a vendor provides a customer with a key to electronically download the

software before the license period begins, the customer does not have the right to use the

licensed software until the license period begins. Further, even if the customer is required

to request access codes, we believe the customer would generally have the reasonable ability

to access the licensed software once it is able to make the request if providing the code is

purely administrative.

We generally believe that the download does not have to be completed for control to have

transferred. The customer just needs to have the ability to download the software.

Illustration 1 — Electronic delivery

Consider a software vendor that provides its customer with the means to download

software electronically. To receive the access code for the electronic download, the

customer must email the vendor’s customer setup inbox, which automatically generates

and provides the customer with an access code within minutes. This gives the customer the

flexibility to designate the appropriate employee to receive the access code.

The customer has purchased 100 seats for a three-year term license beginning 31 December

20X0. On 1 January 20X1, the customer submits the request for an access code and

receives one shortly thereafter. The customer downloads the software for some users that

same day and downloads the software for the remaining users over the next two months.

The vendor determines that control of the software transferred on 31 December 20X0,

and revenue related to the software license can be recognized at that time. This is because

the vendor made the software available on 31 December 20X0 (since the customer was

able to email and obtain the access code beginning that date), and that date was the

beginning of the license period. The fact that the customer did not download all copies on

that date is irrelevant.

EY AccountingLink |

ey.com/us/accountinglink

11 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Extension of a term-based license

The guidance on recognizing revenue from a license of IP also applies to renewals or extensions

of term-based licenses. That is, revenue related to the renewal of a license of IP may not be

recognized before the beginning of the renewal period because that’s when the licensee can

use and benefit from the renewed license. Consider the following example:

Illustration 2 — Extension of a term-based license

Technology entity X enters into a contract with a customer for the use of a software license

(License A) and PCS for a three-year period from 1 January 20X1 through 31 December 20X3

(the initial contract). On 30 June 20X2, Technology entity X and the customer agree to renew

the contract for an additional three years from 1 January 20X4 through 31 December 20X6

(the extension period). Assume that the software license and unspecified updates are distinct,

and that Technology entity X recognizes revenue from the license (functional IP) at a point in

time and from the PCS over time using a time-elapsed method. The customer has a copy of

License A before the start of the extension period.

Revenue from an initial license or a license renewal cannot be recognized until the beginning

of the license period to which it relates because the customer cannot use and benefit from

the software until then. Although the customer has a copy of the software from the initial

contract, Technology entity X recognizes revenue for the renewal period on 1 January 20X4,

when the customer can use and benefit from the software during the extension period.

IFRS 15 does not require an entity to wait to until the beginning of the license renewal period

to recognize revenue relating to a license renewal. Accordingly, the IASB noted in the Basis for

Conclusions on IFRS 15 (in its April 2016 amendments) that entities that report under IFRS

may recognize revenue for contract renewals or extensions earlier than those that report

under US GAAP.

How we see it

The guidance in ASC 606 on license renewals changed practice for technology entities that

had followed the legacy software guidance. Under the legacy guidance, technology entities

recognized revenue from the extension of an active term-based license when the renewal

agreement was executed, assuming all other revenue recognition criteria were met and

VSOE of fair value of the undelivered element (e.g., PCS) had been established. This was

because the customer already had possession of and the right to use the software to which

the extension or renewal applied.

Under the standard, the customer does not have the right to use the software under the

renewal agreement until the beginning of the extension period, even though the customer

already possesses a copy of the software. Therefore, entities must wait until the beginning of

the extension period to recognize revenue for renewals of software licenses under the standard.

Contract modifications of term-based software licenses (added January 2020)

 EITF will address issues related to modifications of licenses of IP

The FASB has added a project to the agenda of the Emerging Issues Task Force (EITF) to

address diversity in practice related to accounting for contract modifications for licenses

of IP under the revenue standard. As part of this project, the EITF will address the accounting

for contract modifications that extend a license term but are not solely a renewal of the

terms and conditions of the original license.

EY AccountingLink |

ey.com/us/accountinglink

12 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Stakeholders had said that the guidance isn’t clear on when revenue from a license of IP

should be recognized if a modification is not solely a renewal of the terms and conditions of

the original license (e.g., the modification also adds other goods or services or changes the

pricing). As a result, some entities believe that revenue for a license renewal should be

recognized when the modification is approved by both the licensor and licensee, while others

believe revenue should be recognized at the end of the original license term, which may be

later than when the modification was approved. Technology entities should select one

approach and apply it consistently to similar transactions until the EITF addresses the issue.

We encourage readers to monitor developments because any new guidance on this topic

could affect accounting for such arrangements. Refer to our To the Point, The EITF will

address revenue recognition related to contract modifications for licenses of IP, for details.

Sales- or usage-based royalties (updated January 2020)

Technology entities may enter into contracts that require the customer to pay a sales- or

usage-based royalty in exchange for a software license. For example, a technology entity that

licenses transaction processing software may require customers to pay a fee for each transaction

processed using the software.

Revenue generated from sales- and usage-based royalties from licenses of IP is recognized at

the later of when (1) the sale or usage occurs or (2) the performance obligation to which

some or all of the sales- or usage-based royalty has been allocated is satisfied (in whole or in

part). That is, an entity recognizes the royalties as revenue when (or as) the customer’s sales

or usage occurs, unless that recognition pattern accelerates revenue recognition ahead of the

entity’s satisfaction of the performance obligation to which the royalty solely or partially

relates based on an appropriate measure of progress. This guidance is known as the royalty

recognition constraint.

Since a software license is functional IP and the performance obligation to provide the

software is generally satisfied at the point in time when control of the license transfers to the

customer (assuming the software license is not combined with a service, such as hosting or

PCS), following the royalty recognition constraint will generally not accelerate revenue

recognition ahead of the entity’s satisfaction of the performance obligation to which the

royalty solely or partially relates.

The FASB explained in the Basis for Conclusions of ASU 2016-10

that the guidance in

ASC 606-10-55-65 through 55-65B addresses the recognition of sales- or usage-based

royalties received in exchange for a license of IP, rather than when such amounts are included

in the transaction price of the contract. As a result, this exception is a recognition constraint,

and the constraint on variable consideration does not apply.

In some contracts, a sales- or usage-based royalty may be related to both a license of IP and

another good or service that may or may not be distinct. The standard requires an entity to apply

the royalty recognition constraint to the overall royalty stream when the sole or predominant item

to which the royalty relates is a license of IP. When the sole or predominant item to which the

royalty relates is not a license of IP, the general variable consideration guidance applies.

Technology entities need to apply judgment when determining whether to apply the royalty

recognition constraint to a software license that is combined with other goods or services. An

entity should not split a single royalty and apply the royalty recognition constraint to one portion

of the royalty and apply the general constraint on variable consideration to the other portion.

EY AccountingLink |

ey.com/us/accountinglink

13 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

It is important to note that the royalty recognition constraint applies only to licenses of IP for

which some or all of the consideration is in the form of a sales- or usage-based royalty. The

Board said in the Basis for Conclusions of ASU 2014-09

that because the royalty recognition

constraint was structured to apply only to a particular type of transaction (i.e., a license of IP),

other transactions that may be economically similar would be accounted for differently. That

is, entities cannot analogize to the royalty recognition constraint for other situations. For

example, it cannot be applied if consideration in a contract is in the form of a sales- or usage-

based royalty but there is no license of IP or a license of IP is not the predominant item to

which the royalty relates (e.g., sales- or usage-based fee in a SaaS contract that does not

contain a software license).

Estimating sales- or usage-based royalty received on a lag (updated January 2020)

An entity that applies the royalty recognition constraint should recognize revenue when the

underlying sales or usage has occurred and the performance obligation to which the royalties

relate has been satisfied (or partially satisfied). Therefore, licensors that are provided actual sales

or usage data from the licensee on a lag may need to estimate the royalties earned in the current

reporting period. That is, technology entities are not able to recognize sales- or usage-based

royalties on a lag when the data is not received in the period in which the sales or usage occurs.

The former Chief Accountant of the Securities and Exchange Commission (SEC) noted in a

speech

that because the FASB did not provide “a lagged reporting exception” in the

standard, the reporting of sales- and usage-based royalties may require estimation when the

sales or usage data is received on a lag.

How we see it

Estimating royalties earned in the current reporting period by licensors without actual

sales or usage data from the licensee requires significant judgment. Licensors need to

have processes and controls to collect data and develop assumptions to make a

reasonable estimate. Some technology entities that have adopted the standard have

requested more frequent reports from their customers or changes to the timing of reports

so that they have actual data for some sales to use in their estimates. For example, an

entity may receive sales or usage data monthly rather than quarterly and would,

therefore, only need to estimate sales or usage in the last month of the quarter.

Purchase or use additional copies of software

A technology entity may provide the customer with the option to purchase or use additional

copies of software in exchange for additional consideration, and the customer may have the

ability to replicate the software or download additional copies without further assistance from

the technology entity. Questions have been raised about whether this type of option is an

option to acquire additional software rights (i.e., an option for additional goods) or whether

the extra copies represent additional usage of the software license and, therefore, whether

the additional usage gives rise to a sales- or usage-based royalty that likely is subject to the

royalty recognition constraint.

The Joint Transition Resource Group for Revenue Recognition (TRG)

generally agreed

that

the entity has to exercise judgment to determine whether the contract is for a single license

or for multiple licenses. In doing so, the entity considers whether the additional copies are

distinct goods or services. Additional licenses are typically distinct because the customer can

benefit from the additional license on its own, and providing it does not modify, customize or

have an interdependency with existing licenses. TRG members also generally agreed that

while the customer may be able to replicate the software or download additional copies without

the assistance of the technology entity, the entity may still be required to grant additional rights

to the customer for the use of the additional copies of software.

EY AccountingLink |

ey.com/us/accountinglink

14 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

An entity has provided a customer with an option if the customer can decide to purchase

additional distinct copies of the software, and the entity is required to transfer those additional

rights to the customer. Conversely, if the contract requires the customer to pay usage-based

fees to compensate the vendor for the rights to use the software that have already been

transferred, these fees are treated as variable consideration. When the software license is the

sole or predominant item to which the usage-based fees relate, the fees are accounted for as

sales- and usage-based royalties rather than general variable consideration (see the “

Sales-

or usage-based royalties” section above for details).

Estimating standalone selling prices (updated January 2020)

Software entities commonly sell licenses, both perpetual and term-based, as part of bundled

arrangements with PCS services, and these bundles are frequently sold at steep discounts

to the list prices. In some cases (e.g., term-based license contracts), the license and PCS are

not sold separately by the entities, meaning there isn’t a standalone selling price based on

observable inputs.

The standard requires an entity to estimate the standalone selling price for each performance

obligation and allocate the transaction price to each performance obligation on a relative

standalone selling price basis with limited exceptions (i.e., allocation of a discount

and

allocation of variable consideration

). The FASB also stated in the Basis for Conclusions of

ASU 2014-09

that if the good or service is sold at highly variable amounts, the most reliable

way to determine the standalone selling price may be to use the residual approach. The standard

states

that the residual approach can only be applied to contracts with multiple promised

goods or services when the selling price of one or more goods or services is unknown (either

because the historical selling price is highly variable, as might be the case for software

licenses, or because the goods or services have not yet been sold (e.g., specified upgrade

rights for software)), and when observable standalone selling prices exist for the other goods

and services in the contract (e.g., PCS sold at a constant percentage of the net license fee

Under the residual approach, an entity estimates the standalone selling price by deducting the

sum of the observable standalone selling prices of the other performance obligations in the

contract from the transaction price. That is, the residual approach is used to estimate the

standalone selling price under the standard rather than to allocate consideration, as it was

used under legacy guidance.

How we see it

To support use of the residual approach when historical prices are highly variable, entities

must perform a thorough assessment of the pricing. As part of the assessment, entities

should consider whether data has been sufficiently stratified (e.g., by customer size or by

geography) and whether results are consistent with the entity’s pricing strategies.

Concentrations of historical prices around a specific point (e.g., the midpoint) or range

may indicate that prices are not highly variable.

The SEC staff has requested a comprehensive, quantitative discussion of variability to

support the use of the residual approach as part of its comment letter process.

Estimating standalone selling prices in perpetual license contracts

For perpetual licenses, the first year of PCS is often included in a bundle with the license, and

renewals of PCS are frequently sold on a standalone basis. It is common practice in the software

industry to charge a percentage of the net perpetual license fee (e.g., 20% of the net license fee)

for renewals of standalone PCS. Entities may be able to use the residual approach to estimate

the standalone selling price of the perpetual license if they have sufficient evidence to support

VSOE of fair value

is no longer

required to account

for good

s and

services separately

from each other.

EY AccountingLink |

ey.com/us/accountinglink

15 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

the assertion that the pricing for the perpetual license bundle is highly variable and there is an

observable price for the PCS. An observable price for PCS may be established if PCS is priced

at a consistent percentage of the net license fee for similar sales (e.g., sales to similar customers

by class and geographical market). For example, PCS may be consistently priced at 20% of the

net license fee. That is, the entity can demonstrate that the pricing relationship between the

software license and the PCS is consistent across sales to similar customers (based on the

observable price of the PCS established as a constant percentage of the net license fee).

Other considerations for estimating the standalone selling price of both the perpetual license

and the PCS include the entity’s internal pricing strategies, sales of similar goods or services

by third parties, or other industry pricing. The entity should prioritize the use of observable

inputs in its estimates of the standalone selling price.

Although VSOE of the fair value of each element is no longer required, technology entities

may find that they are able to use the observable data they used to calculate VSOE of fair

value to estimate the standalone selling price for certain performance obligations, such as

PCS and professional services.

Estimating standalone selling prices in term-based license contracts (updated January 2020)

Term-based licenses are often sold in a bundled arrangement with PCS for the contract term.

In these cases, entities may not have standalone sales of either the term-based license or the

PCS. To estimate standalone selling prices for both the license and PCS in a bundled term-

based license contract, entities may be able to identify pricing relationships between term-

based licenses and perpetual licenses of the same software product and their related PCS.

For example, assume that an entity enters into a contract with a customer to provide a three-year

term-based license and PCS for the license term for a total of $400,000. The entity does not

have previous standalone sales for the license or PCS in these types of contracts. Using observable

data from contracts for perpetual licenses of the same software product with one year of PCS

and two subsequent renewals of PCS, the entity concludes that the PCS represents 20% of the

net license fee. The entity considers this relationship in allocating the $400,000 fee for the

term-based license arrangement between the license and PCS in the contract.

This example describes one acceptable method for estimating standalone selling price

(i.e., leveraging the relationship between a perpetual license and PCS in similar sales). Entities

can use other reasonable methods for estimating standalone selling price for the license and

PCS in term-based license contracts. That is, entities also can consider the estimated life of

the software, the pricing strategies used to determine the prices for both perpetual and term-

based licenses of the same software and third-party prices for similar contracts. Regardless of

the method used, entities should prioritize the use of observable data in their estimates and

should apply the same approach consistently for similar contracts.

Customized software (added January 2020)

Technology entities may enter into contracts to deliver software or a software system that

requires significant production, modification or customization (commonly referred to as

customized software). In this situation, an entity may conclude that the software license and

professional services related to the production, modification or customization are not

separately identifiable and, therefore, represent a single performance obligation based on the

factor in ASC 606-10-25-21(b) that says, “one or more of the goods or services significantly

modifies or customizes … one or more of the other goods or services promised in the contract.”

To determine whether to account for customized software as a single performance obligation,

technology entities should consider whether they are making alterations to the software’s

source code, and if so, the level of effort required to complete the alterations, as well as

EY AccountingLink |

ey.com/us/accountinglink

16 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

whether the alterations create new features or functionality that are critical to the utility of

the software for the customer. This evaluation will be contract-specific (i.e., based on the

professional services the entity agrees to provide in the arrangement).

How we see it

Many technology entities have determined that they do not provide customized software

because the professional services they provide as part of the arrangement do not significantly

modify or customize the underlying software. Professional services related to data migration

or integration with the customer’s computing environment typically do not indicate that

the software is customized. Typically, if customizations are not customer-specific (e.g., if

the customizations will be incorporated into a future version of the software and made

available to all customers), the software vendor is not providing customized software.

After evaluating the performance obligations in the contract, an entity that concludes that it

has a single performance obligation to provide customized software must determine whether

the combined performance obligation is satisfied over time or at a point in time. Control

transfers over time if one of the criteria described in ASC 606-10-25-27 is met.

We believe the second and third criteria are most relevant for a technology entity to assess

for customized software arrangements. That is, the entity must determine (1) whether the

customer owns the software code as it is being created and whether the customer can direct

its use and obtain substantially all the remaining benefits from the software code, or (2)

whether the entity is unable to use the software code related to the customization for other

customers and whether the entity is legally entitled to payment for work completed to date. If

the entity is unable to demonstrate that control transfers over time, the presumption is that

control transfers at a point in time.

Further, entities evaluating these types of contracts need to consider whether the costs of

modifying or customizing the software qualify as costs to fulfill a contract that are required to

be capitalized in accordance with ASC 340-40.

Provision for loss

After adopting the standard, entities will still have to apply the guidance in ASC 985-605

(when contracts are determined to be within its scope) on the accounting for losses in a

contract to deliver software or a software system, either alone or together with other

products and services, that requires significant production, modification or customization.

That is, if a loss is probable on an unsatisfied or partially unsatisfied customized software

performance obligation (based on the amount of the transaction price allocated to it), the loss

should be recognized pursuant to ASC 450, Contingencies.

Migrating from on-premise software to SaaS (added January 2020)

Many traditional software entities are making their on-premise software licenses available to

customers over the internet as a SaaS offering. As an incentive for customers to migrate to

SaaS offerings, entities structure contracts in a variety of ways, such as incorporating conversion

options (see the “Material rights” section below) and remix rights (see the “Remix rights

”

section below) into their contracts or providing discounts on future purchases of SaaS.

Under some conversion options, customers cannot continue to use the on-premise software

after they move to the SaaS, while in other arrangements there may not be any restrictions

on the customers’ ability to move back and forth. These contract terms should be carefully

evaluated to determine the accounting implications.

EY AccountingLink |

ey.com/us/accountinglink

17 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

 EITF will address issues related to modifications of licenses of IP

The FASB has added a project to the agenda of the EITF to address diversity that has

arisen in accounting for contract modifications of licenses of IP under the revenue

standard. As part of this project, the EITF will address the accounting for contract

modifications in which rights conveyed by a license of IP are revoked in a migration from

on-premise software to SaaS (i.e., the on-premise license is revoked in exchange for SaaS).

The standard does not provide guidance on how an entity should account for the

revocation of rights to a license of IP.

If an explicit or implicit conversion option (i.e., an option to convert on-premise software to

SaaS) is not determined to be a material right, we believe it may be acceptable for an

entity to account for the option at contract inception as a right of return or to account for a

conversion prospectively when it occurs following the contract modification guidance in

ASC 606. Technology entities should select one approach and apply it consistently to

similar transactions until the EITF addresses the issue.

We encourage readers to monitor developments because any new guidance on this topic

could affect the accounting for these arrangements. Refer to our To the Point, The EITF will

address revenue recognition related to contract modifications for licenses of IP, for details.

Cloud services (added January 2020)

Cloud services refer to the delivery of numerous types of computing services over the

internet. There are various cloud service offerings, including:

•

Cloud applications or SaaS — These services provide customers with access to a wide

variety of software applications (e.g., enterprise resource planning, customer relationship

management, human capital management, payroll) over the internet.

•

Cloud platforms or platform as a service — These services provide customers with internet

access to application development platforms they can use to build or manage cloud

applications.

•

Cloud infrastructures or infrastructure as a service — These services provide customers

with internet access to computing infrastructure (e.g., storage).

•

Other cloud service offerings — These services provide customers with internet access to

other services, such as data as a service (e.g., analytics) or security as a service.

Determining the nature of the entity’s promise in cloud service arrangements

As described above (see the “Determining whether a contract contains a license of IP”

section), an entity must first evaluate whether its contracts provide a license of IP to

determine which accounting guidance to apply.

In our experience, it is uncommon for cloud service customers, especially SaaS customers, to

have the contractual right to take possession of software without penalty and run it in-house or

through an unrelated vendor. Therefore, cloud service arrangements generally do not provide

a license of IP and are not subject to the licensing guidance in the standard. Accordingly,

cloud service arrangements, including any fees that may be labeled as “software licensing

fees” in the arrangement, are generally accounted for as the transfer of a service (and not a

license of IP). Cloud service vendors need to evaluate the terms of their contracts to

determine whether a license of IP is provided.

EY AccountingLink |

ey.com/us/accountinglink

18 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Even if a contract contains a promise to deliver a license of IP to the customer, the contract

may also include provisions that allow the customer to convert its on-premise license to a

cloud service (most frequently to SaaS). Refer to the “

Migrating from on-premise software to

SaaS” section for further discussion.

When entering into contracts to provide cloud services (e.g., private cloud offerings), cloud

service vendors should first evaluate whether these contracts include lease components that

are in the scope of ASC 842, Leases (or ASC 840, Leases, for entities that haven’t yet adopted

ASC 842). The following sections assume that the cloud services do not contain lease components.

Applying the series guidance

Technology entities need to evaluate whether certain arrangements, including those for cloud

services, meet the criteria to be accounted for as a series of distinct goods and services.

Entities should evaluate whether the distinct goods and services in a contract that represent

separate performance obligations are substantially the same and have the same pattern of

transfer (i.e., the performance obligation is satisfied over time using the same measure of

progress). Goods and services that meet both criteria must be combined into one

performance obligation and accounted for as a series of distinct goods or services. That is,

accounting for goods or services as a series is required if the specified criteria are met.

The series provision often applies to cloud service contracts. For example, the customer may

have access to various SaaS modules (e.g., revenue, inventory, procurement) in an entity’s

SaaS financial management application. If the entity concludes that the nature of the promise

is to provide continuous access to its financial management application, each day of service is

likely distinct and substantially the same. However, because SaaS contracts are usually sold

with other goods and services (e.g., professional services), judgment may be required. The

following illustrates how a technology entity might evaluate performance obligations in a

SaaS contract:

Illustration 3 — Identifying performance obligations in a SaaS contract

SaaS provider A enters into a three-year contract with Customer X to provide access to its

SaaS basic customer relationship management (CRM) and human resource management (HRM)

applications (collectively referred to as SaaS applications) for $300,000. The contract also

includes professional services that will personalize the user’s interface based on the user’s

role. These services are sold separately from the SaaS applications and can be provided by

third-party vendors. The customer can benefit from the SaaS applications without the

professional services, which do not significantly customize or modify the SaaS applications.

SaaS provider A determines that the CRM and HRM applications and professional services

are distinct (i.e., the CRM and HRM applications and the professional services should not be

combined into a single performance obligation). The three services are each capable of

being distinct because Customer X can benefit from each of the SaaS applications and

professional services on its own. The services are distinct within the context of the contract

because the services are not highly interdependent or interrelated and each service does

not significantly modify or customize the other.

SaaS provider A first determines that the nature of the promise is providing continuous

access to its CRM and HRM applications for the three-year period. Although the activities

that Customer X may be able to perform using each of the SaaS applications may vary from

day to day, the overall promise is to provide continuous access to the CRM and HRM

applications to Customer X for a period of three years.

EY AccountingLink |

ey.com/us/accountinglink

19 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

SaaS provider A determines that access to the CRM application represents a series of

distinct services that are substantially the same and have the same pattern of transfer to

Customer X. Each day of service is capable of being distinct because Customer X benefits

each day from access to the CRM application. Each day is distinct within the context of the

contract because there are no significant integration services, each day does not modify or

customize another day, and each day is not highly interdependent or interrelated.

Each day of service is substantially the same because Customer X derives a consistent

benefit from the access to the CRM application and has the same pattern of transfer over

the term of the contract. Each distinct service represents a performance obligation that is

satisfied over time and has the same measure of progress (e.g., time elapsed). Therefore, the

criteria to account for access to the CRM application as a series of distinct services (i.e., a

single performance obligation) are met.

SaaS provider A performs a similar analysis for the access to the HRM application, determines

that it also represents a series of distinct services and accounts for it as a single performance

obligation. Like access to the CRM application, access to the HRM application is substantially the

same, has the same pattern of transfer and, therefore, meets the criteria in the series guidance.

Access to the CRM and HRM applications is provided to Customer X concurrently over

the term of the contract (i.e., coterminous), and the performance obligations have the

same pattern of transfer. SaaS provider A may account for access to the SaaS applications

as if they were a single performance obligation if the outcome is the same

as accounting

for the goods and services as individual performance obligations.

SaaS provider A also considers whether the professional services meet the criteria to be

accounted for as a series. As part of this assessment, SaaS provider A considers whether each

day of the professional services is distinct from the other days or whether the nature of the

promise for the professional services is for a combined output from all of the days. SaaS

provider A also considers the complexity of the professional services and whether the

activities each day build on those of the previous days or whether each day of activity is

substantially the same. This analysis requires judgment and is based on the facts and

circumstances of the professional services performed.

The series provision may also apply to other services provided by technology entities. The

following examples were discussed by the TRG,

and TRG members generally agreed that the

contracts in these examples should be accounted for under the series provision. Although

these examples are not specific to cloud services, they are helpful to illustrate application of

the series provision and may be instructive when evaluating cloud service arrangements.

Illustration 4 — Example of IT outsourcing

A vendor and customer execute a 10-year IT outsourcing contract under which the vendor

continuously provides server capacity, manages the customer’s software portfolio, runs an

IT help desk and provides other services. The monthly invoice is calculated based on

customer usage for each of the services, which is measured differently for each service

(e.g., based on millions of instructions per second of computer power used by the customer

for the server capacity services). The vendor concludes that the customer simultaneously

receives and consumes the benefits of the services as the vendor performs them (i.e., the

services meet the over-time criterion in ASC 606-10-25-27(a)).

The vendor first considers the nature of its promise to the customer. Because the vendor

has promised to provide an unspecified volume of services rather than a defined amount of

services, the TRG agenda paper noted that the vendor could reasonably conclude that the

nature of the promise is to stand ready to provide the integrated outsourcing service each day.

EY AccountingLink |

ey.com/us/accountinglink

20 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

If the nature of the promise is the overall IT outsourcing service, each day of service could

be considered distinct because the customer can benefit from each day of service on its

own, and each day is distinct within the context of the contract. The TRG agenda paper also

noted that the vendor could reasonably conclude that each day of service is substantially

the same. That is, even if the individual activities that comprise the performance obligation

vary from day to day, the nature of the overall promise is the same from day to day.

Illustration 5 — Example of transaction processing

A vendor enters into a 10-year contract with a customer to provide continuous access to

its system that processes transactions on behalf of the customer. The customer is

obligated to use the vendor’s system, but the quantity of transactions the vendor will

process is unknown. The vendor concludes that the customer simultaneously receives and

consumes the benefits as it performs.

If the vendor concludes that the nature of its promise is to provide continuous access to its

system rather than process a particular number of transactions, it might conclude that

there is a single performance obligation to stand ready to process as many transactions as

the customer requires. If that is the case, the TRG agenda paper noted that it would be

reasonable to conclude that there are multiple distinct time increments of the service. Each

day of access to the service provided to the customer could be considered substantially the

same since the customer is deriving a consistent benefit from the access each day, even if

a different number of transactions are processed each day.

If the vendor concludes that the nature of its promise is to process each transaction, the TRG

agenda paper noted that each transaction processed could be considered substantially the

same even if there are multiple types of transactions that generate different payments.

Further, the TRG agenda paper noted that each transaction processed could be a distinct

service because the customer could benefit from each transaction on its own and each

transaction could be distinct within the context of the contract.

Allocating variable consideration under the series guidance

Variable consideration (e.g., a user-based fee) is allocated to one or more (but not all)

performance obligations in the contract or one or more (but not all) distinct goods or services

in a series of distinct goods or services that make up a single performance obligation if both

criteria described in Step 4 in Appendix A are met (i.e., the variable consideration allocation

exception). This exception requires an entity to allocate variable consideration to the period

that relates to its efforts to satisfy the performance obligation (e.g., a distinct month of services).

The FASB noted in the Basis for Conclusions of ASU 2014-09

that this exception is

necessary because allocating contingent amounts to all performance obligations in a contract

may not reflect the economics of a transaction in all cases. Allocating variable consideration

entirely to a distinct good or service may be appropriate when the amount allocated to that

particular good or service is reasonable relative to all other performance obligations and

payment terms in the contract. Subsequent changes in variable consideration should be

allocated in a manner that is consistent with the initial allocation.

The TRG discussed

the following examples of when an entity would conclude that a contract

that is accounted for as a series of distinct goods or services meets the allocation objective and

would allocate variable consideration to a distinct period of service, such as day, month or year:

•

Consistent fixed prices — The TRG agenda paper described a contract to process an

unknown quantity of transactions for a fixed contractual rate per transaction. The

allocation objective could be met if the fees are consistent throughout the contract and

the rates are consistent with the entity’s standard prices for similar customers.

Entities that apply

the series guidance

are required to

allocate variable

onsideration to the

period in which the

services were

performed,

certain criteria

are

met.

EY AccountingLink |

ey.com/us/accountinglink

21 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

•

Declining prices — The TRG agenda paper described an IT outsourcing contract in which

the events that trigger the variable consideration are the same throughout the contract,

but the per-unit price declines over the life of the contract. The allocation objective could

be met if the pricing is based on market terms (e.g., if the contract contains a

benchmarking clause) or the changes in price are substantive and are linked to changes in

the entity’s cost to fulfill the obligation or the value provided to the customer.

Refer to the “Recognition of revenue from cloud service arrangements

” section below for a

discussion of how the variable consideration allocation exception guidance applies to several

types of cloud service arrangements.

How we see it

Applying the variable consideration allocation exception for a series of distinct services

may result in a revenue recognition pattern that is similar to the accounting for contingent

consideration under legacy guidance.

Recognition of revenue from cloud service arrangements (added January 2020)

How an entity recognizes revenue from cloud service arrangements will depend on the nature

of the performance obligation and on how fees are structured (e.g., fees are fixed, fees are

based on usage).

Entities need to carefully consider the nature of their performance obligations, particularly

when the contracts include user- or usage-based fees. In those cases, recognizing revenue

ratably may not be consistent with the standard’s objective of measuring progress, which is to

depict an entity’s performance in transferring control of goods or services promised to a

customer. Refer to the “Allocating variable consideration under the series guidance

” section

for further information.

Below we discuss some of the most common types of cloud service arrangements and the

revenue recognition patterns for each.

Fixed-fee arrangements (added January 2020)

As described in the “Applying the series guidance

” section, the nature of the performance

obligation related to a cloud service arrangement is often a series of distinct services to provide

access to the service for a period of time. In these cases, the service is typically provided on a

consistent basis from period to period (i.e., the performance obligation is satisfied evenly over

the period), and it is rare for a cloud service vendor to have a different pattern of performance.

Accordingly, we believe revenue for fixed-fee cloud service arrangements (i.e., no variable

consideration) should be recognized ratably over the contractual period, commencing on the

date the service is made available to the customer, unless the cloud service vendor’s

performance is not provided consistently from period to period.

When a cloud service vendor satisfies a performance obligation by transferring a promised

service, the cloud service vendor has earned a right to consideration from the customer and,

therefore, has a contract asset. If a cloud service vendor has an unconditional right to receive

consideration from the customer (i.e., nothing other than the passage of time is required before

payment of that consideration is due), the contract asset is accounted for as a receivable and is

presented separately from other contract assets. That is, the cloud service vendor recognizes a

contract asset when revenue recognized exceeds the amount that the cloud service vendor has

the contractual right to bill. This may occur when a multi-period cloud service arrangement

includes escalating fees (also called ramped pricing), but the performance obligation remains

the same in each period of the arrangement (e.g., the price per seat increases in each year of a

multiyear contract, but the total number of seats remains constant).

EY AccountingLink |

ey.com/us/accountinglink

22 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

A contract involving multiyear arrangements with escalating fees is illustrated below.

Illustration 6 — Multiyear SaaS with escalating annual payments

A SaaS provider enters into a three-year noncancelable contract with a customer to provide

access to its SaaS expense management application. At the beginning of each year, the

customer will make the following nonrefundable payments: $200,000 in the first year,

$250,000 in the second year and $300,000 in the third year.

The SaaS provider determines that the nature of the promise is to provide a series of distinct

services over the three-year contract term. Further, it determines that the performance

obligation is satisfied evenly over the contract term.

As such, the SaaS provider determines that the $750,000 total transaction price should be

recognized ratably over the contract term (i.e., $250,000 recognized each year). Note that

because of the escalating fees, the SaaS provider will also recognize a contract asset in the

amount of $50,000 in the first year to reflect the difference between the amount recognized

as revenue and the amount the SaaS provider billed to the customer in the first year. The

contract asset will reverse in the third year, when the amount billed to the customer in that

year exceeds the amount recognized as revenue.

Fixed-fee arrangements with overages (added January 2020)

Cloud service arrangements may have fixed fees (including any minimum amounts

guaranteed) but also require the customer to pay overage fees when they exceed certain

thresholds based on usage. When the cloud service provider’s performance obligation is to

stand ready to perform, regardless of customer usage, the overage fee is considered variable

consideration that the provider needs to estimate at contract inception, unless the variable

consideration allocation exception is met.

For example, consider a three-year contract for access to a SaaS application that allows the

customer to process transactions, among other functions. The customer agrees to pay an annual

fee of $100,000, plus overage fees at a rate of $0.1 per transaction for transactions processed

through the application during the year that exceed 1 million (i.e., overage fees are only paid if

the customer processes more than 1 million transactions during the year). Assume that the

SaaS provider has determined that the nature of its performance obligation is to provide

continuous access to the SaaS application, regardless of the number of transactions processed.

The SaaS provider determines that the $100,000 annual fee is fixed consideration, and all

additional consideration received as overage fees is variable consideration.

While the fixed component of the consideration will be recognized ratably over the contract

term, as described above, the SaaS provider will need to determine whether the variable

consideration allocation exception applies to the overage fees.

We believe that for the entity to apply the variable consideration allocation exception by

allocating overage fees to a particular day, the entity would have to conclude that the overage

fees relate to its performance on that particular day. Therefore, the entity in the example

above may conclude that it can’t apply the variable consideration allocation exception to the

daily reporting periods for the overage fees because those payments do not relate to its

efforts to satisfy the performance obligation to provide continuous access to the platform.

That is, the nature of the performance obligation is a series of daily stand-ready obligations

that are satisfied evenly over time, and the overage fees are additional consideration for

satisfying that performance obligation over the course of each year. Because the overage

fees are only incurred after the annual minimum is reached, recognizing revenue when the

fees are incurred would result in more revenue recognized for the periods after the minimum

is reached (i.e., backloading the revenue recognition), which is inconsistent with the allocation

EY AccountingLink |

ey.com/us/accountinglink

23 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

objective of ASC 606. Therefore, the criteria for using the variable consideration allocation

exception would not be met, and the entity would not recognize revenue for the overages on

the days when the fees are incurred.

If technology entities earn overage fees over a period of time that is less than the contract

term (e.g., in a multiyear contract where overage fees are accrued and reset on an annual

basis or another period), they should evaluate whether the overages can be allocated to the

period in which the overage fees are earned (e.g., to the annual period in which overages accrue).

Consider our example above for the three-year SaaS contract with annual overage fees. The

entity evaluates whether it can apply the variable consideration allocation exception to the

overage fees earned in each annual period in the three-year contract rather than to the daily

periods. The entity may conclude that it can apply the variable consideration allocation

exception to the overage fees earned in annual periods, which would require the entity to

allocate the annual overage fees to each of the three years (since the overages can be

attributed to a single year).

Therefore, the entity would estimate overage fees only for each annual period rather than for

the full three-year period at contract inception (which would be required if the variable

consideration allocation exception is not met for any period). This would result in recognition

of revenue from the overage fees only in the annual period to which the overages relate and

not over the entire contract term. In the example above, if the entity estimated that the

overage fees for the first year would be $20,000, it would recognize this amount ratably over

the year (i.e., $5,000 in each quarter).

Variable fee arrangements based on usage (added January 2020)

Consideration for some cloud service arrangements is based entirely on customer usage, and

the cloud service provider has a stand-ready obligation to perform, regardless of how often

the customer uses the platform. Therefore, the usage-based fees are variable consideration.

If the usage-based fees relate solely to the cloud service provider’s efforts to satisfy the

performance obligation to provide cloud services, the consideration can be allocated to the

period in which the usage occurred (assuming that this allocation is consistent with the

allocation objective in the standard).

Illustration 7 — Variable fee cloud service arrangement based on usage

Cloud provider C enters into a contract for cloud storage in which a customer agrees to pay

daily fees based on the amount of storage space it uses (i.e., a fixed daily rate of $0.025 per

gigabyte of storage is multiplied by the number of gigabytes used). Cloud provider C

invoices the customer at the end of each month. Assume that the entity has appropriately

concluded that the nature of the entity’s performance obligation is to stand ready to

provide any amount of storage space the customer needs at any time during the contract

term, and the consideration in the contract is variable based on the number of gigabytes of

storage used (and, therefore, each gigabyte used is not an optional purchase).

Cloud provider C determines that the service provided to the customer in this contract

meets the criteria to be accounted for as a series of distinct goods or services. This is

because the performance obligation to stand ready to provide any amount of storage space

represents a series of distinct services that are substantially the same and have the same

pattern of transfer to the customer.

Each day of service is capable of being distinct because the customer benefits each day

from access to the cloud storage. Each day is distinct within the context of the contract

because there are no significant integration services, each day does not modify or

customize another day and each day is not highly interdependent or interrelated.

EY AccountingLink |

ey.com/us/accountinglink

24 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Each day of service is substantially the same because the customer derives a consistent

benefit from the access to the cloud storage and has the same pattern of transfer over the

term of the contract. Each distinct service represents a performance obligation that is

satisfied over time and has the same measure of progress (e.g., time elapsed). Therefore,

the criteria to account for access to the cloud storage as a series of distinct services (i.e., a

single performance obligation) are met.

Cloud provider C then considers whether the variable consideration allocation exception

would apply to the daily usage-based fees. The entity would be required to allocate usage-

based fees to each day if the entity determines that the payment relates specifically to the

entity’s efforts to satisfy the performance obligation for each day and that allocating the

variable consideration to each distinct day is consistent with the allocation objective.

Cloud provider C determines that it meets the first criterion to allocate the daily variable

fee to the distinct service performed that day because the uncertainty related to the

consideration is resolved on a daily basis as the entity satisfies its obligation to provide

cloud storage. This is because the variable payments specifically relate to transferring the

distinct service: access to any amount of cloud storage that the customer chooses to use

each day.

Cloud provider C concludes that allocating the variable payments to each day is consistent

with the allocation objective because the fixed-rate-per-gigabyte fees reflect the value to

the customer based on the amount of storage the customer uses each day. Further, the

rates charged are consistent with Cloud provider C’s standard pricing practices.

Therefore, Cloud provider C determines that it can apply the variable consideration allocation

exception and recognizes each day’s fee for the day in which it occurs. That is, if the

customer uses 250 gigabytes of storage the first day and 300 gigabytes the second, Cloud

provider C will recognize $6.25 and $7.50 of revenue for the respective days.

If the usage-based fees do not relate to the cloud service provider’s efforts to satisfy the

performance obligation, the variable consideration is estimated at contract inception and

recognized ratably over the contract term. These estimates of variable consideration must be

updated at the end of each reporting period.

User-based arrangements (added January 2020)

In some cloud service arrangements, consideration depends on the number of users with

access to the service. Technology entities will need to determine whether such fees represent

a usage-based fee as described in the “Variable fee arrangements based on usage

” section or

whether they represent optional purchases (see the “Variable consideration and options for

additional goods and services” section for additional details) based on the rights and obligations

of each party to the contract.

If the contract includes a customer option, the technology entity is not obligated to provide

additional goods and services until the customer makes a separate purchasing decision

(i.e., exercises the option). That is, the entity’s performance obligation at contract inception is

to provide the quantity of goods or services specified in the contract.

Consider a contract with a customer to purchase a two-year subscription to a SaaS finance

management application for 50 users for $100,000. The contract states that the customer

can add additional users during the two-year period at a price of $800 per user per year,

prorated for the precise period of access to the service.

EY AccountingLink |

ey.com/us/accountinglink

25 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The entity determines that its performance obligation is to provide continuous access to the

SaaS application for 50 users for the two-year term. The entity concludes that it has provided

the customer with an option to purchase subscriptions for additional users because the entity

is not obligated to provide access for the additional users until the customer makes a

purchasing decision. At contract inception, the entity begins recognizing revenue ratably for

the $100,000 related to the original 50 users over the two-year term. As additional users

obtain access, the entity begins recognizing the additional consideration owed over the

remaining contract term.

When the addition of new users is considered an optional purchase, providing access to each

new user is likely a distinct performance obligation that will be recognized ratably over the

related contract term. However, performance obligations that have the same pattern of

transfer over the same period can be accounted for as a single performance obligation

(e.g., the original 50 users in the example above) since accounting for them together would

result in the same treatment as accounting for them as separate performance obligations.

Therefore, after the customer exercises the option to add new users, an entity can combine

the new users into one performance obligation if they all receive access to the SaaS for the

same term.

Technology entities that consider the addition of new users an optional purchase will have to

evaluate the option to determine whether it represents a performance obligation for a

material right to which some of the transaction price should be allocated at contract inception.

Conversely, when the addition of new users is considered variable consideration, a technology

entity will have to evaluate whether the variable consideration allocation exception is met or

whether it is required to estimate variable consideration at contract inception as part of the

total transaction price.

Estimating standalone selling prices in cloud service contracts (added January 2020)

When a cloud service is not the only performance obligation in a contract, a technology entity

will need to allocate the transaction price to the performance obligations based on their

relative standalone selling prices (with certain exceptions for allocating discounts and variable

consideration). Determining the standalone selling price for a cloud service may require

significant estimation and judgment because the technology entity may charge different

prices in different arrangements.

The best evidence of the standalone selling price of cloud services is the observable price

when they are sold separately. If this information is not available, a technology entity must

estimate the standalone selling price. When estimating the standalone selling price, a

technology entity needs to prioritize the use of observable inputs and consider all information,

including both market conditions and entity-specific factors.

Examples of market conditions that cloud service vendors might consider when estimating the

standalone selling price for these services include:

•

The extent of competition in the market

•

Competitor pricing for a similar or identical service (e.g., a competing customer

relationship management SaaS)

•

Geographic area effects on pricing

EY AccountingLink |

ey.com/us/accountinglink

26 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Examples of entity-specific factors cloud service vendors should consider when estimating

standalone selling prices for these services include:

•

The internal pricing practices, including:

• The profit objectives and internal cost structure

• Discounts provided when multiple cloud services are bundled together (e.g., human

capital management and payroll) or are bundled with other services, such as

professional services

• Pricing based on the number of users in the arrangement, including seasonal, part-

time or full-time users, and cloud services sold on an unlimited basis

•

The size of the contractual agreement (e.g., based on the amount of consideration or the

number of users), the term of the contractual agreement and the characteristics of the

targeted customer

•

Contractually stated renewal rates included in contracts

We believe it may be appropriate for entities to stratify selling prices to help them estimate

standalone selling prices. A cloud service vendor’s pricing for a product or service may depend on

the type or size of customer, the amount of product or services purchased, geographic location

or other factors (e.g., distribution channel). Accordingly, a vendor may choose to stratify its

analysis to determine its estimate of the standalone selling price for each class of customer.

Hardware sold with cloud services (added January 2020)

With the rise of the Internet of Things, an increasing number of connected hardware devices

are available, ranging from security cameras to home equipment. In contracts where a

customer purchases hardware, the hardware may require the installation of an app or the

purchase of a cloud service subscription in order to be used, or the hardware may provide

additional functionalities when paired with the cloud service.

To identify performance obligations in contracts containing multiple promises (e.g., hardware

and cloud services), technology entities must determine whether the hardware and cloud

services are each capable of being distinct and whether they are distinct within the context of

the contract.

In performing this evaluation, technology entities should consider whether the hardware can

be used without the cloud service, how the hardware and cloud service affect each other

(e.g., whether the cloud service enables the hardware to “learn” or perform its intended

function better over time), whether there are additional functionalities that result from using

the hardware with the cloud service, and other details of how the hardware and cloud services

function and are sold.

Illustration 8 — Hardware sold with cloud services

Consider a contract to provide a smart home security camera bundled with cloud services,

which enable the customer to view live images from the camera in an app on internet-

connected devices (e.g., tablets, phones). The entity also provides the cloud services to

customers who purchase the camera through secondary markets.

The entity concludes that the customer can benefit from each of the goods and services

either on its own or together with other goods or services that are readily available. That is,

each good or service is capable of being distinct under ASC 606-10-25-19(a).

EY AccountingLink |

ey.com/us/accountinglink

27 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The camera is capable of being distinct because the customer can benefit from it together

with the cloud services, which are a readily available resource since they can be obtained

separately. Further, the customer can benefit from the camera because it can be resold

through secondary markets for more than scrap value.

The cloud services are capable of being distinct because the customer can benefit from

them together with the camera transferred at the outset of the contract or the customer

can purchase the camera separately through the secondary markets and obtain the cloud

services from the entity.

The entity then considers the factors in ASC 606-10-25-21 and determines that the promise

to transfer each good and service is distinct within the context of the contract. In reaching

this conclusion, the entity notes that it does not provide a significant service of integrating

the cloud services with the camera into a combined output, and the cloud services and the

camera do not significantly modify or customize one another.

The entity also determines that the camera and the cloud services are not highly

interdependent or highly interrelated because the entity can fulfill its promise to transfer

the cloud services independently from its promise to provide the camera (since customers

can purchase the camera in secondary markets). Further, because the cloud services

provide only the basic functionality of connecting the camera to a personal device using

Wi-Fi instead of a traditional electrical cord, the utility the customer can derive from the

camera and the cloud services, when transferred together, is not greater than or

substantially different from the utility the customer would receive if the camera and cloud

services had been transferred separately. As a result, the entity identifies two performance

obligations: the camera and the cloud services.

Technology entities will need to evaluate the specific features and functionality of the cloud

services in arrangements that include connected devices. Evaluating whether hardware and

cloud services are separate performance obligations in arrangements for connected devices

may be complex and require significant judgment when the cloud service has sophisticated

features or functionality that the device cannot do independently. In these cases, there may

be an interdependency between the hardware and the cloud service.

How we see it

To conclude that hardware and a cloud service are a single performance obligation,

technology entities will need to demonstrate that the functionality of both the hardware and

the service is significantly elevated when they are used together. Many technology entities

have concluded that they have separate performance obligations because the hardware and

the cloud service do not significantly affect each other and because the hardware can be sold

separately from the cloud service.

We note that, as part of its comment letter process, the SEC staff may request that

technology companies provide a comprehensive analysis to support a conclusion that one or

more promises should be accounted for as a combined performance obligation.

Identifying other performance obligations commonly found in

technology contracts

The following discussion of other promises that are commonly included in technology contracts

and considerations for evaluating whether these promises represent performance obligations

may be relevant for all technology contracts, including those that contain a software license.

EY AccountingLink |

ey.com/us/accountinglink

28 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Material rights (updated January 2020)

Under some contracts, a technology entity provides a customer with the option to purchase

additional goods or services or renew a contract at a stated price. These options are separate

performance obligations only if they provide a material right that the customer would not

receive without entering into the contract (e.g., a discount that exceeds the range of

discounts the entity typically provides for those goods or services to that class of customer in

that geographical area or market).

If an option is determined to be a separate performance obligation, a technology entity

allocates a portion of the transaction price to the material right, based on its relative

standalone selling price, and recognizes the allocated amount when it transfers those future

goods or services or when the option expires. Evaluating whether an option provides a

material right may be more complex when the standalone selling price of the good or service

is highly variable, as illustrated below.

Illustration 9 — Evaluating a customer option when the standalone selling price is

highly variable

Technology entity Y enters into a contract with Customer Z for a perpetual license of

software A with one year of PCS. The contract also includes an option to purchase

additional licenses of software A at 40% off the list price.

The entity does not sell software A separately, but it sells PCS separately in the form of

renewals that are consistently priced at 20% of the net license fee. Assume that

Technology entity Y uses the residual method to estimate the standalone selling price of

the perpetual license for software A. Also assume that the price Technology entity Y

charges for the bundle of the perpetual license with PCS is highly variable. That is because

the price Technology entity Y charges ranges from list price to a discount of up to 70% for

the bundle to customers in the same class and same market as Customer Z who have not

made prior purchases. (Assume that the entity has appropriately stratified its

contracts/customers to evaluate the range of discounts and has a sufficient amount of

transactions to support that this is the range of discounts it offers.)

Because the 40% discount Technology entity Y offered to Customer Z is within the range of

discounts it typically offers to customers in the same class as Customer Z, Technology

entity Y concludes that this option does not represent a material right.

A technology entity that provides a customer with cloud services and an option to purchase

additional goods or services would perform the same evaluation, and a similar approach may

be taken for evaluating whether the option provides a material right in situations with highly

variable pricing.

Volume discounts or tiered pricing can make the assessment of whether a customer option to

purchase additional goods or services is a material right more complex, as illustrated below.

Illustration 10 — Evaluating a customer option with volume discounts

Semiconductor Entity S sells microchips for use in cell phones. The entity executes a contract

with a customer to sell 1 million units of microchip M for $0.50 each, or $500,000. The

contract provides the right for the customer to purchase an additional 200,000 microchips for

$0.40 each, effectively bringing the price for all 1.2 million microchips to $0.48 per microchip.

The accounting for

options to provide

additional goods

services depends

on whether the

option provides a

material right.

EY AccountingLink |

ey.com/us/accountinglink

29 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The entity concludes that it has provided the customer with an option to purchase the

additional microchips since the entity is not obligated to provide the additional goods until

the customer makes a purchasing decision. Further, the volume discount is applied

prospectively and does not affect the transaction price in the original contract.

Scenario A: For microchip M, Semiconductor Entity S provides volume discounts as part of

its standard pricing practices and typically prices the first 1 million microchips at $0.50

each, the second million at $0.40 each and any additional amounts at $0.35 each.

Semiconductor Entity S considers whether the option provides the customer with a

material right. To make this evaluation, the entity compares the discount offered in this

option with the discount it typically offers to a similar high-volume customer that receives a

discount without having had a prior contract. In other words, the entity compares the

pricing in this contract to the pricing it typically offers to customers that purchase between

1 million and 2 million units of microchip M without having made any prior purchases.

The entity has sold and continues to sell the same volume of microchip M at the same price

to other customers in the same class of customer who have not made prior purchases

(i.e., similar customers pay $0.50 each for the first 1 million microchips and $0.40 each for

the second million). That is, the price offered to the customer in the option exists

independently of the existing contract. Therefore, Semiconductor Entity S concludes that it

has not provided the customer with a material right.

Scenario B: For microchip M, Semiconductor Entity S provides volume discounts as part of

its standard pricing practices and typically prices the first 3 million microchips at $0.50

each and any additional amounts at $0.30 each.

Semiconductor Entity S considers whether the option provides the customer with a

material right. To make this evaluation, the entity compares the discount offered in this

option with the discount it typically offers to a similar high-volume customer that receives a

discount without having had a prior contract.

For similar high-volume customers of the same customer class who have not made prior

purchases, the entity typically does not provide this pricing (e.g., similar customers would

pay $0.50 per microchip for all 1.2 million microchips). Therefore, the entity concludes

that it has provided the customer with a material right.

Careful consideration should be given to whether the discount is offered to the customer

independently of the existing contract.

If the customer is, in effect, paying the entity in

advance for future goods or services, the option represents a material right.

An entity that concludes that an option is a separate performance obligation has to determine

the standalone selling price of the option. As part of estimating the standalone selling price of

an option, the entity should consider the additional discount that is provided by the material

right (i.e., adjust for any discount that the customer could receive without exercising the

option). Additionally, for goods or services that are both similar to the original goods or services

in the contract and are provided in accordance with the terms of the original contract,

ASC 606-10-55-45 provides an alternative to estimating the standalone selling price of an

option (commonly referred to as the renewal option approach). See section 6.1.5 of our FRD

publication, Revenue from contracts with customers (ASC 606)

, for additional information on

the renewal option approach.

EY AccountingLink |

ey.com/us/accountinglink

30 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

How we see it

Significant judgment may be required to determine whether a customer option represents

a material right. This determination is important because it affects the accounting and

disclosures for the contract at inception and throughout the life of the contract.

While the concept of a material right is similar to the concept of an option that must be

accounted for under legacy guidance, the criteria are different. As a result, some entities

that have adopted the standard have reached different conclusions from their legacy

GAAP accounting about whether to account for an option.

That is, an option is no longer evaluated to determine whether it is significant and

incremental to the range of discounts reflected in the pricing of the other elements in the

contract. Instead, under the standard, an entity evaluates whether an option provides the

customer with a material right (e.g., a discount that exceeds the range of discounts the

entity typically gives for those goods or services to a new customer in that class in that

geographical area or market).

Nonrefundable up-front fees (updated January 2020)

When a customer pays an up-front fee at contract inception, a technology entity must

evaluate whether the nonrefundable up-front fee relates to the transfer of a good or service.

The existence of such a fee may indicate that there are promises in the contract, such as the

option to renew PCS at a discounted rate or implementation/installation services that may or

may not be required for the customer to use and benefit from an outsourcing or cloud service

contract. That is, if the customer can renew the agreement without paying an additional up-

front fee, the entity would need to determine whether the renewal option is a material right

(i.e., another performance obligation in the contract) that effectively gives the customer a

discount from the price a similar new customer would have to pay.

In some cases, nonrefundable fees relate to activities that an entity is required to perform at

or near contract inception. The entity must consider whether performing these activities

transfers promised goods or services that are performance obligations in the contract.

Activities that the entity must undertake to fulfill a contract (e.g., certain installation and

setup activities) that do not transfer a good or service to the customer are not a promised

good or service in the contract. Technology entities should consider the nature of the services

being performed when making this assessment.

Illustration 11 — Nonrefundable up-front fee in perpetual software license arrangement

is a material right

Technology entity F enters into an arrangement with a customer for a perpetual software

license to antivirus software with one year of PCS for $1,180,000. The contract provides

the customer with the ability to renew PCS annually for $180,000 (or 18% of the net

license fee). Technology entity F has determined that the software license and PCS are

combined into a single performance obligation for its antivirus software because the

updates provided by the PCS significantly modify the functionality of the software and are

integral to maintaining the utility of the software license to the customer.

Because the software license and PCS have been combined into a single performance

obligation, a one-year renewal of the PCS is effectively a one-year renewal of the software

license and PCS (i.e., the combined offering). However, because the contract contains an

option to renew the PCS for $180,000 in subsequent years (rather than the $1,180,000 paid

for the same combined performance obligation in the initial year of the contract), Technology

entity F considers whether the renewal option provides the customer with a material right.

Nonrefundable up

front fees may

indicate that a

con

tract contains a

material right

to a

discount at renewal

that must be

accounted for.

EY AccountingLink |

ey.com/us/accountinglink

31 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Technology entity F typically sells a perpetual license to the antivirus software with one

year of PCS (i.e., the one-year combined performance obligation) to similar new customers

for prices ranging from $1,000,000 to $1,300,000. Therefore, Technology entity F

determines that the options to renew the combined performance obligation in subsequent

years for $180,000 represent material rights, and the entity allocates some of the initial

transaction price to the material rights.

Based on the number of anticipated renewals and the estimated life of the technology,

Technology entity F determines that the estimated performance period for the material

rights is four years. Therefore, the consideration allocated to the material rights is recognized

over the four-year estimated performance period or when the renewal option expires.

Illustration 12 — Nonrefundable up-front fee in perpetual software license arrangement

is not a material right

Technology entity K enters into a contract with a customer for a perpetual license to

financial data analytics software and one year of PCS for $800,000. The contract provides

the customer with the ability to renew PCS annually for 20% of the net license fee (or

approximately $330,000). Technology entity K routinely prices PCS at 20% of the net

license fee for perpetual license arrangements.

Assume that Technology entity K has determined that the license and PCS are two

separate performance obligations because the updates are not critical to the ongoing

functionality of the software.

Technology entity K considers whether the nonrefundable up-front fee of $800,000 paid

only in the first year indicates that it has provided the customer with a material right. Unlike

the situation in Illustration 11, the customer is only renewing the PCS since it is a separate

performance obligation from the software. The nonrefundable up-front fee in this contract

relates to the transfer of the software license, which is only provided in the first year. Because

the renewal rate of 20% of the net license fee is provided to other customers purchasing only

PCS, Technology entity K concludes that it has not provided the customer with a material right.

How we see it

The entity evaluates whether the nonrefundable up-front fee creates a material right. If

the entity concludes that the nonrefundable up-front fee does not provide a material right,

the fee is part of the consideration allocable to the goods or services in the contract and is

recognized as the good or service to which the consideration is allocated is transferred to

the customer. If an entity concludes that the nonrefundable up-front fee provides a

material right, the amount of the fee allocated to the material right is recognized over the

period of benefit of the fee, which may be the estimated customer life.

This contrasts with legacy guidance from SEC Staff Accounting Bulletin Topic 13, where

nonrefundable up-front fees not paid in exchange for products delivered or services

performed (representing the culmination of the earnings process) were deferred and

recognized over the estimated customer relationship period.

Implementation services (updated January 2020)

Technology entities frequently include promises to provide implementation services to customers

as part of their software or cloud service contracts (i.e., these implementation activities have been

determined to transfer a service to the customer). These services, which can include loading of

software, training of customer personnel and data conversion, need to be assessed using the

entity’s facts and circumstances to determine whether they are separate performance obligations

(i.e., they are capable of being distinct and are distinct within the context of a contract).

EY AccountingLink |

ey.com/us/accountinglink

32 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

In assessing whether implementation services are capable of being distinct, an entity first

considers whether the customer can benefit from those services on their own. There is strong

evidence to suggest that implementation services are capable of being distinct if third party

vendors offer (or are capable of offering) implementation services for the entity’s software or

cloud services, or if the customer could perform these services on its own. This evidence

would demonstrate that the implementation services provide benefit to the customer on their

own (e.g., apart from the software or cloud services purchased from the technology entity).

If the entity concludes that the customer is not able to benefit from the implementation services

on their own, the entity considers whether the customer can benefit from the services together

with other readily available resources. Readily available resources include the software or cloud

service from the contract if it is sold separately by the entity or if it is transferred to the

customer before the implementation services. An entity should disregard any contractual

limitations that prevent the customer from obtaining readily available resources from a party

other than the entity when making this assessment. That is, contractually restricting a customer

from using another vendor to perform the installation services would not preclude a technology

entity from determining that the implementation services are capable of being distinct.

In assessing whether the implementation services are distinct within the context of the

contract, an entity needs to consider whether the implementation services modify or

customize the software or cloud services, whether the entity is providing a significant service

of integrating the software or cloud services with the implementation services into one

combined output or whether the entity would be able to fulfill its promise to transfer the

software or cloud services in the contract independently from its promise to provide the

implementation services (i.e., whether the implementation services are highly interdependent

or interrelated with the software or cloud services). This evaluation may require judgment and

is based on the facts and circumstances of the entity’s contracts.

Illustration 13 — Implementation services are not a promised good or service

SaaS vendor A enters into an arrangement with a customer for a two-year SaaS

subscription. The contract requires the customer to pay $125,000 at the beginning of the

first year and $100,000 at the beginning of the second year. The contract indicates that

the $125,000 consideration paid in the first year includes a $25,000 fee related to

implementation and installation services. However, these implementation and installation

services just refer to the creation and activation of the customer’s account, which SaaS

vendor A must do to provide the SaaS.

Based on the nature of these implementation and installation services, SaaS vendor A

determines that they are administrative, setup activities and do not transfer control of a

good or service to the customer. Therefore, SaaS vendor A determines that the

implementation and installation services are not a promise in the contract. SaaS vendor A

concludes that the SaaS is the only promised good or service and, therefore, the only

performance obligation in the contract.

Assume that SaaS vendor A concludes that the SaaS performance obligation is satisfied

over time and that a time-based measure of progress is appropriate. SaaS vendor A

recognizes the total consideration of $225,000 ratably over the two-year term.

EY AccountingLink |

ey.com/us/accountinglink

33 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Illustration 14 — Implementation services are distinct

Technology entity P enters into an arrangement with a customer to perform

implementation services and to provide SaaS for a three-year period. The entity sells the

SaaS and implementation services separately. The implementation services include

changing the layout of the main dashboard for each type of user (e.g., marketing, finance)

and do not alter the source code of the underlying software or add any new functionality.

The implementation service is routinely performed by third parties and does not

significantly modify or customize the SaaS.

Technology entity P evaluates the promised goods and services to determine which

promises should be accounted for as separate performance obligations.

Technology entity P concludes that the implementation services are capable of being

distinct because they can be used with the SaaS, a readily available resource, and because

they can be purchased from third parties. Further, the implementation services are distinct

within the context of the contract because they are routine and do not significantly modify

or customize the SaaS, are not integrated with the SaaS into a combined output, and are

not highly interdependent or interrelated to the SaaS since the entity can fulfill its promise

to transfer the SaaS independently from its promise to provide the implementation services.

Based on this assessment, Technology entity P identifies two performance obligations: the

SaaS and the implementation services.

Illustration 15 — Implementation services are not distinct

Consider the same promised goods or services as in Illustration 14, except that the nature of

the implementation services is to set up data feeds and interfaces with third-party applications

and to connect the customer’s SaaS account to Technology entity P’s infrastructure.

Technology entity P does not sell the SaaS without the implementation services and the

customer cannot use the SaaS until the implementation services are complete, which may

be up to nine months after entering into a contract. The implementation services cannot be

provided by other entities as they require access to Technology entity P’s systems.

Technology entity P evaluates the promised goods and services to determine which

promises should be accounted for as separate performance obligations. The SaaS is capable

of being distinct because it can be used together with the implementation services that are

provided at the outset of the contract. However, the implementation services are not capable

of being distinct because they are not sold separately by the Technology entity P, cannot be

provided by a third party and do not provide benefit to the customer without SaaS (which is

not a readily available resource).

Based on this assessment, Technology entity P identifies one performance obligation: the

implemented SaaS (comprising the SaaS and implementation services). Technology entity P

should consider whether any up-front fees provide the customer with a material right with

respect to future renewals of the SaaS.

Post-contract customer support or maintenance services (updated January 2020)

Many contracts involving software or cloud services also include promises to provide

unspecified upgrades, updates and enhancements (collectively referred to as unspecified

upgrades) along with technical customer support and bug fixes after the license period begins

(collectively, PCS). Technology entities need to evaluate whether the individual services that

comprise PCS are distinct and, therefore, separate performance obligations.

The individual

services that

comprise PCS

may

be separate

performance

obligations.

EY AccountingLink |

ey.com/us/accountinglink

34 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Entities also need to evaluate whether unspecified upgrades are a separate performance

obligation from the software license or other services in the contract. Refer to the “

Licenses

of IP” section above.

When unspecified upgrades are a separate performance obligation in the contract, the technology

entity needs to determine the appropriate measure of progress that best reflects the transfer

of control to the customer. In doing so, technology entities need to consider the nature of the

promise to the customer, which generally is a stand-ready obligation, as discussed by the TRG.

Since the nature of the entity’s promise is fundamentally a guarantee to make available to the

customer any upgrades it develops during the period on a when-and-if-available basis, the

customer benefits evenly throughout the contract period from the assurance that it will have

access to these future upgrades. Therefore, a straight-line measure of progress (i.e., ratable

revenue recognition) is generally appropriate. The FASB staff also indicated

that the FASB

didn’t intend to change how entities determine what constitutes a specified or unspecified right.

In situations where bug fixes and technical customer support are provided outside of PCS to make

sure the product functions as promised, they may be part of the assurance warranty coverage and,

therefore, would not be revenue elements. Such warranties are accounted for under ASC 460-10,

Guarantees — Overall. If the technology entity determines that the bug fixes or customer support

(or both) are not part of the assurance warranty, it needs to determine whether they are separate

performance obligations and whether the nature of the promise is a stand-ready obligation.

How we see it

Technology entities need to evaluate whether unspecified upgrades and customer support

are separate performance obligations. An entity may account for the unspecified upgrades

and customer support that are not part of the assurance warranty as a single performance

obligation if it concludes that they have the same pattern of revenue recognition over the

same period (e.g., both ratable over the contract term) because that would result in the

same treatment as accounting for the performance obligations separately.

Most technology entities have concluded that it is appropriate to account for unspecified

upgrades and customer support that are provided on a when-and-if-available basis as a

combined performance obligation and to recognize revenue associated with this

performance obligation on a straight-line basis over the contract term. This is because

unspecified upgrades and customer support are both stand-ready obligations satisfied

evenly over the contract term (i.e., they have the same pattern of revenue recognition

over the same period).

Specified upgrades (updated January 2020)

Technology entities may provide customers with the right to specified upgrades or enhancements

as part of a software or cloud service contract. Under the standard, technology entities need

to evaluate whether the rights to receive specified upgrades or enhancements are promised

goods or services and separate performance obligations. If the specified upgrade is a separate

performance obligation, a portion of the transaction price is allocated to it, and recognition of

that amount of revenue is deferred until the specified upgrade is provided.

Distinguishing between specified and unspecified upgrades (added January 2020)

The TRG indicated

that technology entities should carefully consider whether a contract

includes a promise of one or more specified upgrades, even if the contract only refers to

unspecified upgrade rights provided on a when-and-if available basis as part of PCS.

Determining when a specified upgrade right has been provided to a customer if a contract

does not explicitly include such a right may require judgment.

EY AccountingLink |

ey.com/us/accountinglink

35 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The key consideration in making this determination is whether the vendor has provided a level

of information to its customers regarding the features, functionality and release date of future

product enhancements in sufficient detail that the vendor has created a valid expectation by

the customer that it will receive a specific upgrade/enhancement. Key factors to consider in

making this judgment include:

•

What level of detail regarding the features, functionality and the anticipated release date of

future product enhancements has been provided to the customer? Generally, the greater the

level of detail contained in communications to the customer, and the closer the anticipated

release date of the enhancements is to the origination of the arrangement with the customer,

the more likely it is that the customer has an expectation about the release of the future

product enhancement(s) that has affected its current purchasing decision. Technology

entities will need to consider any information provided to customers in roadmaps (i.e., product

development plans, press releases, information on a website, marketing collateral, executive

presentations or other information made available to customers), including the specificity

of descriptions of any future features and functionality and the related release dates, to

determine whether the customer has a valid expectation of specified upgrades.

•

Is the communication of a general nature made available to all customers or to an entire

class of customers, or is it specific to one or a few customers? Although the form of

communication will not determine whether a specified upgrade right exists, it is important

to understand the form of communication to evaluate the factors discussed above in their

proper context. Generally, it is less likely that information broadly communicated to all

customers, or an entire class of customers, will create an expectation by any individual

customer that it will receive a specific upgrade/enhancement, although customer-wide

communications may be designed to create such an expectation (e.g., roadmaps following

mergers of entities providing competing products). Conversely, it is more likely that a

communication made to one or a few customers would create such an expectation.

•

Has the vendor used caveats in describing its plans to deliver an upgrade/enhancement that

can be judged to have created a reasonable amount of uncertainty in the mind of a customer

about whether it will actually receive such an upgrade/enhancement? Many software

entities include caveats in their written arrangements with customers that require the

customer that is signing the written arrangement to acknowledge that (1) it has not relied

on any information outside the written arrangement or (2) its rights to publicly announced

upgrades or other marketed upgrades are expressly limited. Additionally, many vendors

include language in marketing collateral, on their websites or in other materials indicating

that the determination of when enhancements to its current products will be made available, if

ever, remains at the vendor’s sole discretion and that the information contained in such

communications does not constitute a commitment to deliver an upgrade/enhancement. This

kind of language may create a reasonable amount of uncertainty in the customer’s mind

about whether they will ever receive a specific upgrade/enhancement.

•

Are there any consequences for the entity if it doesn’t provide specific new features or

functionalities to the customer? If the customer has recourse against the entity in the

event that those specific new features or functionalities are not provided, that may

suggest that a specified upgrade has been promised to the customer.

EY AccountingLink |

ey.com/us/accountinglink

36 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

How we see it

Entities that license software are likely to recognize some revenue from contracts that involve

specified upgrades earlier than they did under legacy guidance. Under the standard, if the

specified upgrade is determined to be a separate performance obligation, only the revenue

allocated to that upgrade is deferred. Under legacy guidance, by contrast, entities that

license software were often unable to separate the delivered elements from the specified

upgrade because VSOE of fair value was generally unavailable for the specified upgrade.

Applying ASC 606 may not significantly change revenue recognition for cloud service

providers that had historically accounted for specified upgrades as separate deliverables by

using the best estimate of selling price under the multiple-element arrangement guidance.

Technology entities also may find it challenging to determine the standalone selling price for

specified upgrades that are determined to be separate performance obligations. To determine

the standalone selling price, technology entities should first consider the price they charge

existing customers for the upgrade (if it has previously been offered to customers). If the

standalone selling price is not directly observable, technology entities must estimate it.

When developing an estimate of standalone selling price for specified upgrades, entities may

consider factors such as the planned list price (including any considerations from internal

pricing discussions), the standalone selling price of similar goods or services, the costs to

deliver the specified upgrade plus a reasonable margin, or any penalties for failure to provide

the specified upgrade. In their evaluation, entities should maximize the use of observable

inputs and apply estimation methods consistently in similar circumstances.

Unspecified additional software products (updated January 2020)

As part of a contract with a customer, a technology entity may license software and promise

to deliver unspecified additional software products in the future. For example, the technology

entity may agree to deliver all new products in a family of products over the next two years.

Under the standard, technology entities must determine whether the promise to deliver

unspecified additional software products is a separate performance obligation from the

license. Technology entities also need to evaluate whether the promise to deliver unspecified

additional software products is a stand-ready obligation to provide future products on a when-

and-if-available basis or if enough specific detail has been provided to the customer about

upcoming products to be released such that the contract contains individual promises to

deliver specified future products.

A performance obligation for unspecified additional software products is recognized ratably

over the contract term, like unspecified upgrades. If a technology entity determines that it has

promised individual specified future software products that are determined to be separate

performance obligations, any transaction price allocated to them will likely be recognized at

the point in time that the future products are made available to the customer.

How we see it

This guidance changes how a technology entity accounts for unspecified future products

and requires more analysis and judgment than legacy practice. Under legacy software

guidance, unspecified additional software products were accounted for as subscriptions,

and all revenue from the arrangement was recognized ratably over the term of the

arrangement beginning with delivery of the first product.

EY AccountingLink |

ey.com/us/accountinglink

37 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Remix rights (updated January 2020)

A technology entity may provide a customer with the right to choose and change the mix of

software licenses and/or cloud services to use over the contract term (i.e., remix rights) in

addition to PCS and unspecified additional software products. Some of these contracts, however,

include limits, such as a cap on the number of users who can simultaneously use the products.

We believe these remix rights will typically be considered attributes of the underlying software

licenses, cloud services or other services in the arrangement. That is, the remix rights are not

separate promises because they do not create an obligation to transfer additional rights.

However, entities must consider whether each of the underlying software licenses and services

that a customer can use because of the remix rights is a separate performance obligation.

To do this, entities must first evaluate whether the promises (e.g., each licensed software

product, cloud services, PCS, unspecified additional software products) in the arrangement

are separate performance obligations by evaluating whether each of them is capable of being

distinct and is distinct within the context of the contract.

If the entity determines that each of these promises is a separate performance obligation,

allocating the transaction price to each of the performance obligations may require significant

judgment and estimation.

Although the transaction price in arrangements with remix rights is allocated to each of the

performance obligations on a relative standalone selling price basis, entities that can reasonably

estimate expected customer usage (e.g., when they have reliable data about historical customer

usage) may be able to adjust the standalone selling price of each performance obligation based

on their estimates and any restrictions on usage included in the contract. However, once the

transaction price is allocated to the performance obligations, the allocation is not adjusted for

changes to those estimates (e.g., for actual customer usage). Changes in the total transaction

price generally are allocated to the separate performance obligations on the same basis as the

initial allocation.

For example, the portfolio of products and services provided to a customer as part of a

contract with remix rights may include access to a software product that is used by customers

less frequently than the other products or services in the portfolio, based on historical

customer usage data. In this fact pattern, the entity may conclude it is most appropriate to

reflect the expectation that fewer customers will use this software product than the other

products or services in the portfolio in the standalone selling price of that software product

and, therefore, allocate less of the transaction price to it than the entity would have allocated

to it by using the unadjusted standalone selling price.

Technology entities should continue to monitor actual customer usage and periodically revise

the estimates they apply to future contracts.

Contracts with remix rights may include performance obligations that transfer at a point in time

and performance obligations that transfer over time. Depending on the terms of the contract,

control of the performance obligations may transfer (or begin to transfer) to the customer at

the outset of the contract or control may transfer at different points in time for each

performance obligation. Entities will have to carefully evaluate each performance obligation to

determine when control transfers and, therefore, when revenue should be recognized.

Remix rights may

take many forms

and

accounting for

goods or services

that

a customer

has

the ability

to use

may

require

significant

judgment and

estimation.

EY AccountingLink |

ey.com/us/accountinglink

38 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Illustration 16 — License remix rights

Technology entity T enters into a five-year contract with a customer that provides the

customer with the right for up to 20 users to use or access any combination of the vendor’s

on-premise software products A and B and SaaS product C. At the onset of the

arrangement, Technology entity T does not know how the customer plans to use the

products included in the portfolio. The contract also includes PCS and the right to use any

new software or SaaS products released by Technology entity T during the five-year license

period (i.e., unspecified additional products and services). The total transaction price for

the five-year contract is $500,000.

Assume that Technology entity T concludes that each of the promises are distinct and

estimates the following standalone selling prices for 20 users of each of the performance

obligations (because it does not have data to support other usage patterns):

•

Software product A — $400,000

•

Software product B — $350,000

•

SaaS product C — $350,000

•

PCS — $90,000

•

Unspecified additional products and services — $25,000

(a)

Since Technology entity T does not have reliable data to estimate how the customer plans

to use the products in the portfolio, it assumes usage will be even across all performance

obligations and does not make any adjustments to the standalone selling prices. Technology

entity T then allocates the $500,000 transaction price on a relative standalone selling price

basis to the performance obligations as follows:

•

Software product A — $165,000 ($400,000 / $1,215,000 x $500,000)

•

Software product B — $144,000 ($350,000 / $1,215,000 x $500,000)

•

SaaS product C — $144,000 ($350,000 / $1,215,000 x $500,000)

•

PCS — $37,000 ($90,000 / $1,215,000 x $500,000)

•

Unspecified additional products and services — $10,000 ($25,000 / $1,215,000 x

$500,000)

Technology entity T will need to evaluate the timing of revenue recognition for each of the

identified performance obligations based on when it transfers control. Specifically,

Technology entity T concludes that the consideration allocated to the software licenses will

be recognized at the later of the beginning of the license period or when it makes the

software licenses available to the customer. The consideration for the related PCS will be

recognized ratably over the remaining contract term (once the customer can use and

benefit from the software license) and the consideration allocated to the SaaS will be

recognized ratably over the remaining term from the time at which it makes the SaaS

available to the customer. The unspecified additional products and services will be

recognized ratably over the five-year contract term.

____________________

(a)

Technology entity T estimated the standalone selling price for the unspecified additional products and services

based on its history of new product releases and its internal roadmap for future releases. This evaluation

requires significant judgment. Further, while Technology entity T did not have reliable information on customer

usage patterns, technology entities that do have this information should consider it as part of the evaluation.

EY AccountingLink |

ey.com/us/accountinglink

39 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Significant financing component (added January 2020)

To determine whether a significant financing component exists, a technology entity needs to

consider all relevant facts and circumstances, including (1) the difference between the cash

selling price and the amount of promised consideration for the promised goods or services

and (2) the combined effect of the expected length of time between the transfer of the goods

or services and the receipt of consideration and the prevailing market interest rates.

The standard describes three factors that indicate that there isn’t a significant financing

component, including:

•

The customer paid for the goods or services in advance, and the timing of the transfer of

those goods or services is at the customer’s discretion.

•

A substantial amount of the consideration promised by the customer is variable, and the

amount or timing of that consideration varies based on a future event that is not within

the control of the customer or the entity (e.g., a sales-based royalty).

•

The difference between the promised consideration and the cash selling price of the good

or service arises for reasons other than the provision of financing to either the customer

or the entity and the difference between the amounts is proportional to the reason for the

difference (e.g., a payment is made in advance in accordance with the typical payment

terms of the industry or jurisdiction, payment terms provide the entity or the customer

with protection from the other party failing to fulfill its obligations under the contract).

As a practical expedient, a technology entity may decide not to adjust the promised amount of

consideration for the effects of a significant financing component if it expects, at contract

inception, that the period between the transfer of a promised good or service to a customer

and the payment for that good or service will be one year or less.

How we see it

Many technology entities have elected to use the practical expedient and not account for

significant financing components when the anticipated period of time between payment

and the transfer of the promised goods or services is one year or less.

When the anticipated period of time between payment and transfer of the promised goods

or services is greater than one year, a technology entity must evaluate whether there is a

significant financing component or whether the billing terms that result in the timing

difference are for reasons other than financing. Example 30

in the standard illustrates an

entity’s determination that a customer’s advance payment does not represent a significant

financing component. Reasons other than financing could include business and industry

norms to enhance collections, alignment with the nature of the related product or service

itself or assurance that either party to the contract will perform.

Technology entities must carefully evaluate whether a significant financing component

exists when customers are provided with payment choices that base the amount on the

timing of the payment (e.g., up-front rather than annual payments).

Virtual goods (added January 2020)

Many publishers of social-network games, virtual worlds and popular multiplayer online role-

playing games offer the games free of charge and give players the opportunity to purchase

virtual goods to enhance their game-playing experience. Virtual goods are non-physical items

represented in a game by images, animations or three-dimensional objects. Game publishers

also sell characteristics that provide a player with additional or enhanced abilities (such as

speed, strength or health) within a game.

EY AccountingLink |

ey.com/us/accountinglink

40 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Online games provided under a free-to-play model are hosted software applications for which

players generally do not have the ability or the right to take possession of any software license.

Under the standard, game publishers are required to go through the five-step revenue

recognition model to determine the appropriate revenue recognition pattern for their

contracts with customers.

Identifying the contract and performance obligations

Game publishers typically have standard terms and conditions that apply to the use of their

games, regardless of whether they are purchased or played for free. These terms may vary

from publisher to publisher, but they primarily provide the player with a limited license to use

the game that is hosted by the game publisher and to also use in-game purchases made in the

publisher’s game.

The game publisher may conclude that these arrangements do not provide a license of IP

(e.g., because the customer does not take possession of the software) or that a license of IP is

provided with hosting services as a single performance obligation that is satisfied over time.

The discussion in this section assumes that one of these conclusions is reached.

Further, in a free-to-play model, although a player accepts the standard terms and conditions

upon initial access to a game, the arrangement likely does not meet the definition of a

contract under the standard at the onset of the arrangement. This is because the arrangement

lacks commercial substance until an in-game purchase is made, requiring consideration to be

paid to the publisher.

Typically, a game publisher has no contractual obligation to continue to make the game

available to players and can delete a player’s account at any time (regardless of whether the

player has paid for the game or in-game purchases). Most game publishers have a practice of

making a public announcement about their plans to shut down a game (generally a few

months before the shutdown). In addition, a player can delete his or her account at any time.

However, publishers have generally established a practice of continuing to make their games

available after players make in-game purchases (and publicly announcing when they will be

discontinued), which has created players’ expectations that the publisher will continue to host

the game. Therefore, we believe that publishers often have an implied promise to provide

hosting services. Because of the implied promise to provide hosting services, the implicit

performance period is generally not affected by the contractual terms permitting termination

by either party at any time.

Satisfaction of the performance obligation

The period over which the performance obligation is satisfied will depend on the duration of

the implied hosting period for the virtual goods. Based on player behavior and the specific

game features, publishers may find that the length of the implied hosting period (i.e., the

estimated performance period) depends on whether the virtual good is consumable or

durable. These types of goods have the following characteristics:

•

Consumable goods are consumed by a specific action (e.g., using virtual fuel for a virtual

vehicle) or are no longer accessible after a specific amount of time passes. After these

goods are consumed, they are no longer accessible to the player.

•

Durable goods (e.g., virtual vehicles, virtual furniture) are accessible to players

throughout the period that they play the game.

Revenue for virtual

goods is likely

recognized over

the

implied

hosting

period.

EY AccountingLink |

ey.com/us/accountinglink

41 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

For consumable goods, a game publisher may determine that the estimated performance

period varies for each type of virtual good sold, based on when a player “consumes” the

virtual good. This may be a single point in time, a series of times (e.g., the virtual good

provides multiple power-ups) or a period of time. To make these estimates, a publisher may

have to retain, collect and analyze data about player behavior, which can require extensive

effort. This data may include the dates that consumable virtual goods are purchased and the

dates that such items are consumed. Additionally, a publisher has to consider the effect that

the features and functionality of the game have on the period of performance and the data

available to estimate it.

For durable goods, a game publisher may determine that average paying player life best

represents the estimated performance period. One way a publisher may estimate average

paying player life could be the average period of time between the date the player first

purchases a virtual good or currency and the date the player last logs in to the game. The

date of first purchase can be objectively determined, but the last login date may be more

difficult to determine. For example, players may stop playing for a period of time and then

resume playing the game at a later date. A publisher has to use judgment and should have

data to support a conclusion that player inactivity indicates that the player has stopped

playing the game. Additional considerations for determining the estimated performance

period could include other data about paying players (e.g., total hours played, purchasing

patterns) and the average paying player life for similar games published by the entity or

competitors, if that information is publicly available.

We believe that, to make these estimates, the publisher isn’t limited to considering only the

data available for a particular game. For example, when a game publisher launches a new

game, it will not have historical data related to that new game. However, it may determine

that it has other games in its portfolio that have sufficiently similar characteristics (e.g., game

genre, game mechanics, demographics of players, common paying players, types of virtual

goods available) to provide a basis for it to reasonably estimate average player life or

expected usage patterns of virtual goods. The publisher should focus on estimating a period

of performance that is consistent with the standard’s recognition objective of depicting the

satisfaction of the performance obligation.

How we see it

Under legacy guidance, game publishers selected their accounting policy for virtual goods

from three revenue recognition models, which reflected different expectations about the

delivery period and the data available to support those expectations. If the available data

was insufficient to support a particular model a publisher identified as an accounting

policy, the publisher usually defaulted to a less precise model until data became available

to support the selected model.

Under the standard, publishers are required to recognize revenue over a period that best

depicts their satisfaction of the performance obligation in an arrangement. Publishers that

don’t have a lot of reliable data still need to estimate the period of performance.

Changes to estimated period of performance

Like any significant estimate, an estimate of the period of performance (e.g., average paying

player life) is likely to change. As a result, it is important that the publisher implement a

process to continually update the data on which an estimate is based and maintain appropriate

documentation. As part of that process, we would expect a publisher to consider how actual

results compare with historical estimates in addition to how future results may differ from

past results.

EY AccountingLink |

ey.com/us/accountinglink

42 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Once a change in estimate is identified, the publisher should account for that change in

accordance with ASC 250-10-45, which provides guidance on accounting for estimates. That

guidance requires the effect of the change in estimate to be accounted for in both the period

that the change occurred and in future periods, if the change affects both periods. That is, the

change in estimate would apply to transactions with deferred revenue balances (i.e., revenue

to be recognized in future periods) and all future transactions.

Additional considerations for technology contracts

The following section outlines some additional considerations for evaluating contracts with

customers that may be relevant to technology contracts, including those that contain a

software license.

Enforceable rights and obligations (updated January 2020)

A contract in the scope of the standard may be written, oral or implied by an entity’s

customary business practice, but one of the criteria it must meet is that it must create

enforceable rights and obligations.

A technology entity may enter into a master service agreement (MSA) with a customer that

stipulates the terms and conditions (e.g., payment terms, use of service or content,

confidentiality), but the contract may require separate purchase orders or order forms for

specific goods and services before the entity transfers them and is entitled to payment. In

these cases, the purchase order generally creates enforceable rights and obligations and

should be evaluated together with the MSA. That is, the purchase order commits the parties to

perform their respective obligations, which is the transfer of promised goods and services in

exchange for the specified consideration.

If an MSA includes an enforceable clause requiring the customer to purchase a minimum quantity

of goods or services, the MSA alone may constitute a contract under the standard because

enforceable rights and obligations exist for this minimum amount of goods or services.

Termination clauses

Technology contracts may include clauses that allow a customer to terminate a contract

without penalty, or the customer may be required to pay a termination penalty that is not

substantive. The absence of a substantive termination penalty may affect an entity’s

determination of the length of the contract, the number of performance obligations, the

transaction price, the timing of revenue recognition and the required disclosures.

The standard does not address the effect of termination penalties on the length of the

contractual period. However, the TRG generally agreed

that a substantive termination

penalty payable by a customer is evidence of enforceable rights and obligations on the part of

both parties throughout the period when the substantive termination penalty applies.

The amount, nature and purpose of the termination penalty are factors to consider when

determining whether the termination penalty is substantive. TRG members observed that the

determination of whether a termination penalty is substantive, and what the enforceable

rights and obligations are under a contract, requires judgment and consideration of the facts

and circumstances. If the termination penalty is not substantive, the contract may be shorter

than the stated contractual term. The following example demonstrates the effect of the

termination penalty on the duration of a contract.

Determining the

enforceable rights

and obligations

under a contract

with termination

rights may require

significant

judgment.

EY AccountingLink |

ey.com/us/accountinglink

43 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Illustration 17 — Determining the duration of the contract

SaaS provider A enters into a four-year SaaS contract with a customer. The customer is

required to pay a nonrefundable annual fee of $100,000, which is the standalone selling

price for the service.

To determine the duration of the contract in each of the scenarios below, the entity considers

these facts and whether the contract provides cancellation rights and termination penalties.

Scenario A: Assume no cancellation rights are provided to either party. In this case, the

enforceable rights and obligations exist for the entire stated contractual term, and the

contract duration is four years.

Scenario B: Assume the contract provides the customer with a right to cancel the contract

at the end of each year without cause but with a termination penalty. The penalty decreases

annually throughout the contract term at the end of each year. The following illustrates the

payments under the contract.

Year 1 Year 2 Year 3 Year 4

Annual fee ($) 100,000 100,000 100,000 100,000

Termination penalty ($) 225,000 150,000 75,000 0

If SaaS provider A determines that the penalty is substantive in each period, enforceable

rights and obligations exist for the stated contractual term of four years.

Scenario C: Assume the contract provides the customer with a right to cancel at the end of

each year with no termination penalty. In this case, SaaS provider A determines that the

contract duration is one year, with options to renew for each of the following three years

because the customer can choose whether to receive the service during those years. That

is, SaaS provider A determines that enforceable rights and obligations do not exist

throughout the entire stated contractual term because there is no substantive termination

penalty. The options to renew are not material rights because they are offered at the

standalone selling price of $100,000.

Many professional services contracts, such as a statement of work (SOW), have customer

termination provisions with a minimum notification period (e.g., 30 days). For example, a SaaS

vendor may sell a three-year SaaS solution and enter into an SOW to provide implementation

services priced on a time and materials basis, which the SaaS vendor anticipates will take six

months to complete.

The SOW may provide the customer with the ability to terminate the SOW at any time after a

30-day notification period and to pay only for the services received (i.e., there is no substantive

termination penalty). Such provisions need to be carefully evaluated because they likely

indicate that there are only enforceable rights and obligations in the contract for 30 days of

professional services and that any additional days of service are optional purchases. Entities

need to evaluate whether a contract, such as an SOW, contains an option to renew the

implementation services and whether there are material rights in these situations.

EY AccountingLink |

ey.com/us/accountinglink

44 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

How we see it

Technology entities should carefully evaluate the termination provisions in their contracts. The

evaluation of termination clauses is critical because the conclusions on the enforceable rights

and obligations in a contract, including contract duration, can affect the determination and

allocation of transaction price. Further, termination clauses can affect required disclosures

(e.g., the amount of transaction price allocated to remaining unsatisfied performance

obligations, often referred to as backlog), as well as the characterization of customer

prepayments (e.g., as a contract liability or another type of liability, such as a customer deposit).

Contract modifications (updated January 2020)

Parties to a contract frequently agree to modify the scope or price (or both) of a contract.

As illustrated in Example 5, Case B,

in the standard, a contract modification may include

compensation to a customer for performance issues (e.g., poor service by the entity, defects

present in transferred goods). An entity may need to account for the compensation to the

customer as a change in the transaction price separately from other modifications to the contract.

The standard requires certain modified contracts to be treated as entirely new contracts

(either a second, separate contract or the termination of the existing contract and the

creation of a new contract) and others to be treated as part of the original contract. The

accounting treatment depends on whether the modification results in the addition of distinct

goods or services and whether the amount of consideration expected for those goods or

services reflects their standalone selling prices.

Consider a SaaS provider that enters into an agreement with a customer to increase the

number of users with access to a SaaS subscription. Assume the services provided to the

additional users are distinct. If the additional consideration reflects the standalone selling

price of the additional service per user, the modification is accounted for as a separate

contract. If the additional consideration does not reflect the standalone selling price, the

modification is accounted for as the termination of the existing contract and the creation of a

new contract. The revenue recognized to date on the original contract is not adjusted, and the

remaining portion of the original contract and the modification are accounted for together by

allocating the remaining consideration (i.e., the unrecognized transaction price from the

existing contract plus the additional transaction price from the modification) to the remaining

performance obligations. As part of this assessment, the SaaS provider also considers

whether it has identified all the promises in the modified agreement.

If the modification involves a software license, we believe the additional and/or modified

software license is likely distinct from the original license because the new and/or modified

rights typically differ from those conveyed by the original license. Therefore, the accounting

treatment depends on whether the additional consideration reflects the standalone selling

price of the software license.

 EITF will address contract modifications for licenses of IP

The FASB has added a project to the agenda of the EITF to address diversity in practice related

to accounting for contract modifications for licenses of IP under the revenue standard. As part

of this project, the EITF will address the accounting for contract modifications that extend a

license term but are not solely a renewal of the terms and conditions of the original license.

We encourage readers to monitor developments because any new guidance on this topic

could affect accounting for such arrangements. Refer to our To the Point, The EITF will

address revenue recognition related to contract modifications for licenses of IP, for details.

EY AccountingLink |

ey.com/us/accountinglink

45 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Entities may make appropriate adjustments to the standalone selling price they use to evaluate

contract modifications to reflect the circumstances of the contract. For example, the SaaS

provider in the example above may conclude that, when more users are added, the customer

qualifies for lower pricing offered based on volume. While the per-user price for the additional

users may be lower than the original per-user price, the SaaS provider may determine that the

additional transaction consideration reflects the standalone selling price for the volume of users.

Other appropriate adjustments to the standalone selling price could include reduced costs to sell

to existing customers.

How we see it

Technology entities have to evaluate whether to treat contract modifications as separate

contracts or as modifications of existing contracts. This is a change in practice for

software or cloud service providers that treated all agreements to add users as separate

contracts under legacy guidance. Under the standard, treating a modification as a

separate contract is permitted only if the consideration for providing distinct services to

more users reflects the standalone selling price.

New contracts with existing customers (added January 2020)

Because technology entities may enter into new contracts with existing customers without

amending an existing contract, they may find it difficult to determine when a contract

modification has occurred.

A new contract with an existing customer needs to be evaluated as a contract modification if it

results in a legally enforceable change to the scope or price of an existing contract. In some cases,

the determination of whether a new contract modifies an existing contract will require judgment.

We believe that, to make this determination, an entity should consider the facts and circumstances

of the new contract, including the following factors included in the contract combination

requirements of the standard:

•

Whether the contracts were negotiated as a package with a single commercial objective,

which might be the case if the original contract contemplated future modifications

•

Whether the amount of consideration to be paid in one contract depends on the price or

performance of the other contract

•

Whether the goods or services promised in the contracts (or some goods or services

promised in each of the contracts) are a single performance obligation

Illustration 18 — Evaluating a new contract with an existing customer

SaaS provider B has several SaaS products designed for the health care industry. On 1 July

20X6, SaaS provider B enters into a three-year SaaS contract with a new customer for a

subscription to its electronic medical records application and implementation services,

which are expected to take two months. Since the customer is a large hospital network and

represents a significant business opportunity for SaaS provider B, SaaS provider B agrees

to provide the customer with a discount of 25% off the list price for each service, which is

larger than the discount it typically provides to new customers. Further, the sales

representative believes that, based on discussions with the customer, the customer is likely

to purchase other applications from SaaS provider B in the future if the customer is satisfied

with the implementation and function of the electronic medical records application.

EY AccountingLink |

ey.com/us/accountinglink

46 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

On 1 July 20X7, when there are still two years remaining on the original contract, SaaS

provider B enters into a second, separate contract with this customer. The new contract is

for a two-year subscription to SaaS provider B’s appointment management application and

does not legally change the scope or price of the original contract.

However, as part of the negotiations, the customer and the sales representative consider

the discount that was provided in the original contract and agree to a price for the second

contract that represents only a 15% discount off the list price. The sales representative and

the customer agree to this price primarily because the implementation services provided as

part of the original contract were completed ahead of schedule and because the customer

has been impressed with the electronic medical records application so far. Further, the

customer was willing to accept a smaller discount in the second contract because it had

received a larger discount in the original contract.

SaaS provider B considers whether the second contract should be evaluated as a

modification of the original contract. SaaS provider B considers the negotiations that

occurred for obtaining both contracts, based on discussions with the sales representatives,

and determines that the price of the second contract was not negotiated independently of

the original contract. That is, SaaS provider B determines that the contracts were

negotiated with a single commercial objective. Therefore, SaaS provider B determines that

it should account for the second contract as a modification of the original contract.

Collectibility

Technology entities may not expect to collect the full contract price for transferring goods or

services when they enter into contracts with certain customers (i.e., customers in new or

emerging markets). For a contract to be in the scope of the standard, it must be probable that

the entity will collect substantially all of the consideration to which it expects to be entitled in

exchange for the goods or services that will be transferred to the customer (i.e., the transaction

price after considering variable consideration, including the constraint).

The amount of consideration that is assessed for collectibility is the amount to which the entity

expects to be entitled, which under the standard is the transaction price for the goods or services

that will be transferred to the customer rather than the price that is stated in the contract.

For technology entities, differences between the transaction price and the contractual price

most often relate to variable consideration (e.g., rebates, discounts, explicit or implicit price

concessions) that reduces the amount of consideration stated in the contract. See the

“Variable consideration

” section for further discussion of implicit price concessions.

An entity also may consider its ability to manage its exposure to credit risk (e.g., through

advance payments, through the right to stop transferring additional goods or services) as part

of the collectibility assessment. Consider an IT service provider that enters into a three-year

contract to provide data management services and has the right to stop providing services

when the customer fails to pay. Based on its history with this class of customer, the IT service

provider expects the customer to make the required payments for at least nine months. The

IT service provider then evaluates whether it will collect substantially all of the consideration

to which it will be entitled for the nine months of service.

EY AccountingLink |

ey.com/us/accountinglink

47 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

When an entity determines that a contract with a customer does not meet the collectibility

requirements of a contract under the standard (or any of the criteria to be identified as a

contract), the entity should recognize nonrefundable consideration received as revenue only

when one of the following events has occurred:

•

The entity has fully performed, and substantially all the consideration has been received

(i.e., the entity has fully performed on all performance obligations in the contract and has

received substantially all cash consideration for the entire contract).

•

The contract has been terminated.

•

The entity has transferred control of the goods or services and has stopped transferring

(and has no obligation under the contract to transfer) additional goods or services to the

customer, if applicable.

How we see it

Under the standard, a technology entity needs to assess the customer’s ability and intent

to pay substantially all of the consideration to which the entity expects to be entitled. This

amount may not be the contractual price.

It is no longer acceptable for entities to default to deferring revenue recognition until cash

is collected if they have concerns about whether they will collect the contractual amount

(i.e., they are unable to conclude that collectibility is reasonably assured).

Principal versus agent (updated January 2020)

A technology entity may publish advertising content from a third party on its website or mobile

application. A technology entity also may provide a platform to sell virtual or digital goods on

behalf of a third party. When another party is involved in providing goods or services to the

technology entity’s customer, the technology entity must determine whether its performance

obligation is to provide the good or service itself (i.e., the technology entity is a principal) or to

arrange for the other party to provide the good or service (i.e., the technology entity is an agent).

An entity is a principal if it controls a promised good or service before it transfers the good or

service to a customer. The Board noted in the Basis for Conclusions of ASU 2016-08

that

control is the determining factor in the assessment of whether an entity is a principal or an agent.

To apply the principal versus agent guidance, an entity must first properly identify the

specified good or service (or unit of accounting for the principal versus agent evaluation) to

be transferred to the customer. A specified good or service is defined as each distinct good or

service or distinct bundle of goods or services promised to the customer. That is, the specified

good or service is what the customer is ultimately purchasing, regardless of which entity is

responsible for providing that good or service.

This assessment may be straightforward in transactions where a consumer product is being

purchased from an online retailer, such as a song or a book (physical or electronic). The online

retailer would often conclude that the consumer product is the specified good or service. The

evaluation may be more complex when there are several goods or services purchased by the

customer, particularly when the goods or services are sourced from different entities. For

example, an entity may sell its hardware to customers, which may include software sourced

from third parties. An entity would have to determine whether there are one or two specified

goods or services in this transaction (i.e., hardware with embedded software or hardware and

software separately) based on an evaluation of whether the separate promises are distinct from

each other.

Technology entities

need to carefully

evaluate whether to

recognize

gross

revenue or

net

revenue when third

parties are involved

in the sale of goods

services.

EY AccountingLink |

ey.com/us/accountinglink

48 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Determining whether an entity controls a good or service before it is transferred to the

customer can be challenging if the good or service is intangible, such as digital content. As

part of this evaluation, the standard requires the entity to consider the definition of control in

ASC 606-10-25-25, which states that control is “the ability to direct the use of, and obtain

substantially all of the remaining benefits from, the asset.” An entity also should consider how

the benefits from an asset can be obtained, including by selling or exchanging the asset. When

evaluating control, an entity also should look to its contractual relationship with any third

party involved in the contract to help the entity determine whether it has control of the good

or service before that good or service is transferred to the customer.

Because it still may not be clear whether an entity controls the specified good or service, the

standard provides three indicators (i.e., principal indicators) of when an entity controls the

specified good or service (see Step 2 of the model in Appendix A). Generally, the inventory

risk indicator won’t apply to intangible goods or services, so technology entities need to

consider the other indicators (i.e., responsibility for fulfilling the promise to provide the

specified good or service and discretion in establishing the price of the specified good or

service) to determine whether they control intangible goods or services.

The FASB noted in the Basis for Conclusions of ASU 2016-08

that while the indicators can

help to support an entity’s assessment of control, they cannot replace the assessment.

Further, the FASB explained that the indicators should not be viewed in isolation and are not a

checklist of criteria that must be met in all cases. However, an entity’s conclusions about

control and the principal indicators should align. An entity that reaches different conclusions

when it applies the standard’s definition of control and when it considers the principal indicators

should reevaluate its analysis, considering the facts and circumstances of the contract.

The illustration below, which is similar to Example 45

in the standard, demonstrates the

control assessment for an entity that concludes that it is an agent:

Illustration 19 — Entity is an agent

An entity operates a website that provides a marketplace for customers to purchase goods

from a variety of suppliers, who deliver the goods directly to the customers. The entity’s

website facilitates customer payments to the suppliers at prices that are set by the suppliers.

The entity requires payment from customers before orders are processed (i.e., provided to the

supplier for fulfillment), and all orders are nonrefundable. The entity has no further obligations

to the customers after arranging for the supplier to provide the products to the customers; the

entity is not responsible for the acceptability of goods provided to customers.

First, the entity evaluates the specified goods and concludes that there are no other goods

or services promised to the customer except those provided directly by the suppliers. Next,

the entity considers whether it controls the specified goods before they are transferred to

the customers. Since the entity does not at any time have the ability to direct the use of the

goods transferred to the customers, the entity concludes that it does not control the

specified goods before they are transferred. As part of this assessment, the entity also

considers the three indicators of control in the standard and makes the following

determinations that support its overall control evaluation:

•

The suppliers are responsible for fulfilling the promise to the customer, and the entity

does not take responsibility for the acceptability of the goods.

•

The entity does not have inventory risk because it does not obtain the goods at any time.

•

The entity does not have discretion to establish prices because these are set by the suppliers.

The entity concludes that it is an agent for the goods sold through its website because the nature

of its performance obligation is to arrange for suppliers to provide goods to the customers.

EY AccountingLink |

ey.com/us/accountinglink

49 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

By contrast, consider the following example of an entity that concludes it is acting as a principal:

Illustration 20 — Entity is a principal

An entity operates a website that provides a marketplace for customers to purchase digital

content. The entity has entered into contracts with suppliers that provide the entity with the

right to sell the digital content during a noncancelable period of time in exchange for a fixed fee

per unit of content. The entity can set the price for the content to be sold to customers on its

website. The entity is contractually required to pay the supplier a fixed price or rate for any

digital content it sells to its customers that is unaffected by the price paid by the end customers.

The entity is also responsible for assisting customers if they encounter issues downloading

the content or other issues, and customers do not interact with the suppliers.

The entity first evaluates the specified goods and concludes that the digital content is the only

specified good or service. Next, the entity considers whether it controls the digital content

before it is transferred to the customer. The entity concludes that it controls the specified

goods before they are transferred because it has entered into a noncancelable distribution

agreement that permits it to sell the digital content to its customers. This differs from the

entity’s conclusion in Illustration 19 because the entity in that illustration provided a platform

to connect suppliers to customers and did not have the ability to sell the goods.

As part of its assessment, the entity in this illustration also considers the three indicators of

control in the standard and makes the following determinations that support its overall

control evaluation:

•

The entity is responsible for fulfilling the promise to the customer, and the entity takes

responsibility for the acceptability of the goods.

•

There is no inventory risk associated with digital content.

•

The entity has discretion in establishing prices.

The entity concludes that it is a principal for the digital content sold through its website

because it controls the content before it is transferred to the customer.

Entities need to evaluate the nature of their own transactions, including specific contractual

terms, to determine whether they are agents or principals.

If a contract with a customer includes more than one specified good or service, the standard says

that an entity may be a principal for some specified goods or services and an agent for others.

Illustration 21 — Entity is both a principal and an agent

A software reseller sells software licenses bundled with PCS to end users and other IT

solutions. The reseller has entered into contracts with several software manufacturers that

provide the reseller with the right to sell licenses to the software with PCS to end users

during noncancelable periods of time in exchange for fixed fees per license sold. The

reseller can set the prices it charges end users but is contractually required to pay the

software manufacturer the fixed fee, regardless of the price paid by end users. The

software reseller does not have a commitment to make a minimum number of purchases

from the software manufacturer and does not make purchases in advance.

The software reseller is responsible for identifying which software will address the

customer’s needs (including the feasibility of integrating it with the customer’s existing

technology environment), ordering the software from the manufacturer, assisting

customers if they encounter issues downloading the software (all software is provided

electronically) and with other basic technical support. The software manufacturer provides

the higher levels of technical support and provides PCS directly to the customer.

EY AccountingLink |

ey.com/us/accountinglink

50 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

As part of its principal versus agent evaluation for these contracts, the software reseller

determines that the software license and PCS are separate specified goods or services.

When assessing control for the software license, the reseller concludes that it controls the

software license before the license is provided to the end user. This is because the reseller

has the right to direct the software manufacturer to provide the software to the end user

on the reseller’s behalf. As part of this assessment, the software reseller also considers the

three indicators of control in the standard and makes the following determinations that

support its overall control evaluation:

•

The software reseller is responsible for fulfilling the promise to the customer, and the

entity takes responsibility for much of the purchasing process as described above.

•

There is no inventory risk associated with the software provided electronically.

•

The software reseller has discretion to establish prices.

Conversely, the reseller concludes that it does not control the PCS before it is provided to the

end user because the software manufacturer creates the updates that it delivers electronically

to end users of the software directly through the internet and because all but the most

basic level of technical support will be provided by the software manufacturer. As part of

this assessment, the software reseller also considers the three indicators of control in the

standard and makes the following determinations that support its overall control evaluation:

•

The software manufacturer is responsible for fulfilling the promise to the customer

because it provides the updates directly to the end users.

•

There is no inventory risk associated with the PCS provided electronically.

•

The software reseller has discretion to establish prices.

The software reseller believes that the first of the indicators is the most relevant to consider

in this assessment and that it supports its overall control assessment. Therefore, the

software reseller concludes that it is the principal for the software license but is an agent

for the PCS because it does not control the PCS before it is transferred to the end user.

The facts and circumstances of each reseller arrangement must be evaluated because

differences in the structure of these arrangements (e.g., how the software license or cloud

service is delivered to the end user) could result in different conclusions about whether the

reseller is a principal or an agent.

Determining gross revenue as a principal when selling through an intermediary

(added January 2020)

Questions have arisen regarding gross revenue recognition for entities that are the supplier of

goods or services (e.g., SaaS vendors, hardware manufacturers) that are sold through an

intermediary (i.e., a reseller or distributor). While the supplier of the goods or services is the

principal in these arrangements, it may be difficult to determine whether the intermediary or

the end customer is the customer. This determination is important because the amount of

gross transaction price, and, therefore, the amount of revenue recognized, depends, in part,

upon the consideration paid by the customer.

The standard defines a customer as “a party that has contracted with an entity to obtain goods

or services that are an output of the entity’s ordinary activities in exchange for consideration.”

When it is not clear, based on the definition, who the supplier’s customer is, the supplier should

also consider who its contractual arrangement is with and to which party it transfers control of

the goods or services (i.e., who is obtaining the output of the supplier’s ordinary activities).

EY AccountingLink |

ey.com/us/accountinglink

51 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

If identifying the party to which control transfers is difficult, it may also be helpful to consider

the standard’s indicators that the entity is the principal (i.e., it has responsibility for fulfilling the

promise to the customer, inventory risk, discretion in establishing pricing). In some fact patterns,

the supplier may conclude that both the end customer and the intermediary are its customers.

Often the reseller or distributor will be the customer in these arrangements. However, if the

supplier determines that the end customer is its customer, but it does not know (and expects

not to know) the price the intermediary charges the end customer for its goods and services,

it should not estimate its gross transaction price. Instead, it would only consider the transaction

price remitted by the intermediary. The Board stated in the Basis for Conclusions of

ASU 2016-08

that if uncertainty related to the transaction price is not ultimately expected

to be resolved, that amount would not meet the definition of variable consideration and,

therefore, should not be included in the transaction price.

Consider the following illustration:

Illustration 22 — Entity sells through a distributor

Hardware entity H manufactures computer hardware, including Hardware X, that is sold

through a distributor that operates an e-commerce site. Based on careful evaluation of the

facts and circumstances of the arrangement with this distributor, Hardware entity H has

determined that its customer is the end customer rather than the distributor.

The distributor sells Hardware X to end customers for $125, which is due when the order is

placed on the website. As each purchase is made, the distributor places a purchase order

with Hardware entity H for the product and must pay $100, due within 30 days.

The diagram below illustrates the flow of consideration and Hardware X between the

various parties in the arrangements:

Scenario A: Hardware entity H is contractually entitled to receive a monthly report from

the distributor indicating the month’s sales, including prices. Because Hardware entity H

knows that the distributor charges customers $125 for Hardware X, it records revenue at the

gross amount of $125 and records the $25 retained by the distributor as the cost of sales.

Scenario B: Hardware entity H does not have insight (and does not expect to have insight in

the future) into the price charged by the distributor to end customers for sales of Hardware X.

Although Hardware entity H is the principal in the arrangement and records revenue at the

gross amount, it should not estimate the price charged to the end customer. Therefore,

revenue recorded by Hardware entity H is $100, the consideration received from the distributor.

Further, we believe that if an entity is not contractually entitled to know the transaction price

an intermediary charges the end customers (e.g., the arrangement with the intermediary

indicates that the entity does not have a right to that information), but it nevertheless obtains

the information, the entity should not recognize revenue at the gross amount.

For example, assume that a distributor is required to provide the supplier (who has

determined that the end customer is its customer) with a monthly listing of the transactions

that occurred during the period. Based on the distribution agreement, the supplier is not

contractually entitled to know the prices charged to the end customers by the distributor.

EY AccountingLink |

ey.com/us/accountinglink

52 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

However, despite this contractual term, the monthly report that the distributor provides

includes certain prices charged to the end customer for each transaction (e.g., some of the

prices were redacted, while others were not). We believe that, even though the supplier has

the pricing data based on the reports received from the distributor, the supplier should not

record revenue at the gross amount because it is not contractually entitled to that

information and it has no expectation that it will regularly receive the information.

How we see it

While the guidance on principal versus agent considerations is similar to legacy GAAP, the

key difference is that the new guidance focuses on control of the specified goods and

services as the overarching principle for entities to consider in determining whether they

are acting as a principal or an agent. Entities must perform a robust assessment of control

and should avoid focusing solely on the control indicators. This could result in entities

reaching different conclusions from those they reached under legacy GAAP.

Variable consideration

Implied price concessions (updated January 2020)

Technology entities may be aware of potential collectibility issues at the outset of a contract

but may still be willing to enter into the contract with a customer. When the entity is aware of

such a risk and still chooses to transact with the customer, the contract may include an

implied price concession. Under the standard, any implied price concessions create variable

consideration, and an entity must estimate these amounts at contract inception.

Consider a technology entity that has a history of accepting consideration that is 60% of the

contract price in a specific region in exchange for its software and PCS. When determining the

transaction price for a contract in that region, the entity might determine that 60% of the

contract price is the transaction price, and there is an implied price concession for the

remaining 40% based on the entity’s history.

Technology entities may find it challenging to distinguish between implied price concessions

(i.e., reductions of revenue) and customer credit risk (i.e., bad debt) for collectibility issues

that were known at contract inception. Entities need to carefully evaluate all facts and

circumstances that were available at contract inception, as well as any subsequent events

that may have affected the customer’s ability to pay.

Technology entities should consider whether they have a history of accepting prices that are

lower than the contractual prices. If a technology entity has established such a business

practice, it must include an estimate of variable consideration for implied price concessions in

the transaction price. Other factors that technology entities may consider in determining

whether the contract includes an implied price concession include the customer’s payment

history and financial condition, the entity’s policies for credit checks and processes for

collections on outstanding balances, and market conditions in the region. Significant judgment

is required when making this determination, and entities should retain contemporaneous

documentation to support their judgments.

How we see it

Accounting for variable consideration resulting from implied price concessions significantly

changed practice for technology entities that recognized revenue on a cash basis in these

situations under legacy guidance. Under the standard, a technology entity must estimate

variable consideration and include any amounts that are not constrained (refer to Step 3 in

Appendix A) in the transaction price, rather than default to deferring all revenue until the

contingency is resolved. Entities are also required to update the estimated transaction

price at each reporting date and potentially adjust revenue recognized.

Implied price

concessions

create

variable

consideration

that

must be

estimated

at contract

inception.

EY AccountingLink |

ey.com/us/accountinglink

53 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Extended payment terms

Under the standard, an entity needs to consider whether any extended payment terms

provided to the customer create variability in the transaction price (i.e., are a form of variable

consideration) and whether a significant financing component exists.

An entity needs to carefully evaluate contracts that include extended payment terms to

determine whether it has the intent or a reasonable expectation to provide a price concession.

For example, a technology entity may routinely provide price concessions in contracts that

include extended payment terms in order to negotiate contract renewals with customers.

Entities are required to estimate the price concession at contract inception and reduce the

transaction price for that amount.

How we see it

The treatment of extended payment terms under the standard has accelerated the

recognition of revenue for some technology entities. Under legacy guidance,

many

entities that license software could not overcome the presumption in ASC 985-605 that

extended payment terms (i.e., payment terms greater than one year) resulted in a

transaction price that was not fixed or determinable because there was an increased risk

of the entity granting future price concessions to its customer. As a result, most technology

entities had been unable to recognize revenue for contracts that included extended

payment terms until the amounts were due because they were unable to demonstrate a

history of successfully collecting without making concessions to the customer.

Reseller and distributor contracts

The standard likely changes practice for many technology entities that sell their products

through distributors or resellers if the only uncertainty in the contract with the distributor or

reseller is the variability in the transaction price (e.g., a semiconductor chip manufacturer

may provide a distributor with volume discounts, rights of return and price protection rights).

This is because the standard requires an entity to estimate the variable consideration (i.e., the

end sales price) based on the information available, taking into consideration the effect of the

constraint on variable consideration, and recognize revenue when control of the good or

service is transferred to the reseller or distributor.

How we see it

Recognizing revenue (subject to the constraint on variable consideration) when products

are delivered to a reseller is similar to the treatment under the “sell-in” method in legacy

guidance. Entities can no longer apply the “sell-through” method and wait until the

product is sold to the end customer to recognize revenue if the sales price is the only

uncertainty in the contract with the distributor or reseller.

Variable consideration and options for additional goods and services

Technology entities need to exercise judgment to distinguish between contracts that contain

an option to purchase additional goods or services (e.g., option to renew cloud services or

PCS) and contracts that include variable consideration (e.g., rebates, credits, volume

discounts). The TRG generally agreed

that entities should first determine the nature of the

promises in the contract and the rights and obligations of the parties. Determining the nature

of an entity’s promise is critical to differentiating between optional purchases and variable

consideration and may require significant judgment.

EY AccountingLink |

ey.com/us/accountinglink

54 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

If the contract includes a customer option, the technology entity is not obligated to provide

additional goods and services until the customer makes a separate purchasing decision

(i.e., exercises the option). That is, the entity’s performance obligation at contract inception is

to provide the quantity of goods or services specified in the contract. In contrast, if the entity

is obligated to transfer the goods and services and the customer is obligated to pay for those

promised goods and services, even if the consideration owed to the entity is not known at

contract inception, the contract includes variable consideration.

The determination of whether the contract contains a customer option or variable consideration

is important because it affects the accounting for the contract at inception and throughout

the life of the contract and the disclosures an entity has to make. Entities need to make

certain that their conclusions regarding the determination of the nature of the promise are

consistent with conclusions regarding whether additional consideration that will be potentially

received from the customer is related to variable consideration or optional purchases for

additional distinct goods or services.

Technology contracts for products such as microprocessors, computer hardware or networking

equipment may provide volume discounts or rebates that are based on the number of units sold.

The pricing adjustments provided by a volume discount or rebate determine whether it is

accounted for as an option to purchase additional goods or services or variable consideration.

Generally, a volume discount or rebate that is retrospectively applied is accounted for as

variable consideration. This is because the final price of each good or service sold is dependent

upon the customer’s total purchases subject to the discount or rebate. That is, the consideration

is contingent upon the occurrence or nonoccurrence of future events. This view is consistent

with Example 24

in the standard.

Conversely, if a volume discount or rebate is prospectively applied (see Illustration 10 for an

example), the discount or rebate may not be accounted for as variable consideration. This is

because the consideration for the goods or services in the contract is not contingent on or

affected by any future purchases. Rather, the discounts available from the rebate program

affect the pricing on future purchases. However, technology entities need to evaluate

whether the option to purchase goods or services in the future at a discount represents a

material right and, therefore, should be accounted for as a performance obligation. If the

entity determines that the option is a material right, the entity is required to allocate a portion

of the transaction price to the material right at contract inception and recognize revenue

when the option is exercised or the option expires.

How we see it

Significant judgment may be required to distinguish between a customer option and

variable consideration, and identifying the nature of the entity’s performance obligation is

critical to making the distinction. This determination is important because it affects the

accounting for the contract at inception and throughout the life of the contract.

Recognition of revenue

Measuring progress in a combined performance obligation

A single performance obligation may contain multiple goods or services that aren’t distinct

(i.e., a combined performance obligation). For example, hardware, software and professional

services may be combined into a single performance obligation because the professional

services significantly customize and integrate the hardware and software, and the hardware,

software and professional services are inputs to a combined output.

EY AccountingLink |

ey.com/us/accountinglink

55 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The standard requires that a single method of measuring progress be used for each performance

obligation satisfied over time. In the case of a combined performance obligation that is

satisfied over time, the entity has to select a single measure of progress that faithfully depicts

the entity’s performance in transferring the goods or services. Such a determination requires

significant judgment, but TRG members generally agreed

that the measure of progress

selected should be consistent with the standard’s objective and that entities should consider

the nature of the overall promise for the combined performance obligation. For example, the

technology entity should not default to a “final deliverable” methodology or select a measure

of progress that treats each promise as if it were a separate performance obligation.

In the example of the hardware, software and professional services that are combined into a

single performance obligation (because one or more of the goods or services significantly

modifies or customizes the other goods or services promised in the contract), the entity should

consider a measure of progress that depicts the performance of the professional services. This is

because the customer has not purchased each of the individual goods and services, but rather a

customized solution for which each of the individual goods and services is an input (i.e., the entity

concluded that the customizations are significant enough that the promises are not distinct

within the context of the contract) and because the creation of the customized solution is

performed over time (i.e., over the period during which the professional services are provided).

Similarly, an entity may conclude that a measure of progress that aligns with the SaaS may be

appropriate for a hybrid-SaaS contract if the on-premise software and SaaS are a single

performance obligation. This is because the entity has determined that it is providing a

combined output over the period.

Contract costs

Costs to obtain a contract

Identifying costs to obtain a contract that are required to be capitalized

The guidance in ASC 340-40 requires entities to capitalize the incremental costs of obtaining

a contract with a customer if the entity expects to recover those costs. An entity can expect

to directly recover contract acquisition costs (i.e., receive reimbursement under the contract)

or indirectly recover them (i.e., through the margin inherent in the contract). Incremental

costs are costs an entity would not have incurred if the contract had not been obtained.

Entities should first refer to the applicable liability standard to determine when they are

required to accrue for certain costs. Entities would then use the guidance in ASC 340-40 to

determine whether the related costs need to be capitalized.

For technology entities, the most common example of an incremental cost of obtaining a

contract is a sales commission. Commissions paid to an account executive for signing a new

customer or for the sale of additional goods or services (often called “land and expand”)

qualify as incremental costs of obtaining a contract if they are paid only as a result of signing

the contract. Determining whether other types of commissions qualify for capitalization

requires judgment. Commissions paid for renewals, commissions paid to supervisors and

commissions not directly linked to any single or specific contract (e.g., commissions based on

reaching an aggregate value of contracts booked during the year, meeting individual sales

targets or accelerators) require careful consideration.

ASC 340-40 does not address considerations for different types of commission programs.

However, the TRG indicated

that, to determine whether a cost is incremental and, therefore,

capitalizable, an entity should consider whether it would still incur the cost if the customer (or

entity) decided not to enter into the contract just as parties were about to sign. If the costs

would have been incurred even if the contract had not been executed, the costs are not

incremental to obtaining that contract.

Entities may need

to c

apitalize costs

hey would have

expense

d under

legacy guidance

EY AccountingLink |

ey.com/us/accountinglink

56 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

It is important to note that ASC 340-40 does not require costs to be direct in order to be

capitalized. That’s why the TRG members generally agreed

that an employee’s title or level

in the organization, or how directly involved the employee is in the sales process, should not

affect the determination of whether a sales commission is incremental.

Entities also need to carefully evaluate all compensation plans, not just sales commission

plans, to determine whether any plans result in incremental costs that should be capitalized.

For example, “bonus” payments that are tied solely to obtaining contracts would be

capitalized if they are incremental costs of obtaining a contract, regardless of the title of the

plan or the title of the employee paid.

However, some entities pay compensation in increments or delay payments and require that

an individual remain employed to collect a commission when it is due. In these cases, an entity

needs to carefully evaluate whether the requirement to remain employed in order to receive

the commission (i.e., the service vesting condition) is substantive (i.e., whether the time

period is substantive).

The TRG indicated

that fringe benefits should also be capitalized as part of the incremental

cost of obtaining a contract if the additional costs are based on the amount of commissions

paid and the commissions qualify as costs to obtain a contract. However, if the costs of fringe

benefits would have been incurred regardless of whether the contract had been obtained

(e.g., health insurance premiums), the fringe benefits should not be capitalized. That is, an

entity cannot allocate to the commission and, therefore, capitalize a portion of the costs of

benefits it would provide regardless of whether the commission was paid.

Amortization of capitalized costs to obtain a contract (updated January 2020)

When evaluating the period over which a sales commission should be amortized, entities

should assess whether the amortization period for a sales commission extends beyond the

initial contract period because the capitalized contract costs relate to goods or services that

are transferred under multiple contracts or to a specific anticipated contract (e.g., certain

contract renewals). For example, the expected period of benefit of the sales commission could

extend beyond the first contract, such as when the entity expects the customer to renew PCS

or cloud services.

When determining whether the amortization period for a sales commission extends beyond the

contract period, an entity should also evaluate whether an additional commission is paid for

subsequent renewals. In the Basis for Conclusions of ASU 2014-09,

the FASB explained that

amortizing the asset over a longer period than the initial contract would not be appropriate if an

entity pays a commission on a contract renewal that is commensurate with the commission paid

on the initial contract. In that case, the costs of obtaining the initial contract do not relate to the

subsequent contract. Judgment is required to determine whether a renewal commission is

commensurate with the commission paid on the initial contract. For example, a 6% commission

on an initial contract and a 2% commission on a renewal would not be commensurate even if the

declining commission rate corresponds to the level of effort required to obtain the contracts.

Further, before including estimated renewals in the period of benefit, the entity should evaluate

its history with renewals to conclude that such an estimate is supportable.

The TRG generally agreed

that ASC 340-40 does not require an entity to amortize the asset

over the average customer life. Instead, TRG members said entities would make similar judgments

to those used to estimate the amortization period for intangible assets (e.g., a customer

relationship intangible acquired in a business combination) and could consider factors such as

customer “stickiness” and how quickly their products and services change. Capitalized

contract costs should be amortized over a period that is consistent with the transfer to the

customer of the goods or services to which the asset relates.

EY AccountingLink |

ey.com/us/accountinglink

57 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The following graphic lists some factors (but not all) that should be considered in the

evaluation of the period of benefit:

Consider a technology entity that capitalizes a commission earned on the sale of software,

which the entity estimates it will maintain and support for only the next five years, and the

estimated customer life is seven years. In evaluating the period of benefit, the entity may

reasonably conclude that the capitalized commission should be amortized over the five-year

life of the software to which the commission relates. Entities may need to apply judgment

when determining the amortization period.

In a TRG agenda paper,

the FASB staff discussed two acceptable methods for amortizing

capitalized contract costs related both to the original contract and to renewals in cases in

which the renewal commission is not commensurate with the initial commission:

•

The initial capitalized amount is amortized over the period of benefit that includes expected

renewals, while amounts capitalized related to renewals are amortized over the renewal period.

•

The portion of the initial capitalized amount that is commensurate is amortized over the

original contract term and the additional amount that is not commensurate is amortized

over the period of benefit that includes expected renewals. Capitalized amounts related to

renewals are amortized over the renewal period.

While both methods are acceptable because they each meet the objective of amortizing the

costs on a systematic basis that is consistent with the transfer to the customer of the goods

or services to which the asset relates, an entity should make a policy election to select one

method and apply it consistently for similar circumstances. Other amortization methods may

also be acceptable if they are consistent with the pattern of transfer to the customer of the

goods or services to which the asset relates.

EY AccountingLink |

ey.com/us/accountinglink

58 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

The following example illustrates the two methods described in the TRG agenda paper:

Illustration 23 — Methods for amortizing capitalized contract costs

A SaaS vendor has a commission plan that pays a 6% commission to a sales representative

each time the sales representative obtains a new contract with a customer and a 2%

commission each time that customer renews. Based on the SaaS vendor’s assessment of

the guidance in ASC 340-40, it has concluded that the commissions earned as part of this

commission plan are incremental costs to obtain a contract that are required to be capitalized.

Further, the SaaS vendor has determined that the 2% commission paid for renewals is not

commensurate with the 6% commission paid for initial contracts and, therefore, the period

of benefit for capitalized commissions extends beyond the initial contract term.

The SaaS vendor performs an assessment of customer life, technology turnover (i.e., how

quickly the technology changes due to upgrades and changes to underlying software code)

and competitive factors and concludes that the period of benefit for capitalized commissions

is five years.

The SaaS vendor executes a three-year service contract with a customer for $600,000 and

pays a 6% commission to the sales representative. At the end of the three-year term, the

customer renews the contract for two years for $400,000, and the SaaS vendor pays a 2%

commission to the sales representative.

The following are two acceptable methods for amortizing the capitalized contract costs

related to the $36,000 commission paid on the initial contract and the $8,000 commission

paid on the renewal:

Method 1

The $36,000 commission that was capitalized related to the initial contract is amortized

over the five-year period of benefit. When the contract is renewed, the $8,000 commission

that was capitalized related to the renewal is amortized over the two-year renewal period.

The commission would be amortized as follows:

Year 1 Year 2 Year 3 Year 4 Year 5

Initial commission ($) 7,200 7,200 7,200 7,200 7,200

Renewal commission ($) — — — 4,000 4,000

Total amortization expense ($) 7,200 7,200 7,200 11,200 11,200

Method 2

The $36,000 commission that was capitalized related to the initial contract is separated

into two components: $12,000 that is commensurate with the commission paid on renewal

(i.e., the amount of commission that the $600,000 initial contract earns at the commensurate

rate of 2%) and $24,000 that is not commensurate. The SaaS vendor amortizes the

$12,000 component over the three-year initial contract term and the $24,000 component

over the five-year period of benefit. When the contract is renewed, the $8,000 commission

that was capitalized related to the renewal is amortized over the two-year renewal period.

The commission would be amortized as follows:

Year 1 Year 2 Year 3 Year 4 Year 5

Initial commission (not 4,800 4,800 4,800 4,800 4,800

commensurate) ($)

Initial commission 4,000 4,000 4,000 — —

(commensurate) ($)

Renewal commission ($) — — — 4,000 4,000

Total amortization expense ($) 8,800 8,800 8,800 8,800 8,800

EY AccountingLink |

ey.com/us/accountinglink

59 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Allocating capitalized costs to obtain a contract to individual performance obligations

An entity can attribute the capitalized contract costs to the individual performance obligations in

the contract to determine the appropriate amortization period, but it is not required to do so. An

entity may meet the amortization objective in ASC 340-40-35-1 by allocating the capitalized

contract costs to performance obligations on a relative basis (i.e., in proportion to the transaction

price allocated to each performance obligation) to determine the period of amortization.

For example, an entity executes a contract for $600,000 for a perpetual software license and

one year of PCS. Based on the standalone selling prices, the entity allocates $500,000 (83%)

of the total transaction price to the license and $100,000 (17%) to the PCS. The entity pays a

4% commission to the sales representative and determines that the commission is required to be

capitalized under ASC 340-40 because it is an incremental cost of obtaining the contract. The

entity concludes that the $24,000 sales commission should be allocated between the license

and the PCS and amortized over the expected period of benefit associated with each of those

performance obligations. The entity allocates $20,000 (83%) to the license and $4,000 (17%)

to the PCS, consistent with the relative value of the performance obligations to the

transaction price.

Other methods for allocating capitalized contract costs may be appropriate. Entities should

consistently apply any methods used for allocating capitalized contract costs to performance

obligations.

Impairment of capitalized costs to obtain a contract (updated January 2020)

Because costs that give rise to an asset must continue to be recoverable throughout the

contract period (or period of benefit, if longer) to meet the criteria for capitalization, any

asset recorded by the entity is subject to an impairment assessment at the end of each

reporting period based on the hierarchy described in ASC 340-40-35-5.

This guidance indicates that before recognizing an impairment loss on capitalized contract

costs incurred to obtain a contract, an entity needs to consider impairment losses recognized

in accordance with another topic (e.g., ASC 330, Inventory; ASC 985-20, Software — Costs of

Software to Be Sold, Leased, or Marketed). After applying the impairment test to the

capitalized contract costs in the scope of other topics and those in the scope of ASC 340-40,

an entity includes the resulting carrying amounts in the carrying amount of the asset group or

reporting unit for purposes of applying the guidance in ASC 360, Property, Plant, and

Equipment, or ASC 350, Intangibles — Goodwill and Other.

Entities that record capitalized contract costs on a contract-by-contract basis have to monitor

and record impairment as customers terminate or allow services to lapse (i.e., in line with

customer attrition). Therefore, entities may find a portfolio approach easier to operationalize

than accounting for contract costs individually.

How we see it

Technology entities may capitalize more types of commission costs under the standard than

they did under legacy guidance.

It is important for entities to document the judgments they made when determining the

appropriate period of benefit for amortization of capitalized contract costs and disclose

the same in their financial statements. The standard’s disclosure requirements include

judgments made in determining the amounts of costs that are capitalized, the amortization

method chosen and other quantitative disclosures.

EY AccountingLink |

ey.com/us/accountinglink

60 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Costs to fulfill a contract (updated January 2020)

Technology entities incur costs to fulfill a contract, such as when they install semiconductor

processing equipment or implement cloud services for a customer. These entities need to first

determine whether the installation or implementation activity is eligible for capitalization

under other US GAAP (e.g., property, plant and equipment; intangibles). If it is not eligible for

capitalization under other US GAAP, technology entities need to determine whether the

installation or implementation service meets the definition of a separate performance obligation,

and if it does, expense the costs associated with that performance obligation as incurred.

If the installation or implementation is not a separate performance obligation (see discussion

in the “Implementation services

” section above), a technology entity needs to evaluate

whether it is required to capitalize the costs to fulfill the contract. Costs incurred to fulfill a

contract are required to be capitalized only if those costs meet all of the following criteria:

•

The costs relate directly to a contract or to an anticipated contract that the entity can

specifically identify (e.g., costs relating to services to be provided under renewal of an

existing contract, costs of designing an asset to be transferred under a specific contract

that has not yet been approved).

•

The costs generate or enhance resources of the entity that will be used in satisfying (or in

continuing to satisfy) performance obligations in the future.

•

The costs are expected to be recovered.

The illustrations below contrast an example of SaaS implementation services that are

determined to be a separate performance obligation (and, therefore, are not capitalized as

costs to fulfill a contract) with an example of SaaS implementation services that meet the

criteria for capitalization as costs to fulfill a contract.

Illustration 24 — Implementation services for SaaS are not costs to fulfill

Technology entity M enters into a three-year SaaS contract with a customer for $4,000,000

for a subscription to an inventory management application beginning 1 June 20X3. The

contract includes implementation services that will be performed at the beginning of the

contract, starting on 1 June 20X3. The implementation services include data migration,

creation of objects for the customer’s products that will be inventoried and customization of

the application’s layout with the customer’s logo and color scheme. Several third-party

service providers also sell implementation services for Technology entity M’s application.

Under the contract, the customer receives access to the fully functional SaaS on 1 June 20X3.

Technology entity M considers the implementation services and SaaS and determines that

they are separate performance obligations. This is because the implementation services

and SaaS can be purchased separately. The implementation services, which can be

purchased from third parties, can be used with the SaaS, which is fully functional without

the implementation services and is provided at the outset of the contract.

Further, Technology entity M determines that it does not provide a service of integrating the

SaaS and implementation services and that the implementation services do not significantly

modify or customize the SaaS. Finally, Technology entity M determines that it is able to

fulfill its promise to transfer the SaaS independently from its promise to provide the

implementation services, indicating that the two are not highly interdependent or interrelated.

Technology entity M determines that the costs incurred related to implementation services,

which are a separate performance obligation, do not meet the criteria for capitalization because

they do not relate to the entity’s satisfaction of performance obligations in the future (i.e., the

costs are incurred as the performance obligation for implementation services is satisfied).

EY AccountingLink |

ey.com/us/accountinglink

61 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Illustration 25 — Implementation services for SaaS are costs to fulfill

Technology entity N enters into a contract with a customer for $2,000,000 for a one-year

SaaS subscription to an enterprise software application beginning when the customer

obtains access to the SaaS. The contract includes implementation services that will be

performed at the beginning of the contract, starting on 1 January 20X5. The implementation

services, which will take approximately two months to complete, must be performed in

order for the customer to access the SaaS because the services involve the creation of

customer-specific interfaces. Technology entity N does not sell the SaaS without these

implementation services, and no other vendors are able to perform the implementation

services because they require the creation of code that will reside on Technology entity N’s

servers. Further, Technology entity N anticipates that the customer will renew the contract

annually at least three times.

Technology entity N determines that the implementation services are not capable of being

distinct. This is because they cannot be purchased separately or provided by a third party

and because the services do not provide benefit on their own or with other readily available

resources (since the SaaS has not yet been provided and also cannot be sold separately).

Technology entity N considers the guidance related to performance obligations satisfied

over time and concludes that the combined performance obligation meets the

requirements for recognition over time. It determines that revenue will be recognized over

the contract term, beginning when the customer obtains access to the SaaS.

Next, Technology entity N considers whether the costs incurred related to the implementation

services that will be provided at the outset of the contract (i.e., before the customer

obtains access to the SaaS) meet the criteria to be capitalized as a cost to fulfill the

contract as follows:

•

The costs relate specifically to the SaaS contract with this customer and the three

anticipated renewals.

•

The costs generate a resource (the interfaces) that will be used to provide the SaaS,

the future performance obligation, to the customer.

•

The costs are expected to be recovered based on the margin included in the contract.

As such, Technology entity N determines that the costs should be capitalized as a cost to

fulfill as the implementation services are performed. The costs will then be amortized over

the estimated period of benefit beginning when the customer gains access to the SaaS.

The standard requires entities to expense costs that relate to satisfied (or portions of satisfied)

performance obligations in the contract when they are incurred. This is true even if the

associated revenue has not yet been recognized (e.g., the contract consideration is variable

and has been fully or partially constrained). Once an entity has begun satisfying a performance

obligation that is satisfied over time, it should only capitalize costs that relate to future

performance. Accordingly, it may be challenging for an entity to capitalize costs related to a

performance obligation that the entity has already started to satisfy. If an entity is unable to

determine whether certain costs relate to past or future performance, and the costs are not

eligible for capitalization under other US GAAP guidance, the costs are expensed as incurred.

In addition to direct labor and material costs, examples of costs the standard requires to be

capitalized if certain criteria are met include management and supervision, insurance and

depreciation of the tools and equipment used to fulfill the contract. Technology entities therefore

have to exercise significant judgment to identify all the costs that should be capitalized.

EY AccountingLink |

ey.com/us/accountinglink

62 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

How we see it

A technology entity may incur costs that are required to be capitalized when it performs

implementation services for SaaS or software that are not distinct or when it performs IT

outsourcing services. Determining whether the costs associated with implementation

services for SaaS or software are required to be capitalized may require judgment.

A technology entity first must determine whether the implementation services are a

separate performance obligation. If these services are determined to be a separate

performance obligation, the related costs are expensed as incurred.

If a technology entity determines that implementation services are not a separate performance

obligation, it needs to evaluate whether the related costs meet the three criteria in the

standard to be capitalized. As part of this assessment, an entity needs to evaluate whether

the costs generate or enhance resources of the entity that will be used in satisfying

performance obligations in the future, including whether the implementation services are

required for the customer to use the SaaS or software. This evaluation may be challenging.

Disclosure requirements (updated January 2020)

The standard significantly increases the volume of interim and annual disclosures. For public

entities, these disclosures include disaggregated revenues, qualitative and quantitative

information about contracts with customers, significant judgments made in applying the

standard, and costs to obtain or fulfill a contract. Nonpublic entities can choose to provide the

same or streamlined disclosures.

Some of the specific disclosure requirements that may affect technology entities include:

•

Entities must provide a description of their performance obligations, including an explanation

of when the performance obligations are typically satisfied, significant payment terms

and the nature of the goods or services that the entity has promised to transfer.

•

Entities must disaggregate revenue (e.g., by product or service, geographical region) into

categories that depict how the nature, amount, timing and uncertainty of revenue and

cash flows are affected by economic factors. Entities also have to reconcile any

differences between this disclosure and their segment disclosures. When determining the

categories to use to disaggregate revenue, entities should consider how information

about revenue has been presented for other purposes, including disclosures presented

outside the financial statements and information the chief operating decision maker

reviews to evaluate the performance of operating segments.

•

Entities must disclose the aggregate amount of the transaction price that is allocated to

performance obligations that are unsatisfied (or partially unsatisfied) as of the end of the

reporting period. For example, if an entity estimates a total transaction price of $5 million

for a contract and has recognized $3 million to date, it discloses that $2 million of the

transaction price is yet to be recognized, along with either quantitative or qualitative

information on when the remaining transaction price is expected to be recognized.

•

Entities must disclose significant accounting estimates and judgments made in determining

the transaction price, allocating the transaction price to performance obligations and

determining when performance obligations are satisfied. This requirement includes

information about the methods, inputs and assumptions used for allocating the transaction

price, including estimating standalone selling prices of promised goods and services.

The standard

significantly

increases the

volume of required

revenue disclosures.

EY AccountingLink |

ey.com/us/accountinglink

63 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Entities can elect to use an optional exemption that allows an entity not to make quantitative

disclosures about remaining performance obligations in certain situations, including when

contracts have an original expected duration of less than one year and when an estimate of

the transaction price is made solely for disclosure purposes. These situations also include

(1) when an entity applies the “right to invoice” practical expedient in ASC 606-10-55-18,

(2) when an entity recognizes revenue for licenses of IP following the sales- and usage-based

royalty recognition constraint and (3) when variable consideration is allocated entirely to a

wholly unsatisfied performance obligation or to a wholly unsatisfied promise to transfer a

distinct good or service that forms part of a single performance obligation (i.e., a series of

distinct goods or services) when certain criteria are met.

Entities that elect to use any of the standard’s optional exemptions that allow them not to

disclose the aggregate transaction price allocated to the remaining performance obligations

must disclose which optional exemption(s) they are applying, the nature of the performance

obligations, the remaining duration of the contract and a description of the variable consideration

that has been excluded from the disclosure (e.g., the nature of the variability and how that

variability will be resolved).

How we see it

Preparing the required interim and annual disclosures may require significant effort.

Entities need to make sure that they have appropriate policies and procedures, systems

and internal controls in place to collect and disclose the required information.

Endnotes:

_______________________

Accounting Standards Codification (ASC) 606, Revenue from Contracts with Customers, as amended, was created

by Accounting Standards Update (ASU) 2014-09, Revenue from Contracts with Customers, and various amendments.

ASU 2020-05, Revenue from Contracts with Customers (Topic 606) and Leases (Topic 842): Effective Dates for

Certain Entities.

ASU 2016-13, Financial Instruments — Credit Losses (Topic 326): Measurement of Credit Losses on Financial Instruments.

ASC 985-20-15-5.

Paragraph BC37 of ASU 2016-10, Identifying Performance Obligations and Licensing.

ASC 606-10-55-141 through 55-145.

Although the standard does not describe this evaluation in detail, it indicates that the technical support and updates

are capable of being distinct. While the technical support and updates do not provide any benefit to the customer

without the software license, they are capable of being distinct because they can each provide benefit to the

customer together with the software license, which is considered a readily available resource. The software license is

considered readily available given that it is a resource that is already transferred to the customer under the contract.

ASC 606-10-55-140D through 55-140F.

Paragraph BC71 of ASU 2016-10.

Paragraph BC416 of ASU 2014-09.

Speech by the SEC’s former chief accountant, 9 June 2016. Refer to SEC website at

https://www.sec.gov/news/speech/bricker-remarks-35th-financial-reporting-institute-conference.html

The FASB and the International Accounting Standards Board (IASB) created the TRG to help them determine

whether more guidance is needed on their new revenue standards (ASC 606 and the IASB’s standard, IFRS 15

Revenue from Contracts with Customers) and to educate constituents. While the group met jointly in 2014 and 2015,

only FASB TRG members participated in meetings in 2016.

9 November 2015 TRG meeting; agenda paper no. 45.

ASC 606-10-32-36 through 32-38.

ASC 606-10-32-39 through 32-41.

Paragraph BC271 of ASU 2014-09.

ASC 606-10-32-34(c).

The portion of a bundled price for a software license and PCS that relates only to the software license.

ASC 340-40, Other Assets and Deferred Costs — Contracts with Customers, was created by ASU 2014-09.

ASC 985-605-05-1.

ASC 985-605-25-7.

EY AccountingLink |

ey.com/us/accountinglink

64 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Paragraph BC116 of ASU 2014-09.

13 July 2015 TRG meeting; agenda paper no. 39.

Paragraph BC284 of ASU 2014-09.

18 April 2016 TRG meeting; agenda paper no. 54.

26 January 2015 TRG meeting; agenda paper no. 16.

26 January 2015 TRG meeting; agenda paper no. 25.

ASC 606-10-55-244 through 55-246.

9 November 2015 TRG meeting; agenda paper no. 48.

ASC 606-10-55-114 through 55-116.

This accounting treatment is also achieved when an arrangement does not meet any of the other criteria in

ASC 606-10-25-1 to be accounted for as a contract with a customer.

Paragraph BC31 of ASU 2016-08, Revenue from Contracts with Customers (Topic 606): Principal versus Agent

Considerations.

Paragraph BC16 of ASU 2016-08.

ASC 606-10-55-317 through 55-319.

Paragraph BC38 of ASU 2016-08.

SEC Staff Accounting Bulletin Topic 13 notes entities should consider the guidance on extended payment terms in

ASC 985-605 even if the arrangement is not subject to the scope of that standard.

ASC 606-10-55-216 through 55-220.

13 July 2015 TRG meeting; agenda paper no. 41.

7 November 2016 TRG meeting; agenda paper no. 57.

26 January 2015 TRG meeting; agenda paper no. 23.

Paragraph BC309 of ASU 2014-09.

EY | Assurance | Tax | Strategy and Transactions | Consulting

SCORE No. 04373-171US

(Updated 10 July 2020)

ED None

ey.com/en_us/assurance/accountinglink

About EY

EY is a global leader in assurance, tax, transaction and advisory services. The insights and quality services we deliver help build trust and confidence in the capital markets and in

economies the world over. We develop outstanding leaders who team to deliver on our promises to all of our stakeholders. In so doing, we play a critical role in building a better

working world for our people, for our clients and for our communities.

EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young

Global Limited, a UK company limited by guarantee, does not provide services to clients. Information about how EY collects and uses personal data and a description of the rights

individuals have under data protection legislation are available via ey.com/privacy. For more information about our organization, please visit ey.com.

Ernst & Young LLP is a client-serving member firm of Ernst & Young Global Limited operating in the US.

This material has been prepared for general informational purposes only and is not intended to be relied upon as accounting, tax or other professional advice. Please refer to your advisors for specific advice.

EY AccountingLink |

ey.com/us/accountinglink

65 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Appendix A: The five-step revenue model and contract costs

The standard’s core principle is that an entity recognizes revenue at an amount that reflects the consideration to which the

entity expects to be entitled in exchange for transferring goods or services to a customer. That principle is applied using five

steps that require entities to exercise judgment when considering the terms of their contract(s) and all relevant facts and

circumstances. Entities have to apply the requirements of the standard consistently to contracts with similar characteristics and

in similar circumstances. This table summarizes the new revenue model and the guidance for contract costs.

Step 1: Identify the contract(s) with the customer

Definition of a contract

An entity must first identify the contract, or contracts, to provide goods and services to customers. A contract must create

enforceable rights and obligations to fall within the scope of the model in the standard. Such contracts may be written, oral or

implied by an entity’s customary business practices but must meet the following criteria:

•

The parties to the contract have approved the contract (in writing, orally or based on their customary business

practices) and are committed to perform their respective obligations

•

The entity can identify each party’s rights regarding the goods or services to be transferred

•

The entity can identify the payment terms for the goods or services to be transferred

•

The contract has commercial substance (i.e., the risk, timing or amount of the entity’s future cash flows is expected to

change as a result of the contract)

•

It is probable that the entity will collect substantially all of the consideration to which it will be entitled in exchange for

the goods or services that will be transferred to the customer

If these criteria are not met, an entity would not account for the arrangement using the model in the standard and would

recognize any nonrefundable consideration received as revenue only when certain events have occurred.

Contract combination

The standard requires entities to combine contracts entered into at or near the same time with the same customer (or

related parties of the customer) if they meet any of the following criteria:

•

The contracts are negotiated as a package with a single commercial objective

•

The amount of consideration to be paid in one contract depends on the price or performance of another contract

•

The goods or services promised in the contracts (or some goods or services promised in each of the contracts) are a

single performance obligation

Contract modifications

A contract modification is a change in the scope and/or price of a contract. A contract modification is accounted for as a

new contract separate from the original contract if the modification adds distinct goods or services at a price that reflects

the standalone selling prices of those goods or services. Contract modifications that are not accounted for as separate

contracts are considered changes to the original contract and are accounted for as follows:

•

If the goods and services to be transferred after the contract modification are distinct from the goods or services

transferred on or before the contract modification, the entity should account for the modification as if it were the

termination of the old contract and the creation of a new contract

•

If the goods and services to be transferred after the contract modification are not distinct from the goods and services

already provided and, therefore, form part of a single performance obligation that is partially satisfied at the date of

modification, the entity should account for the contract modification as if it were part of the original contract

•

A combination of the two approaches above: a modification of the existing contract for the partially satisfied

performance obligations and the creation of a new contract for the distinct goods and services

EY AccountingLink |

ey.com/us/accountinglink

66 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Step 2: Identify the performance obligation(s) in the contract

An entity must identify the promised goods and services within the contract and determine which of those goods and services

(or bundles of goods and services) are separate performance obligations (i.e., the unit of accounting for purposes of applying

the standard). An entity is not required to assess whether promised goods or services are performance obligations if they are

immaterial in the context of the contract.

A promised good or service represents a performance obligation if (1) the good or service is distinct (by itself or as part of a

bundle of goods or services) or (2) the good or service is part of a series of distinct goods or services that are substantially

the same and have the same pattern of transfer to the customer.

A good or service (or bundle of goods or services) is distinct if both of the following criteria are met:

•

The customer can benefit from the good or service either on its own or together with other resources that are readily

available to the customer (i.e., the good or service is capable of being distinct)

•

The entity’s promise to transfer the good or service to the customer is separately identifiable from other promises in the

contract (i.e., the promise to transfer the good or service is distinct within the context of the contract)

In assessing whether an entity’s promise to transfer a good or service is separately identifiable from other promises in the

contract, entities need to consider whether the nature of the promise is to transfer each of those goods or services individually

or to transfer a combined item or items to which the promised goods or services are inputs. Factors that indicate two or more

promises to transfer goods or services are not separately identifiable include, but are not limited to, the following:

•

The entity provides a significant service of integrating the goods or services with other goods or services promised in

the contract into a bundle of goods or services that represent the combined output or outputs for which the customer

has contracted

•

One or more of the goods or services significantly modify or customize, or are significantly modified or customized by,

one or more of the other goods or services promised in the contract

•

The goods or services are highly interdependent or highly interrelated. In other words, each of the goods or services is

significantly affected by one or more of the other goods or services in the contract

If a promised good or service is not distinct, an entity is required to combine that good or service with other promised goods

or services until it identifies a bundle of goods or services that is distinct.

Series guidance

Goods or services that are part of a series of distinct goods or services that are substantially the same and have the same

pattern of transfer to the customer must be combined into one performance obligation. To meet the same pattern of

transfer criterion, each distinct good or service in the series must represent a performance obligation that would be

satisfied over time and would have the same measure of progress toward satisfaction of the performance obligation (both

discussed in Step 5), if accounted for separately.

Customer options for additional goods or services

A customer’s option to acquire additional goods or services (e.g., an option for free or discounted goods or services) is

accounted for as a separate performance obligation if it provides a material right to the customer that the customer would

not receive without entering into the contract (e.g., a discount that exceeds the range of discounts typically given for those

goods or services to that class of customer in that geographical area or market).

Principal versus agent considerations

When more than one party is involved in providing goods or services to a customer, an entity must determine whether it is a

principal or an agent in these transactions by evaluating the nature of its promise to the customer. An entity is a principal

and therefore records revenue on a gross basis if it controls the specified good or service before transferring that good or

service to the customer. An entity is an agent and records as revenue the net amount it retains for its agency services if its

EY AccountingLink |

ey.com/us/accountinglink

67 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

role is to arrange for another entity to provide the specified goods or services. Because it is not always clear whether an

entity controls a specified good or service in some contracts (e.g., those involving intangible goods and/or services), the

standard also provides indicators of when an entity may control the specified good or service as follows:

•

The entity is primarily responsible for fulfilling the promise to provide the specified good or service

•

The entity has inventory risk before the specified good or service has been transferred to a customer or after transfer

of control to the customer (e.g., if the customer has a right of return)

•

The entity has discretion in establishing the price for the specified good or service

Step 3: Determine the transaction price

The transaction price is the amount of consideration to which an entity expects to be entitled in exchange for transferring

promised goods or services to a customer. When determining the transaction price, entities need to consider the effects of

all of the following:

Variable consideration

An entity needs to estimate any variable consideration (e.g., amounts that vary due to discounts, rebates, refunds, price

concessions, bonuses) using either the expected value method (i.e., a probability-weighted amount method) or the most

likely amount method (i.e., a method to choose the single most likely amount in a range of possible amounts). An entity’s

method selection is not a “free choice” and must be based on which method better predicts the amount of consideration to

which the entity will be entitled. To include variable consideration in the estimated transaction price, the entity has to

conclude that it is probable that a significant revenue reversal will not occur in future periods. This “constraint” on variable

consideration is based on the probability of a reversal of an amount that is significant relative to cumulative revenue

recognized for the contract. The standard provides factors that increase the likelihood or magnitude of a revenue reversal,

including the following: the amount of consideration is highly susceptible to factors outside the entity’s influence, the entity’s

experience with similar types of contracts is limited or that experience has limited predictive value, or the contract has a large

number and broad range of possible outcomes. The standard requires an entity to estimate variable consideration, including

the application of the constraint, at contract inception and update that estimate at each reporting date.

Significant financing component

An entity needs to adjust the transaction price for the effects of the time value of money if the timing of payments agreed to

by the parties to the contract provides the customer or the entity with a significant financing benefit. As a practical

expedient, an entity can elect not to adjust the transaction price for the effects of a significant financing component if the

entity expects at contract inception that the period between payment and performance will be one year or less.

Noncash consideration

When an entity receives, or expects to receive, noncash consideration (e.g., property, plant or equipment, a financial

instrument), the fair value of the noncash consideration at contract inception is included in the transaction price.

Consideration paid or payable to the customer

Consideration payable to the customer includes cash amounts that an entity pays, or expects to pay, to the customer,

credits or other items (vouchers or coupons) that can be applied against amounts owed to the entity or equity instruments

granted in conjunction with selling goods or services. An entity should account for consideration paid or payable to the

customer as a reduction of the transaction price and, therefore, of revenue unless the payment to the customer is in

exchange for a distinct good or service. However, if the payment to the customer exceeds the fair value of the distinct good

or service received, the entity should account for the excess amount as a reduction of the transaction price.

EY AccountingLink |

ey.com/us/accountinglink

68 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Step 4: Allocate the transaction price to the performance obligations in the contract

For contracts that have multiple performance obligations, the standard generally requires an entity to allocate the transaction

price to the performance obligations in proportion to their standalone selling prices (i.e., on a relative standalone selling price

basis). When allocating on a relative standalone selling price basis, any discount within the contract generally is allocated

proportionately to all of the performance obligations in the contract. However, there are two exceptions.

One exception requires variable consideration to be allocated entirely to a specific part of a contract, such as one or more

(but not all) performance obligations or one or more (but not all) distinct goods or services promised in a series of distinct

goods or services that forms part of a single performance obligation, if both of the following criteria are met:

•

The terms of a variable payment relate specifically to the entity’s efforts to satisfy the performance obligation or

transfer the distinct good or service

•

Allocating the variable consideration entirely to the performance obligation or the distinct good or service is consistent

with the objective of allocating consideration in an amount that depicts the consideration to which the entity expects to

be entitled in exchange for transferring the promised goods or services to the customer

The other exception requires an entity to allocate a contract’s entire discount to only those goods or services to which it

relates if certain criteria are met.

To allocate the transaction price on a relative standalone selling price basis, an entity must first determine the standalone

selling price of the distinct good or service underlying each performance obligation. The standalone selling price is the price

at which an entity would sell a good or service on a standalone (or separate) basis at contract inception. Under the model,

the observable price of a good or service sold separately in similar circumstances to similar customers provides the best

evidence of standalone selling price. However, in many situations, standalone selling prices will not be readily observable. In

those cases, the entity must estimate the standalone selling price by considering all information that is reasonably available

to it, maximizing the use of observable inputs and applying estimation methods consistently in similar circumstances. The

standard states that suitable estimation methods include, but are not limited to, an adjusted market assessment approach,

an expected cost plus a margin approach or a residual approach (if certain conditions are met).

Step 5: Recognize revenue when (or as) the entity satisfies a performance obligation

An entity recognizes revenue only when (or as) it satisfies a performance obligation by transferring control of the promised

good(s) or service(s) to a customer. The transfer of control can occur over time or at a point in time.

A performance obligation is satisfied at a point in time unless it meets one of the following criteria, in which case it is

satisfied over time:

•

The customer simultaneously receives and consumes the benefits provided by the entity’s performance as the

entity performs

•

The entity’s performance creates or enhances an asset that the customer controls as the asset is created or enhanced

•

The entity’s performance does not create an asset with an alternative use to the entity, and the entity has an

enforceable right to payment for performance completed to date

The transaction price allocated to performance obligations satisfied at a point in time is recognized as revenue when control

of the goods or services transfers to the customer. If the performance obligation is satisfied over time, the transaction price

allocated to that performance obligation is recognized as revenue as the performance obligation is satisfied. To do this, the

standard requires an entity to select a single revenue recognition method (i.e., measure of progress) that faithfully depicts

the pattern of the transfer of control over time (i.e., an input method or an output method).

EY AccountingLink |

ey.com/us/accountinglink

69 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Licenses of intellectual property

The standard provides guidance on the recognition of revenue for licenses of IP that differs from the model for other

promised goods and services. The nature of the promise in granting a license of IP to a customer is either:

•

A right to access the entity’s IP throughout the license period (a right to access)

•

A right to use the entity’s IP as it exists at the point in time in which the license is granted (a right to use)

To determine whether the entity’s promise is to provide a right to access its IP or a right to use its IP, the entity should consider

the nature of the IP to which the customer will have rights. The standard requires entities to classify IP in one of two categories:

•

Functional: This IP has significant standalone functionality (e.g., many types of software, completed media content such as

films, television shows and music). Licenses of functional IP generally grant a right to use the entity’s IP, and revenue for

these licenses generally is recognized at the point in time when the IP is made available for the customer’s use and benefit.

This is the case if the functionality is not expected to change substantially as a result of the licensor’s ongoing activities

that do not transfer an additional promised good or service to the customer. If the functionality of the IP is expected to

substantively change because of activities of the licensor that do not transfer additional promised goods or services, and the

customer is contractually or practically required to use the latest version of the IP, revenue for the license is recognized over

time. However, we expect licenses of functional IP to meet the criteria to be recognized over time infrequently, if at all.

•

Symbolic: This IP does not have significant standalone functionality (e.g., brands, team and trade names, character

images). The utility (i.e., the ability to provide benefit or value) of symbolic IP is largely derived from the licensor’s

ongoing or past activities (e.g., activities that support the value of character images). Licenses of symbolic IP grant a

right to access an entity’s IP, and revenue from these licenses is recognized over time as the performance obligation is

satisfied (e.g., over the license period).

Revenue cannot be recognized from a license of IP before both (1) an entity provides (or otherwise makes available) a copy

of the IP to the customer and (2) the beginning of the period during which the customer is able to use and benefit from its

right to access or its right to use the IP.

The standard specifies that sales and usage-based royalties on licenses of IP are recognized when the later of the following events

occurs: (1) the subsequent sales or usage occurs or (2) the performance obligation to which some or all of the sales-based or

usage-based royalty has been allocated has been satisfied (or partially satisfied). This guidance must be applied to the overall

royalty stream when the sole or predominant item to which the royalty relates is a license of IP (i.e., these types of arrangements

are either entirely in the scope of this guidance or entirely in the scope of the general variable consideration constraint guidance).

Contract costs

ASC 340-40 specifies the accounting for costs an entity incurs to obtain and fulfill a contract to provide goods and services

to customers. The incremental costs of obtaining a contract (i.e., costs that would not have been incurred if the contract

had not been obtained) are recognized as an asset if the entity expects to recover them. ASC 340-40 cites commissions as a

type of incremental costs that may require capitalization. The standard provides a practical expedient that permits an entity

to immediately expense contract acquisition costs when the asset that would have resulted from capitalizing these costs

would have been amortized in one year or less.

An entity accounts for costs incurred to fulfill a contract with a customer that are within the scope of other authoritative

guidance (e.g., inventory, property, plant and equipment, internal-use software) in accordance with that guidance. If the

costs are not in the scope of other accounting guidance, an entity recognizes an asset from the costs incurred to fulfill a

contract only if those costs meet all of the following criteria:

•

The costs relate directly to a contract or to an anticipated contract that the entity can specifically identify

•

The costs generate or enhance resources of the entity that will be used in satisfying (or in continuing to satisfy)

performance obligations in the future

•

The costs are expected to be recovered

Any capitalized contract costs are amortized, with the expense recognized as an entity transfers the related goods or services to

the customer. Any asset recorded by the entity is subject to an impairment assessment.

EY AccountingLink |

ey.com/us/accountinglink

70 |

Technical Line

How the new revenue standard affects technology entities Updated 10 July 2020

Appendix B: Additional topics

Technology entities also may need to consider the issues addressed in the following sections

of our FRD publication, Revenue from contracts with customers (ASC 606)

•

Noncash consideration — section 5.6

•

Consideration paid or payable to a customer — section 5.7

•

Customer acceptance — section 7.2.1

•

Warranties — section 9.1