Health Tech Industry Accounting Guide

April 2023
About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms,
and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”)
does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that
operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the
rules and regulations of public accounting. Please see www.deloitte.com/us/about to learn more about our global network of member firms.
 

Other Deloitte Publications

Other Deloitte publications, such as our Roadmap Series, are available on the Deloitte Accounting
Research Tool (DART), a comprehensive online library of accounting and financial disclosure literature.
The Roadmap series includes titles on the following topics:

Business Acquisitions — SEC Reporting Fair Value Measurements and Disclosures

Considerations (Including the Fair Value Option)

Business Combinations Foreign Currency Matters

Carve-Out Transactions Guarantees and Collateralizations —

SEC Reporting Considerations
Comparing IFRS Accounting Standards and
U.S. GAAP Hedge Accounting

Consolidation — Identifying a Controlling Impairments and Disposals of Long-Lived Assets

Financial Interest and Discontinued Operations

Contingencies, Loss Recoveries, and Guarantees Income Taxes

Contracts on an Entity’s Own Equity Initial Public Offerings

Convertible Debt (Before Adoption of ASU 2020-06) Leases

Current Expected Credit Losses Noncontrolling Interests

Debt Non-GAAP Financial Measures and Metrics

Distinguishing Liabilities From Equity Revenue Recognition

Earnings per Share SEC Comment Letter Considerations, Including

Industry Insights
Environmental Obligations and Asset Retirement
Obligations Segment Reporting

Equity Method Investees — SEC Reporting Share-Based Payment Awards

Considerations
Statement of Cash Flows
Equity Method Investments and Joint Ventures
Transfers and Servicing of Financial Assets

iii
Contents
Prefacevii

Contactsviii

Chapter 1 — The Emerging Health Tech Marketplace 1

Chapter 2 — Financial Reporting Considerations Related to Environmental

Events and Activities  5
2.1 Introduction 5
2.2 SEC Reporting Considerations 6
2.3 International Standard-Setting Considerations 6
2.4 Potential Accounting and Reporting Implications of Environmental Objectives 7

Chapter 3 — Capitalized Software 8

3.1 Introduction 8
3.2 Internal-Use Capitalized Software 9
3.2.1 Capitalization of Internal-Use Software Costs 12
3.2.1.1 Preliminary Project Stage 12
3.2.1.2 Application Development Stage 12
3.2.1.3 Postimplementation Stage 14
3.3 Cloud Computing Arrangements 14
3.3.1 Classifying Capitalized Implementation Costs in a CCA That Is a Service Contract 15
3.3.2 Internal-Use Software — Subsequent Measurement  16
3.3.3 Transition Between Internal-Use Software and On-Premise Licensed Software 17
3.3.3.1 Transition to Licensing Software Externally 17
3.3.3.2 Transition to Providing Software Through a Cloud-Based Arrangement 17
3.3.4 Hybrid Cloud-Based Software Solutions 17
3.3.5 Cloud-Based (or Hosting) Service Arrangements  18
3.3.6 Multiple-Element Arrangements 18
3.4 Agile Software Development 18
3.4.1 Cost Tracking in an Agile Software Development Environment 19
3.4.2 Amortization in an Agile Software Development Environment 20
3.4.3 Impairment and Abandonment in an Agile Software Development Environment 21
3.5 Software to Be Sold or Marketed 21
3.5.1 External-Use Software — Subsequent Measurement  25

iv
 Contents

3.6 Other Guidance to Consider 25

3.6.1 Web Site Development Costs 25
3.6.2 Software Used for R&D Activities 26
3.6.3 Significant Production, Modification, or Customization of Software 26
3.6.4 Business Process Reengineering Activities 26
3.7 Importance of Ongoing Reassessment of Software Costs 26
3.8 Income Tax Considerations 28
3.8.1 U.S. Federal Income Tax Considerations 28
3.8.2 U.S. International Tax Considerations 28
3.8.2.1 Foreign-Derived Intangible Income — Section 250 Deduction 29
3.9 Considerations Related to Accounting for Income Taxes 29
3.10 FASB Project on the Accounting for and Disclosure of Software Costs 29

Chapter 4 — Revenue Recognition for Health Tech Companies 31

4.1 Health Tech Customer Solutions — What Do They Look Like? 31
4.1.1 Step 1: Identify the Contract With the Customer 32
4.1.2 Step 2: Identify the Performance Obligations in the Contract 35
4.1.2.1 Evaluating Whether a Good or Service Is Distinct 35
4.1.2.2 Evaluating Whether Goods or Services May Be Considered a Series 41
4.1.3 Step 3: Determine the Transaction Price 45
4.1.3.1 Nonrefundable Up-Front Fees 45
4.1.3.2 Variable Consideration 46
4.1.4 Step 4: Allocate the Transaction Price to the Performance Obligations 48
4.1.5 Step 5: Recognize Revenue When (or as) the Entity Satisfies a Performance Obligation  53
4.1.5.1 Revenue Recognized Over Time 54
4.1.5.2 Practical Expedient for Measuring Progress 55
4.1.5.3 Revenue Recognized at a Point in Time 56
4.1.6 Contract Modifications 59
4.1.6.1 Contract Modification Accounted for as a Separate Contract 59
4.1.6.2 Contract Modification Not Accounted for as a Separate Contract 60
4.1.6.3 Contract Modification Accounted for Prospectively 60
4.1.6.4 Contract Modification Accounted for on a Cumulative Catch-Up Basis 60
4.1.6.5 Combination of Contract Modification Types 60
4.1.6.6 Accounting for Contract Assets as Part of a Contract Modification 61
4.1.6.7 Contract Modifications Versus Price Concessions 61
4.2 Gross Versus Net Revenue Recognition  61
4.3 U.S. Federal Income Tax Considerations 63
4.4 Considerations Related to Accounting for Income Taxes  64
4.5 Applying the Revenue Standard to Identify the Performance Obligations in Arrangements
That Include Smart Devices, Updates, and Cloud-Based Services 64

v
Deloitte | Health Tech Industry Accounting Guide (2023)

4.6 Cloud Conversion or Switching Rights 69

4.6.1 Initial Contract Includes a Cloud Conversion Right 70
4.6.1.1 Alternative 1A — Material Right Model (Preferred View) 70
4.6.1.2 Alternative 1B — Right-of-Return Model (Acceptable View) 72
4.6.2 Initial Contract Is Modified to Convert a Term-Based License to SaaS 74
4.6.2.1 Alternative 2A — Prospective Model (Preferred View) 75
4.6.2.2 Alternative 2B — Return Model (Acceptable View) 76
4.6.3 Initial Contract Is Modified to Add a Cloud Conversion Right 77
4.6.3.1 Alternative 3A — Prospective-Material-Right Model (Preferred View) 77
4.6.3.2 Alternative 3B — Right-of-Return Model (Acceptable View) 78
4.6.4 Initial Contract Includes Cloud Mixing Rights With a Cap 79

Chapter 5 — Costs of Obtaining a Contract 81

5.1 Introduction 81
5.2 Using the Portfolio Approach for Contract Costs 87
5.3 Disclosure Requirements 91

Appendix A — Titles of Standards and Other Literature 93

Appendix B — Abbreviations 95

vi
Preface
We are pleased to present the fourth edition of Deloitte’s Health Tech Industry Accounting Guide. The
convergence of the technology and health care/life sciences industries has caused unique challenges for
management within these sectors. This publication is aimed at identifying and providing guidance on the
most difficult technical accounting issues that are encountered in these sectors.

In addition, this guide provides our perspective on the emerging health tech marketplace as well as
relevant research on health tech investment trends (see Chapter 1).

We also encourage readers to consult Deloitte’s Life Sciences Industry Accounting Guide and Technology Industry
Accounting Guide, which include additional guidance relevant to health tech companies.

We hope this publication helps you navigate the various challenges with health tech and encourage you
to contact your Deloitte team for additional information and assistance.

vii
Contacts

Peter Micca Chris Chiriatti

U.S. Audit & Assurance U.S. Audit & Assurance
Health Tech Industry Leader Managing Director
Deloitte & Touche LLP Deloitte & Touche LLP
+1 646 823 8992 +1 203 761 3039
[email protected] [email protected]

Jeff Ellis
Tori Boegh U.S. Audit & Assurance
Managing Director, Global Life Sciences and Healthcare
Investment and Innovation Industry Leader
Incentives Life Sciences Industry
Deloitte Tax LLP Professional Practice Director
+1 818 970 1292 Deloitte & Touche LLP
[email protected] +1 412 338 7204
[email protected]

David Green
Brian Whisnant
U.S. Tax Life Sciences and
U.S. Audit & Assurance Partner
Healthcare Industry Leader
Deloitte & Touche LLP
Deloitte Tax LLP
+1 704 604 8896
+1 973 602 6287
[email protected]
[email protected]

viii
Chapter 1 — The Emerging Health Tech
Marketplace
The health tech marketplace is a high-growth environment in which participants provide technology and
service solutions to a wide spectrum of health care incumbents, including providers, payers, life sciences
organizations, and transactional players. These companies may provide clinical decision support, drug
discovery/bioinformatics software, health care administration software, and medical imaging software.
They may also offer other products or services, including clinical trial database management, decision
support tools for drug discovery, online marketplaces for pharmaceutical research and development
(R&D), medicinal prediction using artificial intelligence (AI), and Web-based simulation for R&D.

Health tech entities continue to disrupt long-standing business models and methods of health care
delivery as well as sources of health information and ways to access it. Emerging technologies such as
AI, telehealth, blockchain, and monitoring devices (e.g., sensors, wearables, ingestibles) are providing
real-time and continuous data about our health and our environment. Such innovations are redefining
the future of health care and health delivery. Health care and health tech companies can use these
innovations to provide more accurate diagnoses, deliver personalized treatment, and predict risk or
deterioration and intervene early.

As the effects of the 2022 and early 2023 macroeconomic environment swept across the United States,
the health tech market cooled. The health tech sector’s 2022 venture capital funding fell short of 2021
funding, dropping 30 percent from USD 39.3 billion in 2021 to USD 27.5 billion in 2022 (see Figure 1
below). However, investments in 2022 were still approximately 40 percent higher than those in 2020
and more than double those in 2019. As overall venture capital funding continues to trend up, health
tech experts remain optimistic about the opportunities to bring innovation to health care in 2023 and
beyond. To keep pace, innovators that have primarily focused on growth are also finding ways to bridge
longer funding cycles.

1
Deloitte | Health Tech Industry Accounting Guide (2023)

Figure 1: 2022 Was Still a Strong Year for Health Tech Funding

1,134

926
852

782

629
585

39.3
484

27.5

19.7

12.4
11.2
6.7 7.5

2016 2017 2018 2019 2020 2021 2022

Health tech venture capital funding (USD billion) Number of deals

Note: Data for deals valued at USD 2 million and above.

Source: PitchBook Data

A year ago, the Deloitte Center for Health Solutions report New Business Models in Health Care: Building
Platform-Enabled Ecosystems showed a spectrum of reactions to the concept of platform-enabled
ecosystems (“platform businesses”), which deviates from the traditional pipeline business model. Some
industry leaders were bullish on the idea while others expressed skepticism about platform businesses
as a future business model. However, our latest analysis of 2022 later-stage venture funding shows that
8 of the top 10 funded health tech innovators are, by our definition, platform businesses, and we expect
platform businesses to continue to gain traction in the market.

Platform businesses can bring together ecosystem participants on a digital network to co-create
goods and services, providing opportunities for wider customer reach, access to new capabilities, and
increased revenue. In health care, telemedicine platforms allow providers to see patients anywhere and
at a time that works for them. Unlike traditional pipeline businesses, which focus on selling a specific
product or service to customers and competing on cost, quality, or market share, platform businesses
compete on network effects that focus on an improved customer experience and differentiated
offerings (e.g., ridesharing companies). Platform businesses develop an ecosystem through a network
of users and partners who exchange information, services, or goods with each other. By leveraging the
collective power of their users and partners, platform businesses can create more value for consumers
than traditional pipeline businesses.

2
 Chapter 1 — The Emerging Health Tech Marketplace

Key components of a successful, sustainable platform business may include the following:

• Accessibility of underused assets.

• Delegation to ecosystem.
• Modularized components.
• Focus on customer experience.
• Positive network effects.
The health tech market holds much opportunity moving forward, and the sector continues to show
strong signs of growth to disrupt health care. For example, the median health tech deal in 2022 fetched
a valuation of more than USD 57 million, which was substantially higher than the 2021 median (USD 34
million) and that of previous years (see Figure 2).

Figure 2: The Median Valuation for Health Tech Companies Increased 67 Percent From 2021 to
2022

57

34
28
23
21
18
17

2016 2017 2018 2019 2020 2021 2022

Valuation (USD million)

Source: PitchBook Data

3
Deloitte | Health Tech Industry Accounting Guide (2023)

Given the convergence of life sciences, technology, and health care, much of the interpretive guidance in
this guide is likely to be applicable to life sciences and traditional technology entities in addition to health
tech entities. Similarly, given the development and use of software in connection with the product/
service offerings within the health tech space, some of the more narrow-scope considerations related to
the use of software that have historically been the focus of more traditional technology companies — in
particular, considerations related to the capitalization of software costs and the recognition of revenue
from the sale of software products and services — could be important to entities operating in the health
tech space.

4
Chapter 2 — Financial Reporting
Considerations Related to Environmental
Events and Activities

2.1 Introduction
Environmental, social, and governance (ESG) matters have become common topics in the news. At the
same time, investors, credit rating agencies, lenders, regulators, policymakers, and other interested
parties have increasingly focused on these issues. In addition, the FASB, SEC, and CAQ have all provided
public information regarding the importance of considering environmental matters, both for preparers
of financial statements preparers and for auditors.

Given the increased interest in ESG matters from various parties, entities in virtually all industries are
considering how these matters will affect their business strategies, operations, and long-term value. As
entities develop business strategies related to the evolving ESG landscape, they will need to incorporate
ESG considerations into their preparation of financial statements. In doing so, they should ensure that
any plans or commitments related to environmental initiatives are considered in a consistent manner
for both sustainability reporting and the preparation of the financial statements. For example, when
preparing financial statements, an entity that plans to reduce its carbon footprint should evaluate the
impact of those plans, if any, on topics such as the useful life of assets, impairment of assets, asset
retirement obligations, other liabilities, and disclosure requirements under current U.S. GAAP.

Entities may also pursue specific arrangements or transactions in connection with climate-related
objectives that involve complex accounting issues, require significant judgment, or both. For example,
entities that enter into certain types of energy service agreements may need to evaluate whether those
arrangements contain an embedded lease. In addition, for other types of transactions with climate-
related objectives, such as compensation arrangements linked to the achievement of company specific
environmental metrics, entities may be required to assess the probability of achieving such metrics.

The next sections in this chapter examine certain potential impacts of climate-related matters on a
health tech entity’s financial accounting and reporting in the context of the existing accounting guidance
and the current regulatory environment. While these impacts may vary depending on the nature of the
entity’s business, along with factors such as relevant regulatory, legal, and contractual obligations, all
health tech entities should evaluate environment-related financial accounting and reporting implications.

5
Deloitte | Health Tech Industry Accounting Guide (2023)

2.2 SEC Reporting Considerations

Health tech entities should be mindful of SEC reporting requirements regarding climate-related
disclosures. In recent years, the SEC has also increased its focus on climate-related disclosures in its
review of public-company filings, including assessing the extent to which the information provided
by such companies is consistent with the SEC’s 2010 interpretive release. On September 22, 2021,
it publicly released a sample letter that highlighted the types of comments it may issue to public
companies regarding climate-related disclosures. Within the past year, the SEC has issued comments to
public companies in a variety of industries.

In March 2022, the SEC issued a proposed rule that would require that registrants disclose (1) certain
climate-related financial impacts and expenditure metrics as well as a discussion of such impacts
on their financial estimates and assumptions within the audited financial statements and (2) certain
greenhouse gas metrics and qualitative information in their annual report but outside the audited
financial statements. With the SEC expected to issue its final rule in the coming months, entities should
be mindful of climate-related SEC reporting requirements, particularly those associated with the
business, risk factors, MD&A, and results of operations sections of SEC filings.

For more information about recent SEC communications regarding climate-related matters, see
Deloitte’s September 27, 2021, and March 21, 2022 (updated March 29, 2022), Heads Up newsletters.
Stay tuned for further developments related to the proposed rule.

2.3 International Standard-Setting Considerations

Entities should also be mindful of the international progress toward developing a common set of
sustainability reporting standards regarding climate change and climate-related topics. In November
2022, the European Council and the European Parliament approved the final text of the Corporate
Sustainability Reporting Directive (CSRD), which will require sustainability reporting by a substantial
number of companies that previously were not subject to mandatory sustainability reporting. The CSRD
will affect all companies with significant operations in E.U. jurisdictions, including U.S.-based companies
with as little as one subsidiary or branch in the European Union. For more information about the CSRD,
see Deloitte’s January 9, 2023, Heads Up.

During the 2022 AICPA & CIMA Conference on Current SEC and PCAOB Developments, several speakers
highlighted the following proposals:

• The SEC’s March 2022 proposed rule on climate-related disclosures, which would apply to all
companies that are currently SEC registrants or that are seeking registration on a U.S. exchange.

• The International Sustainability Standards Board’s exposure drafts IFRS S1 (on disclosure
requirements associated with sustainability-related financial information) and IFRS S2 (on
climate-related disclosures).

Paul Munter, then acting SEC chief accountant (who is currently the SEC’s chief accountant), noted that
the SEC is actively monitoring climate-related rulemaking by other standard setters in an effort to work
with, and learn from, these standard setters to shape the Commission’s final rule on climate-related
disclosures. Nigel James, senior associate chief accountant in the SEC’s Office of the Chief Accountant
(OCA), highlighted the SEC’s role on the IFRS Foundation Monitoring Board and how this allows the SEC
to be active in international standard setting.

6
 Chapter 2 — Financial Reporting Considerations Related to Environmental Events and Activities

2.4 Potential Accounting and Reporting Implications of Environmental

Objectives
Entities from various industries have begun issuing public statements regarding their plans to address
the impacts of climate change on their businesses, and recent news headlines have often highlighted
these statements — for example, “Entity A commits to being carbon neutral by 2030” or “Entity B
pledges to reduce greenhouse gas emissions by 90% by 2040.” As a result, questions have arisen about
the accounting and disclosure considerations related to such statements. Such considerations will
depend on the specific facts and circumstances of an entity’s climate-related public statements, plans,
and actions.

It is critical to understand how the plans and actions of management (i.e., personnel with the
appropriate authority) align with its specific public statements (e.g., those made by the two entities in
the preceding paragraph). By obtaining such an understanding, an entity will be better able to assess
the effect of its climate-related public statements and supporting plans and actions on its net assets,
including whether any assets are impaired or any contractual liabilities exist. For example, Entity A may
operate in a jurisdiction or industry in which it is required to provide a certain level of carbon offsets,
either internally generated or purchased, as part of its plan to become carbon neutral. Depending on
the facts and circumstances of the government regulation and A’s specific operation, A’s obligation
to provide carbon offsets for carbon emissions may result in a liability that needs to be recorded,
potentially disclosed, or both.

7
Chapter 3 — Capitalized Software

3.1 Introduction
Health tech companies rely on the development of proprietary software to serve their customers and
clients. In determining which authoritative guidance to apply to the capitalization of software, a company
would consider how it plans to offer its software solutions to its customers. ASC 985-20 provides
authoritative guidance on software solutions that are often referred to as “external-use software,” while
ASC 350-40 contains authoritative guidance on internal-use software solutions.

Specifically, ASC 985-20 addresses the identification and determination of software development
costs that are incurred and whether such costs are related to the development or implementation of
“external-use” or “internal-use” software. This guidance indicates that in assessing how to account for
these software development costs, an entity should determine whether there is a substantive plan
to market the software externally or whether one will be created during the software’s development
period. ASC 350-40, which applies to software developed or obtained for internal use, including in
providing a service (e.g., “software as a service”), requires that any plan to market internal-use software
be substantive before the entity looks to ASC 985-20 to determine the accounting for the software
project.

A substantive plan to market the software externally could include the selection of a marketing channel
with identified promotional, delivery, billing, and support activities. To be considered substantive, a plan
should be at least reasonably possible to implement. Arrangements providing for the joint development
of software for mutual internal use (e.g., cost-sharing arrangements) and routine market feasibility
studies are not substantive plans to market software.

ASC 350-40-35-9 states that “[i]f, during the development of internal-use software [subject to ASC
350-40], an entity decides to market the software to others, the entity shall follow the guidance in
Subtopic 985-20.” As indicated above, this decision should be supported by a substantive plan before
the entity switches to ASC 985-20. Specifically, ASC 350-40-35-9 states that if there is a substantive
plan to market the software externally, “[a]mounts previously capitalized under [ASC 350-40] shall be
evaluated at each balance sheet date in accordance with paragraph 985-20-35-4.”

Under ASC 350-40-35-7, if an entity markets the software after the development of internal-use software
is completed, the proceeds received, “net of direct incremental costs of marketing, such as commissions,
software reproduction costs, warranty and service obligations, and installation costs, shall be applied
against the carrying amount of that software.” Further, ASC 350-40-35-8 notes that “[n]o profit shall
be recognized until aggregate net proceeds from licenses and amortization have reduced the carrying
amount of the software to zero. Subsequent proceeds shall be recognized as revenue in accordance
with Topic 606 on revenue from contracts with customers or recognized as a gain in accordance with
Subtopic 610-20 on derecognition of nonfinancial assets if the contract is not with a customer.”

8
 Chapter 3 — Capitalized Software

It is critical for an entity to identify software development costs and determine how they should be
accounted for; in doing so, an entity’s management must exercise significant judgment. The guidance
restricts the recognition of any profit when software whose costs were previously determined to be
internal-use is marketed in the future.

3.2 Internal-Use Capitalized Software

In their start-up phase, or even upon maturity, health tech companies are likely to incur significant
software-related costs. Many of these software-related costs can be identified as “internal-use.” ASC
350-40-15-2A describes internal-use software as having both of the following characteristics:
a. The software is acquired, internally developed, or modified solely to meet the entity’s internal needs.
b. During the software’s development or modification, no substantive plan exists or is being developed to
market the software externally.

ASC 350-40-55-1 and 55-2 address situations in which software is for internal use or not for internal
use, respectively. While not all of these examples apply to health tech companies, the full list has been
incorporated for completeness.

ASC 350-40

55-1 The following is a list of examples illustrating when computer software is for internal use:
a. A manufacturing entity purchases robots and customizes the software that the robots use to function.
The robots are used in a manufacturing process that results in finished goods.
b. An entity develops software that helps it improve its cash management, which may allow the entity to
earn more revenue.
c. An entity purchases or develops software to process payroll, accounts payable, and accounts receivable.
d. An entity purchases software related to the installation of an online system used to keep membership
data.
e. A travel agency purchases a software system to price vacation packages and obtain airfares.
f. A bank develops software that allows a customer to withdraw cash, inquire about balances, make loan
payments, and execute wire transfers.
g. A mortgage loan servicing entity develops or purchases computer software to enhance the speed of
services provided to customers.
h. A telecommunications entity develops software to run its switches that are necessary for various
telephone services such as voice mail and call forwarding.
i. An entity is in the process of developing an accounts receivable system. The software specifications
meet the entity’s internal needs and the entity did not have a marketing plan before or during the
development of the software. In addition, the entity has not sold any of its internal-use software in the
past. Two years after completion of the project, the entity decided to market the product to recoup
some or all of its costs.
j. A broker-dealer entity develops a software database and charges for financial information distributed
through the database.
k. An entity develops software to be used to create components of music videos (for example, the software
used to blend and change the faces of models in music videos). The entity then sells the final music
videos, which do not contain the software, to another entity.
l. An entity purchases software to computerize a manual catalog and then sells the manual catalog to the
public.
m. A law firm develops an intranet research tool that allows firm members to locate and search the firm’s
databases for information relevant to their cases. The system provides users with the ability to print
cases, search for related topics, and annotate their personal copies of the database.

9
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 350-40 (continued)

55-2 The following list provides examples of computer software that is not for internal use:
a. An entity sells software required to operate its products, such as robots, electronic game systems, video
cassette recorders, automobiles, voice-mail systems, satellites, and cash registers.
b. A pharmaceutical entity buys machines and writes all of the software that allows the machines to
function. The pharmaceutical entity then sells the machines, which help control the dispensation of
medication to patients and help control inventory, to hospitals.
c. A semiconductor entity develops software embedded in a microcomputer chip used in automobile
electronic systems.
d. An entity purchases software to computerize a manual catalog and then sells the computer version and
the related software to the public.
e. A software entity develops an operating system for sale and for internal use. Though the specifications
of the software meet the entity’s internal needs, the entity had a marketing plan before the project was
complete. In addition, the entity has a history of selling software that it also uses internally and the plan
has a reasonable possibility of being implemented.
f. An entity is developing software for a point-of-sale system. The system is for internal use; however,
a marketing plan is being developed concurrently with the software development. The plan has a
reasonable possibility of being implemented.
g. A telecommunications entity purchases computer software to be used in research and development
activities.
h. An entity incurs costs to develop computer software for another entity under a contract with that other
entity.

Whether software qualifies as internal-use software is not intended to be a choice entities may make
freely; rather, they should carefully evaluate whether the software is within the scope of ASC 350-40.
If the software is or will be marketed externally (i.e., marketed to be sold or licensed on an on-premise
basis), the costs will be within the scope of ASC 985-20. Therefore, if a substantive plan to market the
software externally exists or is being developed during the software development period, regardless of
whether the software is also intended to meet an internal need, the costs will be subject to ASC 985-20.
To be subject to the guidance in ASC 350-40, the software must be intended solely for internal use. As a
reminder, to be considered substantive, a marketing plan needs to be relatively detailed and should take
into account, among other matters, marketing channels and promotion, delivery, billing, and support
systems. Further, implementation of the plan should be at least reasonably possible. Routine market
feasibility studies would not be considered a substantive plan. In many cases, it will be obvious that
software is obtained or developed solely to meet an entity’s internal needs (e.g., enterprise resource
planning [ERP] software purchased from a third-party vendor and used solely by the entity to process
business transactions). In other circumstances, entities will need to carefully evaluate how the software
is or will be used to determine whether it is subject to ASC 350-40. In addition, the guidance in ASC
350-40 must be applied at the individual component or module level. While there is no specific guidance
on what an individual component or module might be, an entity could consider the level of functionality
each component or module provides as well as the level of interdependence between the components
or modules.

Health tech companies often choose to develop a software-as-a-service (SaaS) solution, offering services
to their customers in such a way that customers may not take possession of the underlying solution.
Rather, the customer accesses the solution, normally via an online portal. The costs of developing
the SaaS solution — including, but not limited to, the formulation of conceptual ideas regarding the
identified product need, designing of the solution, specific coding associated with the solution, and
testing of the different versions developed — are all considered internal-use capitalized software costs
that may be subject to the guidance in ASC 350-40.

10
 Chapter 3 — Capitalized Software

An entity may encounter difficulties related to determining whether a hosting arrangement or a SaaS
solution that the entity is developing should be considered internal-use or external-use.

ASC 350-40

15-4A The guidance in the General Subsections of this Subtopic applies only to internal-use software that a
customer obtains access to in a hosting arrangement if both of the following criteria are met:
a. The customer has the contractual right to take possession of the software at any time during the hosting
period without significant penalty.
b. It is feasible for the customer to either run the software on its own hardware or contract with another
party unrelated to the vendor to host the software.

15-4B For purposes of the guidance in paragraph 350-40-15-4A(a), the term without significant penalty
contains two distinct concepts:
a. The ability to take delivery of the software without incurring significant cost
b. The ability to use the software separately without a significant diminution in utility or value.

15-4C Hosting arrangements that do not meet both criteria in paragraph 350-40-15-4A are service contracts
and do not constitute a purchase of, or convey a license to, software.

Example 3-1

Company A, a telehealth company, is developing a hosted solution that would enable users to directly connect
with a health care provider. Company A does not plan on selling the hosted solution as a software product, and
its marketing department is not developing or designing promotional material indicating that A would make
such a sale. Furthermore, A’s executive leadership has confirmed that it is not reasonably possible that it could
sell the hosted solution as a software product. Therefore, A does not have a substantive marketing plan and
should account for the costs of the new hosted solution under ASC 350-40.

Example 3-2

Company B offers its office productivity software solution as a SaaS in which its customers have access to the
solution through an online portal and store data on B’s secure servers. The software will always be maintained
at the most up-to-date version available, and customers have rights to online and telephone support.
Customers do not have the ability to take possession of the software.

Because customers are not permitted to take possession of the software and may use only B’s cloud-based
service, B concludes that the costs associated with its office productivity software should be accounted for
under ASC 350-40.

The terms of a health tech company’s agreements may vary from customer to customer. To appropriately
apply the guidance in ASC 350-40-15-4, a company may need to evaluate these differing terms at the
individual agreement level. If the hosting arrangement does meet the criteria in this guidance, the
software would be considered external-use and would be subject to the guidance in ASC 985-20. That
is, if the software is externally marketed or sold as a result of only one agreement that the health tech
company has entered into with its customers, the software may be considered external-use.

11
Deloitte | Health Tech Industry Accounting Guide (2023)

3.2.1 Capitalization of Internal-Use Software Costs

A health tech company’s timeline for developing an internal-use software solution is divided into stages:
(1) the preliminary project stage, (2) the application development stage, and (3) the postimplementation
stage. It is critical to identify these stages and evaluate their distinct characteristics to determine whether
costs are capitalizable and, if so, what types.

3.2.1.1 Preliminary Project Stage

In the preliminary project stage, a health tech company assesses alternatives related to the solution to
an issue or problem and evaluates its best options going forward. The ASC master glossary defines the
preliminary project stage as follows:

When a computer software project is in the preliminary project stage, entities will likely do the following:
a. Make strategic decisions to allocate resources between alternative projects at a given point in time.
For example, should programmers [for the health tech company] develop a new [patient data tracking]
system or direct their efforts toward correcting existing problems in [a previously developed patient
data tracking] system?
b. Determine the performance requirements (that is, what it is that they need the software to do) and
systems requirements for the computer software project it has proposed to undertake.
c. Invite vendors to perform demonstrations of how their software will fulfill an entity’s needs.
d. Explore alternative means of achieving specified performance requirements. For example, should an
entity make or buy the software? . . .
e. Determine that the technology needed to achieve performance requirements exists.
f. Select a vendor if an entity chooses to obtain software.
g. Select a consultant to assist in the development or installation of the software.

ASC 350-40

25-1 Internal and external costs incurred during the preliminary project stage shall be expensed as they are
incurred.

3.2.1.2 Application Development Stage

Upon selecting the alternative that it is going to use as the solution to its need or problem, a health tech
company will begin incurring costs related to developing this solution. The costs incurred during this
stage are not related to any R&D activities. Rather, they pertain to developing a solution that is expected
to work as intended.

ASC 350-40-55-3(b) states that a project in the application development stage may consist of the
following processes:
1. Design of chosen path, including software configuration and software interfaces
2. Coding
3. Installation to hardware
4. Testing, including parallel processing phase.

12
 Chapter 3 — Capitalized Software

ASC 350-40

25-2 Internal and external costs incurred to develop internal-use computer software during the application
development stage shall be capitalized.

ASC 350-40-30-1 outlines the different types of capitalizable costs that could be incurred for software
developed or obtained:
a. External direct costs of materials and services consumed in developing or obtaining internal-use
computer software. Examples of those costs include but are not limited to the following:
1. Fees paid to third parties for services provided to develop the software during the application
development stage
2. Costs incurred to obtain computer software from third parties
3. Travel expenses incurred by employees in their duties directly associated with developing software.
b. Payroll and payroll-related costs (for example, costs of employee benefits) for employees who are
directly associated with and who devote time to the internal-use computer software project, to the
extent of the time spent directly on the project. Examples of employee activities include but are not
limited to coding and testing during the application development stage.
c. Interest costs incurred while developing internal-use computer software. Interest shall be capitalized in
accordance with the provisions of Subtopic 835-20.

ASC 350-40-30-2 clarifies that if the health tech company “suspends substantially all activities related to
the software developed or obtained for internal use, interest capitalization shall cease until activities are
resumed.”

Questions have arisen regarding the inclusion of share-based compensation costs in the payroll
and payroll-related costs that the health tech company should capitalize. For example, a health tech
company may develop software for internal use. ASC 350-40-30-1(b) requires that payroll and payroll-
related costs be capitalized for “employees who are directly associated with and who devote time to the
internal-use computer software project.”

Further, paragraph 80 of the Basis for Conclusions of SOP 98-1 states that “AcSEC used SOP 93-7,
Reporting on Advertising Costs [codified in ASC 340-20], and FASB Statement No. 91, Accounting for
Nonrefundable Fees and Costs Associated With Originating or Acquiring Loans and Initial Direct Costs of Leases
[codified in ASC 310-20] as a basis for determining the kinds of costs of computer software developed
or obtained for internal use that should be included in amounts reported as assets.” ASC 340-20-30-2
and the definition of “direct loan origination costs” in ASC 310-20-20 address costs that should be
capitalized for direct response advertising and loan origination fees, respectively. Both paragraphs state,
in part, that the “costs directly related to those activities shall include only that portion of the employees’
total compensation and payroll-related fringe benefits directly related to time spent performing those
activities.” Therefore, stock-based compensation plans are part of an employee’s total compensation
and payroll-related fringe benefits. Accordingly, costs associated with participants in stock-based
compensation plans who work directly on internal-use software development projects should be
capitalized to the extent that the capitalization criteria in ASC 350-40 have been met.

Health tech companies may purchase internal-use software from a third party. Such software purchases
may include multiple products or elements. ASC 350-40-30-4 states that such elements can include
“training for the software, maintenance fees for routine maintenance work to be performed by the third
party, data conversion costs, reengineering costs, and rights to future upgrades and enhancements.”

13
Deloitte | Health Tech Industry Accounting Guide (2023)

Health tech companies should allocate the cost of the software package among all of the identified
individual elements. The allocation should be based on objective evidence of the fair value of the
elements in the contract, not necessarily separate prices stated within the contract for each element.
The capitalization, or expensing, of such elements to which a portion of the cost incurred is allocated
should be based on the nature of the elements, which the health tech company assesses in considering
ASC 350-40-30-17.

3.2.1.3 Postimplementation Stage
Upon completion of the activities related to developing the health tech company’s software solution,
costs incurred are identified as part of the postimplementation stage. During this stage, the health tech
company will provide training to users of the solution and further maintain the solution by, for example,
completing bug fixes.

Connecting the Dots

Health tech company management must use judgment in determining the stage in which
the company incurs the types of costs it has identified. Furthermore, the incurrence of costs
associated with the health tech company’s solution may not be linear. For example, training
services could occur during all stages, but the costs of such services are not capitalizable even if
the health tech company believes that they are incurred in the application development stage.

3.3 Cloud Computing Arrangements

Many health tech companies rely on service arrangements with cloud computing vendors for multiple
functions, including ERP, customer relationship management, and supply chain management, to name
a few. Because the expenditures associated with the development and use of such services as part of
a cloud computing arrangement (CCA) can be material to a health tech company, such expenditures
would need to be considered.

In August 2018, the FASB issued ASU 2018-15, which amends ASC 350-40 to address a customer’s
accounting for implementation costs incurred in a CCA that is a service contract. ASU 2018-15 aligns
the accounting for costs incurred to implement a CCA that is a service arrangement with the guidance
on capitalizing costs associated with developing or obtaining internal-use software. Specifically, the ASU
amends (1) ASC 350 to include in its scope implementation costs of a CCA that is a service contract and
(2) clarifies that a customer should apply ASC 350-40 to determine which implementation costs should
be capitalized in a CCA that is considered a service contract.

Capitalized costs associated with a service contract differ in character from costs that are capitalized in
connection with developing or obtaining internal-use software. As a result, costs that are capitalized
in connection with implementing a CCA are likely to be presented differently (in the recognition both
on the balance sheet and in the statement of cash flows and in the subsequent derecognition through
the income statement) from costs incurred to develop or acquire internal-use software. Many entities,
including health tech companies, are implementing software solutions that combine hosted software in
a CCA with owned or licensed (i.e., internal-use) software.

While ASU 2018-15 clarifies what constitutes a “hosting arrangement,” it does not modify the scoping
guidance that differentiates a software license (i.e., internal-use software) from a CCA. That is, under
ASC 350-40-15-4A, even if software is being hosted on a third party’s platform, an entity will still need to
assess the specific circumstances associated with the individual arrangement.

14
 Chapter 3 — Capitalized Software

Health tech companies will have to carefully evaluate whether the following criteria in ASC 350-40-15-4A
are met:
a. The customer has the contractual right to take possession of the software at any time during the
hosting period without significant penalty.
b. It is feasible for the customer to either run the software on its own hardware or contract with another
party unrelated to the vendor to host the software.

If both of these criteria are met, the related software is considered internal-use software even if it is
being hosted by a third-party vendor or the hosted software is interacting with software that is subject
to a CCA (i.e., software that the entity cannot take possession of). If one or both of these criteria are not
met, the software is considered part of a hosting arrangement that is a service contract.

ASU 2018-15 aligns a customer’s recognition of implementation costs incurred in a CCA with the legacy
internal-use software guidance. Such policies have not historically applied to CCA implementation
costs; thus, an entity might need to establish new processes for adapting existing accounting policies to
address CCA arrangements.

Connecting the Dots

CCA implementation costs incurred during the preliminary project and postimplementation
stages are treated differently from those incurred during the application development stage;
therefore, an entity should establish processes for distinguishing these costs. In some instances,
health tech companies make payments directly to a CCA vendor that will provide both the
implementation services and the ongoing cloud computing services under the arrangement with
the vendor. Because not all costs incurred during the application development stage can be
capitalized, the health tech company will need to determine how best to identify what portion
of the fees paid to the CCA service provider must be capitalized and what portion must be
expensed as incurred. In such circumstances, an entity typically will be required to identify the
activities the service provider is performing that are not eligible for capitalization (e.g., training
costs) and allocate the fees paid to the provider to the various activities on the basis of each
element’s stand-alone selling price (SSP) (which may not be the contractual price). For some
large-scale cloud deployments, implementation costs can be significant (sometimes higher
than the cost associated with the CCA service fee), thereby underscoring the importance of
appropriately identifying capitalizable implementation costs.

3.3.1 Classifying Capitalized Implementation Costs in a CCA That Is a Service

Contract
The model used to determine which costs are capitalized in connection with implementing a hosting
arrangement is the same regardless of whether the underlying software qualifies as internal-use or is
provided as part of a CCA. However, since there are differences in how the costs are characterized, it
will be important for health tech companies to analyze what the costs are related to. This is because
capitalized implementation costs related to a CCA that is a service contract are classified and presented
differently from capitalized costs associated with developing or obtaining internal-use software. Eligible
costs incurred to implement a CCA that is a service contract should be capitalized as a prepaid asset
and presented in a company’s financial statements in the same line item in the income statement as
the hosting service expense (e.g., as an operating expense). Such presentation is consistent with the
classification of other service costs and assets related to service contracts. That is, these costs would be
capitalized as part of the service contract, and the financial statement presentation of the cash flows,
the resulting asset, and the related subsequent expense would be consistent with the ongoing periodic
costs of the underlying CCA that is a service contract.

15
Deloitte | Health Tech Industry Accounting Guide (2023)

By contrast, any capitalized costs incurred that are associated with developing or obtaining internal-use
software become part of the underlying software asset (which is generally considered an intangible
asset). As with other intangible assets, the costs incurred to obtain a software asset are generally capital
in nature and thus are treated similarly to the costs of acquiring property, plant, and equipment.

3.3.2 Internal-Use Software — Subsequent Measurement

An impairment for an internal-use software product should be recognized and measured in accordance
with ASC 360-10. Specifically, the software assets must be grouped at the lowest level at which
identifiable cash flows are largely independent of the cash flows of other groups of assets or other
internal-use software products. This guidance applies when certain triggering events occur. ASC 350-40-
35-1 states that such triggering events include:
a. Internal-use computer software is not expected to provide substantive service potential.
b. A significant change occurs in the extent or manner in which the software is used or is expected to be
used.
c. A significant change is made or will be made to the software program.
d. Costs of developing or modifying internal-use computer software significantly exceed the amount
originally expected to develop or modify the software.

Health tech companies should be aware that such triggering events do not include situations in which
the software that is developed is no longer in use. In those situations, the company should look to ASC
350-40-35-2, which refers to ASC 360-10-35-47 through 35-49. A health tech company that commits to a
plan to abandon a capitalized software asset before the end of its previously estimated useful life should
revise depreciation or amortization estimates in accordance with ASC 250-10-45-17 through 45-20 and
ASC 250-10-50-4 to reflect the use of the capitalized software asset over its shortened useful life. In such
situations, the useful life would usually end on the date the health tech company plans to cease use of
the capitalized software asset. Furthermore, ASC 360-10-35-48 notes that “[b]ecause the continued use
of a long-lived asset demonstrates the presence of service potential, only in unusual situations would
the fair value of a long-lived asset to be abandoned be zero while it is being used. When a long-lived
asset ceases to be used, the carrying amount of the asset should equal its salvage value, if any. The
salvage value of the asset shall not be reduced to an amount less than zero.” Moreover, ASC 360-10-
35-49 indicates that “[a] long-lived asset that has been temporarily idled shall not be accounted for as if
[it were] abandoned.”

ASC 350-40-35-3 further clarifies that “[w]hen it is no longer probable that computer software being
developed will be completed and placed in service, the asset shall be reported at the lower of the
carrying amount or fair value, if any, less costs to sell.” Specifically, this paragraph states that “[t]he
rebuttable presumption is that [the uncompleted internal-use] software has a fair value of zero.” In
addition, the guidance further provides the following indicators that the internal-use software product
“may no longer be expected to be completed and placed [into] service”:
a. A lack of expenditures budgeted or incurred for the project.
b. Programming difficulties that cannot be resolved on a timely basis.
c. Significant cost overruns.
d. Information has been obtained indicating that the costs of internally developed software will significantly
exceed the cost of comparable third-party software or software products, so that management intends
to obtain the third-party software or software products instead of completing the internally developed
software.

16
 Chapter 3 — Capitalized Software

e. Technologies are introduced in the marketplace, so that management intends to obtain the third-party
software or software products instead of completing the internally developed software.
f. Business segment or unit to which the software relates is unprofitable or has been or will be
discontinued.

Health tech companies should continually monitor their software projects to ensure that they have
not identified any indicators that the software product may no longer be expected to be completed or
placed into service.

3.3.3 Transition Between Internal-Use Software and On-Premise Licensed

Software
3.3.3.1 Transition to Licensing Software Externally
After the development of internal-use software, a health tech company may decide to license the
software externally on an on-premise basis. If so, the entity must first account for any proceeds received
from the license of the software, net of any direct incremental costs (e.g., commissions, reproduction,
warranties, and installation), as a reduction of the carrying amount of any costs for that software that
were capitalized under ASC 350-40. It cannot recognize profit on the software until it has reduced
the carrying amount to zero. When the entity has reduced the carrying amount to zero (including any
amortization of the software), it can then recognize subsequent proceeds as revenue under ASC 606 (or
a gain under ASC 610-20 if the contract is not with a customer). Any subsequent software development
costs for that software product are then subject to ASC 985-20.

If the decision to market the software externally is made during its development, any software costs
incurred prospectively are accounted for under ASC 985-20. As indicated above, this decision should be
supported by a substantive plan before the entity switches to ASC 985-20. In addition, amortization and
impairment assessments should likewise be subject to ASC 985-20.

3.3.3.2 Transition to Providing Software Through a Cloud-Based Arrangement

Because there have been significant shifts over time to migrate software solutions to the cloud, it is
common for software entities to sell software on both an on-premise licensed basis and a cloud basis. In
those circumstances, any software costs are subject to ASC 985-20.

However, scope questions have arisen in situations in which an entity predominantly sells and provides
a software solution through cloud-based arrangements. We believe that as long as there continue
to be substantive external sales of on-premise software, the software costs should still be subject
to ASC 985-20. Neither ASC 985-20 nor ASC 350-40 provides transition guidance on situations in
which an entity no longer has substantive external sales of on-premise software. We think that, in
such circumstances, it is reasonable to account for any future software development costs that add
functionality that will only be available as part of the cloud-based solution in accordance with ASC 350-40
and to account for the aggregate amount of capitalized software costs for the software prospectively
under ASC 350-40 (e.g., amortization and impairment). We believe that a health tech company should
use judgment in determining whether there are any substantive external sales of on-premise software.

3.3.4 Hybrid Cloud-Based Software Solutions

Some health tech companies sell hybrid cloud-based software solutions, in which on-premise licensed
software is sold with cloud-based software. Often, the on-premise licensed software interacts with the
cloud-based software and, in some circumstances, the on-premise licensed software may be significantly
integrated, interdependent, or interrelated with the cloud-based software.

17
Deloitte | Health Tech Industry Accounting Guide (2023)

In these situations, a health tech company must carefully track its software costs to determine which
are (1) subject to ASC 985-20 (because there are substantive sales of on-premise licensed software)
or (2) subject to ASC 350-40 (because the software is sold only as a service). Even if the on-premise
software is significantly integrated, interdependent, or interrelated with the cloud-based software, it
generally would not be appropriate to account for all software costs under ASC 985-20 if the software
that is sold only as a service is substantive. Likewise, it generally would not be appropriate to account for
all software costs under ASC 350-40 if the software sold on an on-premise licensed basis is substantive.

3.3.5 Cloud-Based (or Hosting) Service Arrangements

A health tech company may obtain internal-use software as part of a cloud-based (or hosting)
arrangement with a vendor. ASC 350-40-15-4A states that, in such circumstances, the software costs are
subject to ASC 350-40 if both of the following criteria are met:
a. The customer has the contractual right to take possession of the software at any time during the
hosting period without significant penalty.
b. It is feasible for the customer to either run the software on its own hardware or contract with another
party unrelated to the vendor to host the software.

The entity has entered into a service contract if (1) the health tech company does not have “the
contractual right to take possession of the software at any time during the hosting period without
significant penalty” or (2) it is not “feasible for the [entity] to either run the software on its own hardware
or contract with another party unrelated to the vendor to host the software.” 1 In this circumstance, only
implementation costs incurred would be subject to ASC 350-40. A health tech company may need to use
judgment in determining which costs are related to implementation — “implementation cost” is not a
defined term because, as paragraph BC14 of ASU 2018-15 states, “[ASC] 350-40 already has appropriate
guidance that entities currently apply in practice.”

3.3.6 Multiple-Element Arrangements
Health tech companies that purchase internal-use software or cloud-based services often purchase
multiple elements in the same arrangement (e.g., on-premise software licenses, postcontract customer
support [PCS], cloud-based services, and professional services). ASC 350-40-30-4 requires health tech
companies to allocate the cost to all individual elements on the basis of their stand-alone prices.

3.4 Agile Software Development

Many health tech companies use an agile software development approach in developing their
proprietary software modules. Agile software development is an adaptive approach that emphasizes
flexibility, integrated customer involvement, and speed. Agile software development methods are
both iterative and incremental; they also feature requirements and solutions that evolve through
collaboration between self-organizing, cross-functional teams. For many health tech companies, these
cross-functional teams consist of the same team members.

Historically, traditional software development (the “waterfall” method or model) involves planning out
an entire project in advance. Before commencing work, the project team understands how all parts
of the solution are meant to fit together. Work is then completed over a period of months to years
in accordance with an established project plan, and the entire solution is tested and implemented
simultaneously.

1
See ASC 350-40-15-4A through 15-4C.

18
 Chapter 3 — Capitalized Software

By contrast, agile software development uses time-bound increments (“sprints”) for planning and
execution. Although there is typically a goal in mind, there is usually no large-scale, established project
plan as there is in a waterfall model. Rather, teams plan smaller-scale development goals, work for two
to three weeks, evaluate progress, recalibrate, and repeat. Typically, a product is delivered at the end
of each sprint, but the goal or destination may change many times over the course of the project as
a result of lessons learned. By placing time constraints on each sprint, teams are able to identify and
address issues in a timelier manner and continually adapt plans to better meet the overall goal.

Using an agile development approach may have an impact on the finance and accounting functions
for health tech companies. In many organizations’ finance funding models, annual budgeting is used
as a key planning mechanism. Software development costs might be estimated for the following fiscal
year on the basis of the large projects to be completed. As health tech companies move into agile
development processes, these budgeting techniques may no longer be applicable given the iterative and
incremental methods employed.

Agile development approaches can also affect how organizations determine which costs related to the
development of internal-use software should be capitalized or deferred. In applying the accounting
guidance on identifying and classifying the capitalizable costs incurred in agile software development,
an entity may need to use significant judgment and keep diligent records of the nature of the costs
incurred. As mentioned above, this is because internal-use software costs incurred by a health tech
company should be capitalized only during the application development phase of an implementation
project. However, agile development activities tend to move through the preliminary-project,
application development, and postimplementation-operation stages of development so quickly or even
simultaneously that the identification of costs specific to application development may be difficult.
Inappropriate application of accounting guidance or insufficient records regarding the timing and nature
of development activities can lead to incorrect accounting for these costs (e.g., failure to capitalize all
appropriate costs).

As mentioned above, when developing internal-use software and implementing cloud computing
arrangements, health tech companies have to establish processes to distinguish implementation costs
incurred during the preliminary-project and postimplementation-operation stages from those incurred
during the application development stage. This is because costs incurred during the preliminary-project
and postimplementation-operation stages must be expensed as incurred while certain costs incurred
during the application development stage must be capitalized or deferred.

Because most of the guidance relevant to the accounting for technology development, implementation,
and acquisition was issued more than 20 years ago, it is likely that many health tech companies
have accounting policies in place to address it. This guidance is easiest to apply when there are
detailed project plans and milestones that might have been common in traditional large-scale
software development projects in which the waterfall method was used. However, agile development
environments are established to eliminate these structural barriers and foster real-time development
and testing and therefore may present certain challenges for entities to overcome in complying with the
accounting requirements. A few such challenges are outlined below.

3.4.1 Cost Tracking in an Agile Software Development Environment

All costs incurred by a health tech company in agile software development will need to be carefully
tracked to ensure accurate accounting records. These costs include, but are not limited to, payroll and
payroll-related costs, fees paid to third-party service providers, costs incurred to obtain inputs from
third parties (e.g., the purchase of on-premise term-based or perpetual software licenses), and travel
expenses incurred by employees that are directly related to their work in software development.

19
Deloitte | Health Tech Industry Accounting Guide (2023)

Entities will need not only to appropriately track costs incurred but also to categorize these costs
into the specific development phase in accordance with the accounting guidance. Because stages of
development are typically not clearly defined in agile development environments, users will need to
determine the appropriate unit of account so that they can assess the achievement of accounting and
reporting milestones. Is the completion of a sprint an indication of a key milestone? A group of sprints?
An overarching program goal? This is an important area of judgment given that each unit of account will
independently move through the phases of development.

Example 3-3

Entity A uses agile software development throughout its software development department to quickly meet
the needs of its customers. Under the agile software development model, development of features is divided
into sprints in which new features and functions are individually developed, tested, and deployed. Once the
features are deemed ready for use, they are incorporated into the overall solution. On the basis of this model,
A has determined that, for the development of simple features, each individual sprint is a unit of account to be
evaluated against the relevant accounting standards for capitalization given that each sprint moves through
the key milestones laid out by U.S. GAAP. Within each sprint, management has determined, on the basis of
detailed time and cost tracking, that 20 percent of time and expense is related to planning, 60 percent is related
to true application development on upgrades and enhancements, and the remaining 20 percent is related to
maintenance within the overall sprint. Therefore, management capitalizes 60 percent of the costs incurred and
expenses 40 percent.

Entity A has determined that for the development of more complex features, multiple sprints will be used.
Each sprint will develop and test a specific element of a given feature. Once all elements are tested and
ready for use, they will be deployed simultaneously into the overall solution. In this case, A has determined
that the group of interconnected sprints is the unit of account for accounting purposes. This is because the
functionality created by each sprint is interdependent, and the intended functionality would not be available
until all of the interconnected sprints were complete. Management must therefore perform an analysis for the
interconnected group of sprints to determine the costs associated with each stage of development and thus
the appropriate accounting for these costs. This may prove challenging because each of the sprints may be at a
different stage of development.

Health tech companies adopting agile development methods should consider which unit of account is
appropriate for their development process. Because each agile development milestone may be different
(e.g., composed of different sprints with different complexities), entities will need to have policies in
place to evaluate each effort to determine the appropriate unit of account and to identify the stages of
development for each unit.

3.4.2 Amortization in an Agile Software Development Environment

In accordance with U.S. GAAP, the assets established upon capitalization of technology development
costs must be amortized. Entities should begin amortization of the capitalized or deferred costs
once the developed technology is ready for its intended use, which occurs after substantial testing
is complete. If the functionality of one module (or sprint) depends on the functionality of another,
amortization will begin when both are ready for their intended use. Agile development adds complexities
given its iterative nature. There may be multiple units of account used in the determination of which
costs to capitalize, and interdependencies among sprints must be considered. Further, there could be
different amortization periods for the same technology development project given that the project may
be divided into multiple sprints, each of which has been determined to be a separate unit of account.
This could result in additional complexities in tracking the various amortization schedules specific to
each unit of account within the same technology development project.

20
 Chapter 3 — Capitalized Software

3.4.3 Impairment and Abandonment in an Agile Software Development

Environment
Identification of the appropriate unit of account is also particularly important to the application of the
accounting guidance on the impairment or abandonment of capitalized or deferred costs. Specifically,
ASC 350-40-35-1 requires that “assets” be assessed for impairment when “events or changes in
circumstances [occur] related to computer software being developed or currently in use [that indicate]
that the carrying amount may not be recoverable.” Regarding abandonment, ASC 350-40-35-3 requires
that “[w]hen it is no longer probable that computer software being developed will be completed and
placed in service, the asset shall be reported at the lower of the carrying amount or fair value, if any,
less costs to sell.” Impairment and abandonment events may be more common in agile development
methods given that each sprint is used as an opportunity to evaluate progress and potentially recalibrate
or pivot. Therefore, the identification of the unit of account related to capitalizing or deferring costs is
a critical judgment that could affect whether and to what extent an entity recognizes impairment or
abandonment charges (e.g., at the end of a sprint determined to be its own unit of account that was
unsuccessful). In addition, impairment or abandonment charges could exist if a sprint replaces existing
technology and causes previously capitalized software to become obsolete because it is no longer in use.

3.5 Software to Be Sold or Marketed

Instead of developing a solution that will provide a service to its customers, a health tech company
may wish to market or sell its software solution, depending on what its go-to-market strategy is. Such
software solutions are commonly referred to as external-use software and could be in the form of an
on-premise perpetual license; a term (or subscription) license; or a SaaS solution that meets the criteria
in ASC 350-40-15-4A, as discussed in Section 3.3.

Rather than prescribing distinct phases like the guidance on internal-use software, ASC 985-20 identifies
technological feasibility as the moment in which costs incurred by a health tech company can be
capitalized.

ASC 985-20

25-1 All costs incurred to establish the technological feasibility of a computer software product to be sold,
leased, or otherwise marketed are research and development costs. Those costs shall be charged to expense
when incurred as required by Subtopic 730-10.

21
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 985-20 (continued)

25-2 For purposes of this Subtopic, the technological feasibility of a computer software product is established
when the entity has completed all planning, designing, coding, and testing activities that are necessary to
establish that the product can be produced to meet its design specifications including functions, features, and
technical performance requirements. At a minimum, the entity shall have performed the activities in either
(a) or (b) as evidence that technological feasibility has been established:
a. If the process of creating the computer software product includes a detail program design, all of the
following:
1. The product design and the detail program design have been completed, and the entity has
established that the necessary skills, hardware, and software technology are available to the entity to
produce the product.
2. The completeness of the detail program design and its consistency with the product design have
been confirmed by documenting and tracing the detail program design to product specifications.
3. The detail program design has been reviewed for high-risk development issues (for example, novel,
unique, unproven functions and features or technological innovations), and any uncertainties related
to identified high-risk development issues have been resolved through coding and testing.
b. If the process of creating the computer software product does not include a detail program design with
the features identified in (a), both of the following:
1. A product design and a working model of the software product have been completed.
2. The completeness of the working model and its consistency with the product design have been
confirmed by testing.

In accordance with ASC 985-20-25-2, a health tech company must meet specific documentation
requirements to establish technological feasibility, which is a strict point in time. Specifically, the
company must complete the (1) product design and (2) detail program design. Upon meeting these
requirements, the health tech company would establish technological feasibility, which generally
occurs much later in the development life cycle of the external-use software product than it does for
internal-use software, resulting in a smaller amount of costs incurred that are eligible for capitalization
under the guidance on external-use software guidance than under the guidance on internal-use
software.

Technological feasibility can be known before the point required in ASC 985-20-25-2 — for example,
when the software product being developed uses only technology that has previously been used
successfully or is not significantly different from existing products. However, before technological
feasibility can be established, a health tech company must complete a detail program design (see
ASC 985-20-25-2(a)) or, in its absence, a working model (see ASC 985-20-25-2(b)). This requirement
is analogous to the requirement under ASC 730-10 to have a prototype before R&D activities can be
considered complete.

While technological feasibility can be known before the requirements of ASC 985-20-25-2 are met,
establishing technological feasibility can be difficult for many health tech companies, including start-ups
that are developing their own software solution platforms, because of the specific documentation
requirements for product design and detail program design.

22
 Chapter 3 — Capitalized Software

The ASC master glossary defines a product design as a “logical representation of all product functions
in sufficient detail to serve as product specifications.” Normally, the product design will be prepared in
writing before programming and will contain a description of the product specifications, including the
following:

• Type of product.
• Objectives of the product.
• General inputs.
• General outputs.
• Major processes or data transformation definitions.
• Data storage and data structure requirements.
• General data flow and interaction with transforming processes.
• General definitions of software control facilities such as processing activity journals, approval
checkpoints, and audit trails.

A detail program design is defined as the “detail design of a computer software product that takes
product function, feature, and technical requirements to their most detailed, logical form and is ready
for coding.” Generally, the detail program design will include narratives and flowcharts addressing the
following:

• Description of logic.
• File layout.
• Report definitions.
• Field definitions.
• Algorithms.
• Special routines.
• Specific arrays of data.
The detail program design is often developed and prepared by a systems analyst and reviewed by a
senior analyst before coding. In these instances, it should be relatively straightforward to determine
whether a detail program design exists. However, in practice, many software development projects are
carried out in relatively unstructured environments in which documentation of a product design and a
detail program design may not be sufficiently detailed or may not exist at all.

ASC 985-20 requires that the detail program design be consistent with the product design and that
it be confirmed by documenting and tracing the detail program design to the product specifications.
Accordingly, before capitalization of software costs is permitted, a certain level of documentation is
necessary. The actual level of documentation may depend on the software product being developed.
Extensive documentation may not be required for minor product enhancements, which will most likely
not include all the elements listed above. On the other hand, a more detailed formal program design
may be required for new products. The detail program design may be prepared separately or as part of
the product design.

In view of the guidance in ASC 985-20, health tech company management is encouraged to create
common documentation requirements for the company’s software engineers. Doing so could make it
easier to identify when the health tech company has a product design and detail program design.

23
Deloitte | Health Tech Industry Accounting Guide (2023)

Once a health tech company establishes technological feasibility for its software to be sold, leased, or
marketed, it can begin capitalizing costs incurred specifically for those costs incurred associated with
coding and testing that are performed after that point. In addition, the health tech company should
capitalize costs incurred that are associated with producing product masters. If the software being
developed is an integral part of a product package or process, costs associated with the software cannot
be capitalized until (1) technological feasibility is established for all portions of the product package or
process and (2) all R&D activities for the other portions of the product package or process have been
completed (see ASC 350-20-25-4).

Upon completion of the software development process, the health tech company’s software product or
process will be available for general release. At this point in the development process, capitalization of
any additional software-related costs must cease.

The example below describes a situation in which a group of products is not considered to be available
for general release even though the group of products has been sold to a few customers for their basic
research and study.

Example 3-4

Company D has developed software that monitors analytical data related to practitioner billings to patients. The
software helps lower outstanding patient billings and increase collections. Company D has sold two licenses of
the software. The customers purchased the software to determine whether there are alternative uses for the
technology. After the sale of the two licenses, D incurred certain costs to modify the device for sales to other
customers.

ASC 985-20-25-6 precludes cost deferral on a product after it is available for general release to customers.
In this scenario, the sale of licenses to the original two customers would not preclude capitalization of the
modification costs incurred after that sale.

The license product would not be considered to be available for general release to the other customers
because (1) the original two customers will be using the licenses for research and study and this use differs
from the design goals for the license and (2) D is still preparing the license for sales to other customers.
Therefore, in this example, capitalization would not be precluded under ASC 985-20-25-6. Company D should
determine whether the modification costs represent production costs, product enhancements, or maintenance
and should account for them accordingly.

The example below illustrates a situation in which capitalization would be precluded because the group
of products would be considered available for general release.

Example 3-5

Assume the same facts as in the example above except that, immediately after the sale of the two licenses,
D also sells a unit to a large health care provider that uses the software to monitor its patient billings and
collections. After the sale of the unit to the health care provider, D continues to incur certain costs to modify
the license.

Under these circumstances, if the modification costs are production costs rather than either product
enhancements or maintenance, ASC 985-20-25-6 will preclude capitalization of the costs because the product
should be considered available for general release to customers. Company D has sold the product in its current
state to a customer and that customer is using the license in accordance with its design goals. Therefore, the
license is available for general release to D’s customers.

However, if the modification costs represent product enhancements, D may capitalize these costs once its
technological feasibility has been established. On the other hand, costs representing maintenance should be
expensed when the related revenue is recognized or as incurred, whichever occurs first.

24
 Chapter 3 — Capitalized Software

As indicated by these different situations, the determination of when certain costs are modification
or production costs rather than enhancements or maintenance-related costs (such as bug fixes that
do not constitute significant alterations to the operations of the software) depends on the facts and
circumstances. Health tech companies will need to use judgment in determining the nature of costs
being incurred and whether such costs should be expensed as incurred or capitalized.

3.5.1 External-Use Software — Subsequent Measurement

Unlike ASC 360-20, which contains considerations related to internal-use software, ASC 985-20-35
includes specific guidance on the appropriate amortization of software-related costs that have been
capitalized.

ASC 985-20-35-1 notes that software costs should be amortized on a product-by-product basis. Multiple
products for which technological feasibility may have been established at the same time should still be
amortized separately. ASC 985-20-35-1 indicates that this is because the amortization costs incurred in
connection with the health tech company’s different software costs should be the greater of:
a. The ratio that current gross revenues for a product bear to the total of current and anticipated future
gross revenues for that product
b. The straight-line method over the remaining estimated economic life of the product including the
period being reported on.

Health tech companies should ensure that they have the forecasting abilities to appropriately calculate
the amount of amortization that should be recognized for a reporting period.

3.6 Other Guidance to Consider

Software-related costs may be subject to U.S. GAAP other than ASC 985-20 or ASC 350-40. The
discussion below describes other guidance that may apply to such costs.

3.6.1 Web Site Development Costs

Health tech companies may incur Web site development costs, which are subject to ASC 350-50. The
guidance is similar to that in ASC 350-40. For example, under ASC 350-50-25-6, if software for a Web
site is purchased or developed for an entity’s internal needs, costs incurred for (1) purchased software
tools or (2) internally developed software tools during the application development stage are generally
capitalized. In addition, certain software acquired or developed for internal use related to Web site
operation or graphics is directly within the scope of ASC 350-40.

While ASC 350-50 refers to Web site content, it does not address the accounting for such content.
Therefore, Web site content is accounted for under other U.S. GAAP. For example, if an entity is a
licensee in the record and music industry and relicenses music content, it would apply the guidance in
ASC 928-340.

25
Deloitte | Health Tech Industry Accounting Guide (2023)

3.6.2 Software Used for R&D Activities

If the software a health tech company uses in R&D activities does not have alternative future uses, it is
subject to ASC 730-10. In addition, the following software costs are accounted for as R&D costs:

• For software subject to ASC 985-20, all costs incurred before the establishment of technological
feasibility.

• For software subject to ASC 350-40, all costs for pilot projects (i.e., “[d]esign, construction,
and operation of a pilot [project] that is not of a scale economically feasible to the entity for
commercial production”).

• For software subject to ASC 350-40, all costs associated with a particular R&D project,
“regardless of whether the software has alternative future uses.”

Software associated with R&D assets may be acquired in a business combination. If the software will be
used for R&D activities, it is subject to the guidance in ASC 805-20 and ASC 350-30. In accordance with
ASC 805-20, such software is recognized as an asset and measured at fair value.

3.6.3 Significant Production, Modification, or Customization of Software

Software sold to customers in arrangements that require significant production, modification, or
customization is accounted for under ASC 606. If the software is being produced, modified, or
customized for a specific customer contract, the costs for such software represent fulfillment costs that
are subject to ASC 340-40.

3.6.4 Business Process Reengineering Activities

A health tech company may incur costs associated with business process reengineering activities as part
of developing software or implementing cloud-based solutions. Those costs are subject to ASC 720-45
and are expensed as incurred.

3.7 Importance of Ongoing Reassessment of Software Costs

As described above, there are various ways in which a health tech company’s evolving business models
may affect which guidance applies to the accounting for costs to develop or acquire software. These
include changes in how health tech companies are (1) developing or acquiring software solutions from
their vendors for internal use and (2) marketing and delivering software solutions to their customers. In
the rapidly evolving technology ecosystem, it is important for a health tech company to have sufficient
internal controls in place to periodically reassess and document how these changes in facts and
circumstances may affect the guidance the entity should apply and the related accounting.

26
 Chapter 3 — Capitalized Software

The flowchart below illustrates how an entity determines the appropriate guidance to apply to software
and software-related costs.
Apply ASC 340-40.

Yes

Are the costs

associated with Is the
Is the software software that (1) will be
Are software being
the costs
acquired in a used in R&D activities and
No No No produced, modified,
associated business combination, does not have alternative future
or customized for a specific
with Web site and will the software uses or (2) will be solely for internal
development? use and associated with a customer contract that
be used for R&D
particular R&D project, is subject to ASC
activities?
including pilot 606?
projects?

Yes Yes
Yes

No
Apply ASC 350-50. Apply ASC 805-20 and Apply ASC 730-10.
ASC 350-30.

Hosting arrangement
Acquisition

Are both of
the criteria in Is
ASC 350-40-15-4A met the
A service (i.e., (1) the entity “has software Are the
the contractual right to take
arrangement possession of the software at any being purchased costs related
No
exists. Apply ASC time during the hosting period without (1) as part of a to (1) software
350-40 only to significant penalty” and (2) it “is feasible hosting arrangement or acquisition or
for the [entity] to either run the
implementation (2) exclusively on (2) software
software on its own hardware
costs. or contract with another an on-premise development?
party unrelated to the basis?
vendor to host the
software”)?

Exclusively on-premise Development

Yes

Are both of
the criteria in (1) Is the
ASC 985-20-15-5 met
(i.e., (1) the “customer has Will the Substantive software being
the contractual right to take Hosting entity’s plan to market acquired, developed, or
possession of the software at any arrangement customers acquire externally modified solely to meet the
time during the hosting period without
the software (1) on an entity’s internal needs, or (2) does
significant penalty” and (2) it “is feasible
for the customer to either run the on-premise basis or (2) as a substantive plan exist (or is
software on its own hardware part of a hosting one being developed) to
or contract with another arrangement? market the software
party unrelated to the
vendor to host the externally?
software”)?

No On-premise basis

Yes
Apply ASC 985-20.
Solely for
internal needs

Apply ASC 350-40.

27
Deloitte | Health Tech Industry Accounting Guide (2023)

3.8 Income Tax Considerations

3.8.1 U.S. Federal Income Tax Considerations
A taxpayer can claim a research credit (which directly offsets a U.S. federal income tax liability) for
performing qualified research activities in the United States. Software development activities may
be considered qualified research activities to the extent that they are intended to resolve technological
uncertainty. However, development activities to create software to be used primarily for internal use
are not considered qualified research activities unless they meet a high threshold of innovation. The
determination of whether software development activities are considered primarily for internal use
depends on the facts and circumstances but takes into account factors such as whether the software
(1) is intended to be used to perform “back office” functionality (e.g., accounting, finance, human
resources); (2) is separately sold, leased, licensed, or otherwise marketed to third parties; and (3) enables
third parties to interact with the taxpayer.

Costs of performing software development activities may be deducted as incurred or capitalized and
amortized over a period of either 36 months or five years at the taxpayer’s discretion. However, for tax
years beginning after December 31, 2021, taxpayers will be required to capitalize all costs of research
and experimentation activities (including software development activity) and amortize them over a
period of either five years for research performed domestically or 15 years for research performed
outside the United States. Recent legislative proposals would delay the effective date on which entities
will be required to capitalize research and experimentation costs to tax years beginning after December
31, 2025. As of the drafting of this publication, it is not clear whether such legislation (or similar
legislation) will ultimately be enacted.

3.8.2 U.S. International Tax Considerations

Health technology companies invest heavily in developing proprietary software accessible by their
customers as well as in creating proprietary data sets, which involve significant activities related to the
collection, cleaning, and storage of data. The proprietary data sets themselves can be used for decision-
making purposes and may generate valuable insights for these companies and their customers. The
aforementioned investments by health tech companies can generate intangible property (IP) that
often accounts for a considerable portion of these companies’ overall market value. The expansion by
companies into international markets either through sales to customers or by employing personnel
may create a potential opportunity for identifying international tax and transfer pricing planning
considerations, especially with respect to the development and funding of IP.

One consideration for many health tech companies is to set up an efficient tax structure that is aligned
with the company’s overall footprint (including IP) and business objectives and that complies with local
tax regulatory regimes across the globe. This process will often depend on a company’s specific facts
and circumstances. Potential options for IP management and funding may include intercompany sales of
IP, intercompany licensing, cost-sharing arrangements, or incubator structures. It is critical for a health
tech company to work with tax advisers to enhance its international tax and transfer pricing structure
and align this structure with business realities.

28
 Chapter 3 — Capitalized Software

3.8.2.1 Foreign-Derived Intangible Income — Section 250 Deduction

Health tech companies that provide sales or services to foreign customers may have the opportunity
to claim a federal income tax deduction on income that is eligible as foreign-derived intangible income
(FDII), resulting in permanent cash tax savings and having an impact on the effective tax rate. The
Section 250 FDII regulations are very complex, and it can be challenging for companies not only to
perform the necessary calculations but also to substantiate them, especially for companies that provide
electronically supplied services to customers.

An electronically provided service to a customer or business recipient may be FDII-eligible to the

extent that it was provided to a person located outside the United States. To determine whether an
electronically supplied service is provided to a person located outside the United States, a company is
generally required to look to the location of the device that the customer or business recipient uses
to access the service. This requirement may pose significant challenges for a company, including data
constraints and restraints associated with privacy laws. For example, if a $75,000 service is provided to
a business recipient throughout a given year and a company is unable to determine the location of the
device used to access this service, the service is not treated as provided to a person located outside
of the United States and is therefore ineligible for this tax deduction. Given the complexity with this
calculation and the substantiation requirements associated with it, a company should consider working
with a tax adviser to evaluate its specific facts and circumstances.

3.9 Considerations Related to Accounting for Income Taxes

One of the overall objectives of ASC 740 is to recognize deferred tax assets and liabilities for the future
tax consequences of events that have been recognized in an entity’s financial statements or tax returns.
A temporary difference is a difference between the financial reporting basis and the income tax basis,
determined in accordance with the recognition and measurement criteria of ASC 740. Therefore, if there
is a difference between the U.S. GAAP and tax treatment related to software costs, a deferred tax asset
or liability may need to be established.

To the extent that a company is eligible for a Section 250 deduction related to FDII, the benefit
associated with that deduction is akin to a special deduction and is treated as a permanent item. For
more information, see Section 3.2.1.5 of Deloitte’s Roadmap Income Taxes.

When determining the amount of tax benefit to recognize in the financial statements for research
credits, software costs, and FDII deductions, it is important for an entity to consider whether the
amounts taken in the tax return meet the more-likely-than-not recognition and measurement
thresholds in ASC 740-10. For more information, see Chapter 4 of Deloitte’s Roadmap Income Taxes.

3.10 FASB Project on the Accounting for and Disclosure of Software Costs

In June 2022, the FASB added to its technical agenda a project to (1) modernize the accounting for
software costs and (2) enhance the transparency regarding an entity’s software costs. Specifically, the
project’s objective is to address the recognition, measurement, presentation, and disclosure of software
costs currently within the scope of ASC 350-40 and ASC 985-20.

29
Deloitte | Health Tech Industry Accounting Guide (2023)

At its January 18, 2023, meeting, the FASB discussed stakeholder feedback and directed its staff to
conduct research on the following two models:

• Initial development cost model — All direct software development costs and software
enhancement costs would be capitalized when it is probable that (1) the software project will
be completed and (2) the software will be used to function as intended. Software development
costs incurred after the software is substantially complete and ready for its intended use, as well
as ongoing maintenance costs, would be expensed as incurred. The Board staff was instructed
to devote some of its research to exploring how to make application of this model more
operable and consistent.

• Dual model — Certain software costs would be expensed as incurred, while other software costs
would be subject to the initial development cost model. The Board staff was instructed to devote
some of its research to exploring alternatives for determining which software costs should be
expensed and which software costs should be capitalized.

At its April 5, 2023, meeting, the FASB instructed its staff to continue performing research on the initial
development cost model but decided that research on the dual model should no longer be pursued.

The FASB will continue its deliberations at future Board meetings. Health tech entities should monitor
the project to stay abreast of the latest developments.

30
Chapter 4 — Revenue Recognition for
Health Tech Companies

4.1 Health Tech Customer Solutions — What Do They Look Like?

The variety of solutions offered by health tech companies is staggering and can include the processing of
billing and medical claims, benefits management services, analytics, automated research, customization
of drugs on the basis of individual patient genetics, automated diagnostics based on implantable
technology, patient scheduling platforms, cancer detection, and online prescription management, to
name a few. Health tech companies provide these technology products or services by using two primary
service offerings:

• SaaS — In this arrangement, which is typically referred to as a CCA, the customer does not
take ownership of the product and the SaaS solution is considered a service provided by the
company.

• On-premise perpetual or subscription licenses — The software sold by the health tech company to
its end customer at a point in time; this software is commonly sold along with PCS services or
other products and services, such as professional services, other SaaS, or hardware.

Many health tech companies are applying SaaS delivery models as they digitize current service
offerings and update current software offerings. Health tech companies often develop a SaaS platform
in which they provide their services to customers via access to a digital platform rather than giving
their customers the software code. In contrast, the software delivery model, often referred to as an
“on-premise” model, involves a software license transfer in which the customer determines where the
software is hosted.

In many software arrangements, however, the customer does not download the software onto servers
or computers that it owns or leases; rather, in such arrangements, the software is hosted on the SaaS
provider’s or third party’s servers and is controlled by the SaaS provider. The SaaS provider will typically
make the functionalities of the software available to the customer through an Internet “portal” hosted on
the seller’s hardware. Questions have arisen about whether such an arrangement is (1) an on-premise
perpetual license or (2) a SaaS arrangement. This determination is important because it can affect the
pattern of revenue recognition. A key consideration in this determination is whether the customer has
the option of taking possession of the software without penalty or diminution of value. SaaS contracts
include various arrangements involving Web-based delivery of applications or solutions managed by
a third-party vendor, typically in the form of a multiple-month subscription to a company’s proprietary
software portal. Customers in these arrangements can access the software remotely from their own
computer systems; however, they do not take ownership of the software.

The sections below outline the revenue recognition model that applies to common arrangements in the
health tech industry.

31
Deloitte | Health Tech Industry Accounting Guide (2023)

4.1.1 Step 1: Identify the Contract With the Customer

For contracts within the scope of ASC 606, the first step in recognizing revenue is to determine whether
a valid and genuine contract exists, for accounting purposes, between an entity and its customer. ASC
606-10-25-2 states that a contract is a legally binding “agreement between two or more parties that
creates enforceable rights and obligations” and further indicates that contracts “can be written, oral, or
implied by an entity’s customary business practices.” In accordance with ASC 606-10-25-1(a) through (e),
a contract exists if the contract has commercial substance, collectibility is probable, each party has
approved the contract and is committed to perform its obligations under the contract, the entity can
identify each party’s rights, and the entity can identify payment terms. As discussed further below, a
few considerations related to performing step 1 of revenue recognition may be unique to health tech
companies.

As part of evaluating whether each party has approved the contract and is committed to perform its
obligations under the contract and, in turn, whether each party’s rights are identifiable and enforceable,
companies must consider the existence of any termination clauses or provisions within the contract.
As noted in ASC 606-10-25-2, “[a] contract is an agreement between two or more parties that creates
enforceable rights and obligations.” Termination provisions may affect the length of time over which
the identifiable rights and obligations are enforceable and therefore may also have an impact on the
determination of several factors (to be discussed in further detail below), such as the promises under
the contract (“performance obligations”), the transaction price, and similarly the contract duration over
which revenue may be recognized.

ASC 606-10

25-3 Some contracts with customers may have no fixed duration and can be terminated or modified by either
party at any time. Other contracts may automatically renew on a periodic basis that is specified in the contract.
An entity shall apply the guidance in this Topic to the duration of the contract (that is, the contractual period)
in which the parties to the contract have present enforceable rights and obligations. In evaluating the criterion
in paragraph 606-10-25-1(e), an entity shall assess the collectibility of the consideration promised in a contract
for the goods or services that will be transferred to the customer rather than assessing the collectibility of the
consideration promised in the contract for all of the promised goods or services (see paragraphs 606-10-55-3A
through 55-3C). However, if an entity determines that all of the criteria in paragraph 606-10-25-1 are met, the
remainder of the guidance in this Topic shall be applied to all of the promised goods or services in the contract.

Contracts may contain various termination provisions that are intended to protect one party or multiple
parties to the contract. These terms may vary widely (e.g., whether they include a penalty for termination
and, if so, the amount of and reason for this penalty). For example, consider a couple of potential
scenarios for a telehealth company that contracts with its customers to provide real-time, remote access
between patients and their health care providers via its proprietary SaaS platform. The contract contains
a one-year stated term and the customer is billed in ratable increments on a monthly subscription basis.

In one potential scenario, the contract states that the customer may exit the arrangement at any time
with one month’s notice and for no additional fee. Because there is no additional fee for leaving the
contract, the telehealth company’s enforceable rights (to bill the customer for remote access to health
care) actually extend for just one month since the customer is only required to provide a month’s worth
of notice before any cancellation takes effect. In this case, despite the stated contract term of one year,
the contract term would actually be seen as month to month in the evaluation of the contract under
step 1 of ASC 606.

32
 Chapter 4 — Revenue Recognition for Health Tech Companies

Consider another potential scenario involving the same contract whose termination provision states
that the customer may still cancel the contract at any time with one month’s notice but would then
be required to pay the telehealth company a penalty. In this instance, since the customer must pay a
penalty for canceling the contract early, the termination provision would need to be evaluated further
to determine whether it is substantive. To be considered substantive, the provision would be weighed
against factors such as (1) whether the terminating party is required to pay compensation, (2) the
amount of such compensation, and (3) the reason for the compensation (i.e., whether the compensation
is in addition to amounts due for goods and services already delivered). Substantive termination
penalties suggest that the parties’ rights and obligations extend for the duration of the contract term,
because the counterparty would not be expected to terminate early. An entity must use judgment in
making this determination, since the guidance does not specify what differentiates a substantive penalty
from a nonsubstantive penalty. However, an incremental penalty of 10 percent or more of the total
transaction price for early termination of a contract may be one factor indicating that the termination
provision is substantive. Nevertheless, in evaluating such provisions, companies should consider any
such provision in the context of the contract as a whole as well as their customary business practices.

Contracts may also include termination provisions intended to protect against a material breach
of contractual obligations from either party. These types of provisions, which may also be known
as “termination for cause” provisions, generally do not allow for a penalty-free or nonsubstantive
termination because they are intended to address a breach of one’s contractual rights rather than to
limit such rights; therefore, such provisions typically would not affect the determination of the contract
length. If the contract is determined to have commercial substance in step 1 (i.e., the risk, timing, or
amount of an entity’s future cash flows are expected to change as a result of the contract), the parties
to the contract most likely intend to satisfy their obligations. In such cases, the termination provisions
for material nonperformance generally do not indicate that any parties’ rights or obligations are limited
to any period less than the full contract term; rather, such provisions generally would stipulate that all
parties expect their rights and obligations to extend throughout the entire duration of the contract.

In further determining whether a valid and genuine contract exists, an entity must evaluate whether
it is probable that it will collect substantially all of the consideration to which it expects to be entitled
under the contract. However, the consideration to which an entity is ultimately entitled may be less than
the price stated in the contract if the customer is offered a price concession. Price concessions are a
form of variable consideration and need to be analyzed when the transaction price is being determined
(as part of step 3 of revenue recognition). However, in step 1, an entity would evaluate whether it is
probable that it will collect the consideration to which it will be entitled for providing goods or services to
a customer after considering any price concessions. As part of this evaluation, the entity must perform
certain aspects of step 3 in conjunction with step 1. It may be difficult to differentiate between credit
risk (i.e., the risk of collecting less consideration than the amount the entity legitimately expected to
collect from the customer) and price concessions (i.e., entering into a contract with a customer with the
expectation of accepting less than the contractual amount of consideration in exchange for goods or
services). Entities will need to use significant judgment and consider all relevant facts and circumstances
in determining whether they have provided an implicit price concession (variable consideration to be
estimated in step 3, as discussed below) or have accepted a customer’s credit risk (to be evaluated
in step 1). This is particularly true of entities in highly regulated industries, such as health care, which
may be required by law to provide certain goods and services to their customers regardless of the
customers’ ability to pay.

33
Deloitte | Health Tech Industry Accounting Guide (2023)

The following indicators may suggest that a health tech company has offered a price concession:

• The health tech company has a customary business practice of providing discounts or accepting
as payment less than the contractually stated price, regardless of whether such a practice is
explicitly stated at contract inception or specifically communicated or offered to the customer.
This indicator may specifically apply to health tech companies that are in their start-up phase
and want to incentivize potential customers to enter into an arrangement.

• The customer has a valid expectation that the health tech company will accept less than that
contractually stated price. This could be due to customary business practices, published policies,
or specific statements made by the company.

• The health tech company transfers the goods or services to the customer and continues to do
so, even when historical experience indicates that it is not probable that the entity will collect the
billed amount.

• Other facts and circumstances indicate that the customer intends to pay an amount that is less
than the contractually stated price, and the entity nonetheless enters into a contract with the
customer.

• The health tech company has a customary business practice of not performing a credit
assessment before transferring goods or services to the customer (e.g., the entity is required by
law or regulation to provide emergency medical services before assessing the customer’s ability
or intention to pay).

ASC 606 includes an example (reproduced below) illustrating an implicit price concession that could
apply to health tech companies. Note that while health tech companies may not sell prescription
drugs, the scenario in the below example may be relevant to health tech companies that sell, for
example, software licenses or bundled hardware/software to clinics or physician groups that operate
in economically depressed regions. Because health tech is a convergence of health care, life sciences,
health plans, and technology, macroeconomic trends or legislative policy decisions can affect the health
tech industry far more broadly than they would affect the general technology space.

ASC 606-10

Example 2 — Consideration Is Not the Stated Price — Implicit Price Concession

55-99 An entity sells 1,000 units of a prescription drug to a customer for promised consideration of $1 million.
This is the entity’s first sale to a customer in a new region, which is experiencing significant economic difficulty.
Thus, the entity expects that it will not be able to collect from the customer the full amount of the promised
consideration. Despite the possibility of not collecting the full amount, the entity expects the region’s economy
to recover over the next two to three years and determines that a relationship with the customer could help it
to forge relationships with other potential customers in the region.

55-100 When assessing whether the criterion in paragraph 606-10-25-1(e) is met, the entity also considers
paragraphs 606-10-32-2 and 606-10-32-7(b). Based on the assessment of the facts and circumstances, the
entity determines that it expects to provide a price concession and accept a lower amount of consideration
from the customer. Accordingly, the entity concludes that the transaction price is not $1 million and, therefore,
the promised consideration is variable. The entity estimates the variable consideration and determines that it
expects to be entitled to $400,000.

34
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10 (continued)

55-101 The entity considers the customer’s ability and intention to pay the consideration and concludes that
even though the region is experiencing economic difficulty it is probable that it will collect $400,000 from the
customer. Consequently, the entity concludes that the criterion in paragraph 606-10-25-1(e) is met based on
an estimate of variable consideration of $400,000. In addition, based on an evaluation of the contract terms
and other facts and circumstances, the entity concludes that the other criteria in paragraph 606-10-25-1 are
also met. Consequently, the entity accounts for the contract with the customer in accordance with the guidance
in this Topic.

Note that in the above example, the entity concludes that the promised consideration is variable.
Therefore, the entity may need to determine the transaction price in step 3 of the model (see Section
4.1.3), including any price concessions, before concluding on collectibility.

4.1.2 Step 2: Identify the Performance Obligations in the Contract

Once a contract is deemed to exist, an entity must identify the goods or services outlined in the contract,
then determine which are separate performance obligations. Step 2 is one of the most critical steps
in the new revenue framework since it establishes the unit of account for revenue recognition. Many
health tech companies may bundle goods/services with the software solution, including PCS, training
for software users, hardware, and hosting services. Some or all of these may exist in a health tech
contract and may constitute separate performance obligations. These promises for goods or services
can be explicit in the contract or implied by the health tech company’s actions. Such actions may include
statements or communications that are available to the customer outside of the contract and that could
lead the customer to reasonably expect to receive goods or services upon entering into the contract.

To identify performance obligations, an entity needs to determine whether promised goods or services
are distinct. ASC 606-10-25-14 states:

At contract inception, an entity shall assess the goods or services promised in a contract with a customer and
shall identify as a performance obligation each promise to transfer to the customer either:
a. A good or service (or a bundle of goods or services) that is distinct
b. A series of distinct goods or services that are substantially the same and that have the same pattern of
transfer to the customer (see paragraph 606-10-25-15).

The section below addresses the evaluation of whether a good or service is distinct under the series
guidance in ASC 606-10-25-15.

4.1.2.1 Evaluating Whether a Good or Service Is Distinct

ASC 606-10-25-19 notes that the following criteria must be met before a promised good or service can
be considered distinct:
a. 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 (that is, the good or service is capable of being distinct).
b. The entity’s promise to transfer the good or service to the customer is separately identifiable from other
promises in the contract (that is, the promise to transfer the good or service is distinct within the context
of the contract). [Emphasis added]

35
Deloitte | Health Tech Industry Accounting Guide (2023)

In addition, ASC 606-10-25-20 addresses when a customer may benefit from a good or service and
states:

A customer can benefit from a good or service in accordance with paragraph 606-10-25-19(a) if the good or
service could be used, consumed, sold for an amount that is greater than scrap value, or otherwise held in a
way that generates economic benefits. For some goods or services, a customer may be able to benefit from
a good or service on its own. For other goods or services, a customer may be able to benefit from the good
or service only in conjunction with other readily available resources. A readily available resource is a good or
service that is sold separately (by the entity or another entity) or a resource that the customer has already
obtained from the entity (including goods or services that the entity will have already transferred to the
customer under the contract) or from other transactions or events. Various factors may provide evidence that
the customer can benefit from a good or service either on its own or in conjunction with other readily available
resources. For example, the fact that the entity regularly sells a good or service separately would indicate that a
customer can benefit from the good or service on its own or with other readily available resources.

ASC 606-10-25-21 further states that the following factors may indicate that two or more promises to
transfer goods or services to a customer are not separately identifiable:
a. The entity provides a significant service of integrating 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. In other words, the entity is using the goods or services
as inputs to produce or deliver the combined output or outputs specified by the customer. A combined
output or outputs might include more than one phase, element, or unit.
b. One or more of the goods or services significantly modifies or customizes, or are significantly modified
or customized by, one or more of the other goods or services promised in the contract.
c. 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.
For example, in some cases, two or more goods or services are significantly affected by each other
because the entity would not be able to fulfill its promise by transferring each of the goods or services
independently.

Moreover, ASC 606-10-25-22 indicates that “[i]f a promised good or service is not distinct, an entity shall
combine that good or service with other promised goods or services until it identifies a bundle of goods
or services that is distinct. In some cases, that would result in the entity accounting for all the goods or
services promised in a contract as a single performance obligation.”

The determination of whether a customer can benefit from the goods or services is based on the
characteristics of the goods or services themselves rather than the customer’s specific plan. The
following example from ASC 606-10 illustrates a scenario in which the goods are services are not
distinct:

ASC 606-10

Example 10 — Goods and Services Are Not Distinct

Case C — Combined Item
55-140D An entity grants a customer a three-year term license to anti-virus software and promises to provide
the customer with when-and-if available updates to that software during the license period. 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 arrangement.

55-140E The entity concludes that the software and the updates are each promised goods or services in the
contract and are each capable of being distinct in accordance with paragraph 606-10-25-19(a). The software
and the updates are capable of being distinct because the customer can derive economic benefit from the
software on its own throughout the license period (that is, without the updates the software would still provide
its original functionality to the customer), while the customer can benefit from the updates together with the
software license transferred at the outset of the contract.

36
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10 (continued)

55-140F The entity concludes that its promises to transfer the software license and to provide the updates,
when-and-if available, are not separately identifiable (in accordance with paragraph 606-10-25-19(b)) because
the license and the updates are, in effect, inputs to a combined item (anti-virus protection) in the contract. The
updates significantly modify the functionality of the software (that is, 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). Therefore, in this Example, the entity accounts for the software license and the when-
and-if available updates as a single performance obligation. In accordance with paragraph 606-10-25-33, the
entity concludes that the nature of the combined good or service it promised to transfer to the customer in this
Example is computer virus protection for three years. The entity considers the nature of the combined good
or service (that is, to provide anti-virus protection for three years) in determining whether the performance
obligation is satisfied over time or at a point in time in accordance with paragraphs 606-10-25-23 through
25-30 and in determining the appropriate method for measuring progress toward complete satisfaction of the
performance obligation in accordance with paragraphs 606-10-25-31 through 25-37.

Health tech companies should be aware of the situations addressed in this example, which notes that
ongoing updates to the customer-hosted software can be critical to its continued use. The nature of
the updates can have a significant impact on the health tech company’s determination of whether the
updates are distinct; management must use significant judgment in making this determination.

For example, an implantable device that uses associated software for diagnostic purposes might not be
useful if it is not paired with the software and thus might not be separately identifiable. On the other
hand, off-the-shelf hardware, such as a server, monitor, or computer terminal that is sold together with
on-premise software, could provide benefits to customers regardless of whether they intend to use
such hardware. A key question to ask is whether a good or service transforms another good or service
it is bundled with or whether it merely provides some incremental benefit. If the good or service is
considered transformative, it is most likely not separately identifiable and therefore not distinct.

Example 10 illustrates a software update that significantly modifies the functionality of the software in
such a way that the software and update are not distinct. Health tech companies often include multiple
services in the same contract, such as delivering the software, installing the software on the customer’s
servers, performing training or maintenance services, and providing hardware such as monitors or
diagnostic machines. A company must determine whether such goods or services are distinct. Example
11 below illustrates a scenario involving distinct goods or services.

ASC 606-10

Example 11 — Determining Whether Goods or Services Are Distinct

Case A — Distinct Goods or Services
55-141 An entity, a software developer, enters into a contract with a customer to transfer a software license,
perform an installation service, and provide unspecified software updates and technical support (online
and telephone) for a two-year period. The entity sells the license, installation service, and technical support
separately. The installation service includes changing the web screen for each type of user (for example,
marketing, inventory management, and information technology). The installation service is routinely performed
by other entities and does not significantly modify the software. The software remains functional without the
updates and the technical support.

37
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 606-10 (continued)

55-142 The entity assesses the goods and services promised to the customer to determine which goods and
services are distinct in accordance with paragraph 606-10-25-19. The entity observes that the software is
delivered before the other goods and services and remains functional without the updates and the technical
support. The customer can benefit from the updates together with the software license transferred at the
outset of the contract. Thus, the entity concludes that the customer can benefit from each of the goods and
services either on their own or together with the other goods and services that are readily available and the
criterion in paragraph 606-10-25-19(a) is met.

55-143 The entity also considers the principle and the factors in paragraph 606-10-25-21 and determines that
the promise to transfer each good and service to the customer is separately identifiable from each of the other
promises (thus, the criterion in paragraph 606-10-25-19(b) is met). In reaching this determination the entity
considers that although it integrates the software into the customer’s system, the installation services do not
significantly affect the customer’s ability to use and benefit from the software license because the installation
services are routine and can be obtained from alternate providers. The software updates do not significantly
affect the customer’s ability to use and benefit from the software license because, in contrast with Example 10
(Case C), the software updates in this contract are not necessary to ensure that the software maintains a high
level of utility to the customer during the license period. 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 the services into a combined output. Lastly, the entity concludes that the
software and the services do not significantly affect each other and, therefore, are not highly interdependent or
highly interrelated because the entity would be able to fulfill its promise to transfer the initial software license
independent from its promise to subsequently provide the installation service, software updates, or technical
support.

55-144 On the basis of this assessment, the entity identifies four performance obligations in the contract for
the following goods or services:
a. The software license
b. An installation service
c. Software updates
d. Technical support.

55-145 The entity applies paragraphs 606-10-25-23 through 25-30 to determine whether each of the
performance obligations for the installation service, software updates, and technical support are satisfied at a
point in time or over time. The entity also assesses the nature of the entity’s promise to transfer the software
license in accordance with paragraphs 606-10-55-59 through 55-60 and 606-10-55-62 through 55-64A (see
Example 54 in paragraphs 606-10-55-362 through 55-363B).

Case B — Significant Customization

55-146 The promised goods and services are the same as in Case A, except that the contract specifies that, as
part of the installation service, the software is to be substantially customized to add significant new functionality
to enable the software to interface with other customized software applications used by the customer. The
customized installation service can be provided by other entities.

38
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10 (continued)

55-147 The entity assesses the goods and services promised to the customer to determine which goods and
services are distinct in accordance with paragraph 606-10-25-19. The entity first assesses whether the criterion
in paragraph 606-10-25-19(a) has been met. For the same reasons as in Case A, the entity determines that
the software license, installation, software updates, and technical support each meet that criterion. The entity
next assesses whether the criterion in paragraph 606-10-25-19(b) has been met by evaluating the principle
and the factors in paragraph 606-10-25-21. The entity observes that the terms of the contract result in a
promise to provide a significant service of integrating the licensed software into the existing software system by
performing a customized installation service as specified in the contract. In other words, the entity is using the
license and the customized installation service as inputs to produce the combined output (that is, a functional
and integrated software system) specified in the contract (see paragraph 606-10-25-21(a)). The software is
significantly modified and customized by the service (see paragraph 606-10-25-21(b)). Consequently, the
entity determines that the promise to transfer the license is not separately identifiable from the customized
installation service and, therefore, the criterion in paragraph 606-10-25-19(b) is not met. Thus, the software
license and the customized installation service are not distinct.

55-148 On the basis of the same analysis as in Case A, the entity concludes that the software updates and
technical support are distinct from the other promises in the contract.

55-149 On the basis of this assessment, the entity identifies three performance obligations in the contract for
the following goods or services:
a. Software customization which is comprised of the license to the software and the customized
installation service
b. Software updates
c. Technical support.

55-150 The entity applies paragraphs 606-10-25-23 through 25-30 to determine whether each performance
obligation is satisfied at a point in time or over time and paragraphs 606-10-25-31 through 25-37 to measure
progress toward complete satisfaction of those performance obligations determined to be satisfied over time.
In applying those paragraphs to the software customization, the entity considers that the customized software
to which the customer will have rights is functional intellectual property and that the functionality of that
software will not change during the license period as a result of activities that do not transfer a good or service
to the customer. Therefore, the entity is providing a right to use the customized software. Consequently, the
software customization performance obligation is completely satisfied upon completion of the customized
installation service. The entity considers the other specific facts and circumstances of the contract in the
context of the guidance in paragraphs 606-10-25-23 through 25-30 in determining whether it should recognize
revenue related to the single software customization performance obligation as it performs the customized
installation service or at the point in time the customized software is transferred to the customer.

Example 56, Case A, in ASC 606-10-55-368 through 55-370 further illustrates use of the “capable of
being distinct” criterion. In this example, an entity determines that a pharmaceutical patent license is
not distinct from the entity’s promise to manufacture the drug for the customer because the customer
cannot benefit from the license without the corresponding manufacturing service.

39
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 606-10

Example 56 — Identifying a Distinct License

Case A — License Is Not Distinct
55-368 In this case, no other entity can manufacture this drug while the customer learns the manufacturing
process and builds its own manufacturing capability because of the highly specialized nature of the
manufacturing process. As a result, the license cannot be purchased separately from the manufacturing
service.

55-369 The entity assesses the goods and services promised to the customer to determine which goods and
services are distinct in accordance with paragraph 606-10-25-19. The entity determines that the customer
cannot benefit from the license without the manufacturing service; therefore, the criterion in paragraph
606-10-25-19(a) is not met. Consequently, the license and the manufacturing service are not distinct, and the
entity accounts for the license and the manufacturing service as a single performance obligation.

55-370 The nature of the combined good or service for which the customer contracted is a sole sourced supply
of the drug for the first five years; the customer benefits from the license only as a result of having access to a
supply of the drug. After the first five years, the customer retains solely the right to use the entity’s functional
intellectual property (see Case B, paragraph 606-10-55-373), and no further performance is required of the
entity during Years 6–10. The entity applies paragraphs 606-10-25-23 through 25-30 to determine whether
the single performance obligation (that is, the bundle of the license and the manufacturing service) is a
performance obligation satisfied at a point in time or over time. Regardless of the determination reached in
accordance with paragraphs 606-10-25-23 through 25-30, the entity’s performance under the contract will be
complete at the end of Year 5.

In addition, goods or services promised in the contract differ from activities that the entity needs to
undertake to transfer the promised goods or services. Promised goods or services are goods or services
that are transferred to the health tech company’s customer in accordance with the contract (i.e., goods
or services that result in the customer’s obtaining control of an asset). A good or service promised in the
contract must be evaluated so that the entity can determine whether the good or service represents a
distinct performance obligation. In contrast, an activity typically represents something that the entity is
required to undertake before or in connection with fulfilling an obligation to transfer a good or service to
the customer.

Because the core principle of the new revenue standard is for an entity to recognize revenue when it
transfers control of a good or service to a customer, it would be inappropriate for an entity to recognize
revenue for the completion of an activity. This is because completion of a fulfillment activity does
not transfer a good or service to a customer. An entity must sometimes use significant judgment in
distinguishing between fulfillment activities and promises to transfer goods or services to a customer.
Consider the following example:

Example 4-1

Health Tech Company A enters into a contract with Customer B to provide access to A’s software in a hosted
environment. Customer B is unable to take possession of the software; rather, B can only access the software
in A’s hosted environment (i.e., A is providing the SaaS). The contract requires A to make modifications to the
software at B’s request; however, A will control any modifications to the software and can use the modified
software to provide SaaS to customers other than B.

In this example, A’s obligation to modify the software at B’s request is not a promised good or service. Rather,
that obligation is a fulfillment activity that A needs to undertake before it can transfer the specified service (i.e.,
SaaS) to B. This is because B does not obtain control of any asset resulting from the customization services
since B is only able to access the modified software in A’s hosted environment.

40
 Chapter 4 — Revenue Recognition for Health Tech Companies

Once the distinct promised goods and services have been identified, the entity will then determine
which goods or services constitute a performance obligation, which is the unit of account under ASC
606. ASC 606-10-25-14 defines a performance obligation as a promise in a contract with a customer to
transfer to the customer either (1) a “good or service (or a bundle of goods or services) that is distinct” or
(2) a “series of distinct goods or services that are substantially the same and that have the same pattern
of transfer to the customer.”

Another important aspect of step 2 relevant to health tech companies and the evaluation of whether
goods and services are distinct is understanding the nature of the goods or services in question — for
this section, we refer to the discussion in Chapter 3 related to on-premise or hosted software and the
evaluation of the software under the criteria in ASC 350-40-15-4A, which are the same as those in ASC
985-20-15-5:
a. The customer has the contractual right to take possession of the software at any time during the
hosting period without significant penalty.
b. It is feasible for the customer to either run the software on its own hardware or contract with another
party unrelated to the vendor to host the software.

As noted above, many software hosting arrangements include a “license” to software but allow the
customer to use the software only in the entity’s hosted environment (because of contractual or practical
limitations or both). In these arrangements, the software is not even a promised good or service
in the contract since ownership of the software is not transferred to the customer. Although these
arrangements may include a contractual license, since the customer is unable to take possession of the
software subject to the license without significant penalty, the customer is required to make a separate
buying decision before control of any software is truly transferred to the customer (the separate buying
decision would be the customer’s election to incur the penalty to take possession of the software).
These transactions are accounted for as service transactions (rather than licensing transactions) and
the underlying software license itself is not considered a distinct performance obligation; rather, it is
an input to the service, since the entity is providing the functionality of the software through a hosting
arrangement (service) rather than through an actual software license that is controlled by the customer.
This determination is important, since it directly factors into the conclusions discussed later in step 5
regarding whether the revenue associated with the good or service (software license or hosted SaaS) may
be recognized at a point in time (such as the delivery of the software license itself to the customer) or
over time (such as over the period the customer has access to the hosted SaaS).

4.1.2.2 Evaluating Whether Goods or Services May Be Considered a Series

As previously mentioned, ASC 606-10-25-14 describes what a performance obligation is. ASC 606-10-
25-14(b) explains that a performance obligation can be a series of goods or services; however, the
performance obligation must meet certain requirements to qualify as a series and therefore be
accounted for as a singular performance obligation rather than multiple individual distinct performance
obligations. Specifically, the goods or services must be substantially the same and have the same
pattern of transfer to the customer as though they were a single performance obligation. As explained in
paragraph BC113 of ASU 2014-09, the FASB and the International Accounting Standards Board (IASB®)
decided to provide the series guidance to promote consistent application of the new revenue standard
to similar goods and services.

ASC 606-10-25-15 clarifies the meaning of “the same pattern of transfer.”

41
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 606-10

25-15 A series of distinct goods or services has the same pattern of transfer to the customer if both of the
following criteria are met:
a. Each distinct good or service in the series that the entity promises to transfer to the customer would
meet the criteria in paragraph 606-10-25-27 to be a performance obligation satisfied over time [see
Section 4.1.5.1].
b. In accordance with paragraphs 606-10-25-31 through 25-32 [see Section 4.1.5.1], the same method
would be used to measure the entity’s progress toward complete satisfaction of the performance
obligation to transfer each distinct good or service in the series to the customer.

Entities that determine that the series guidance applies to their goods or services must account for
them as a series. In other words, goods or services that meet the requirements of ASC 606-10-25-14(b)
must be accounted for as a single performance obligation. (This guidance is similar to that on whether
goods or services are distinct or must be “bundled” as a single account.)

An entity should use significant judgment in determining how series guidance may apply to health tech
companies. Consider again a potential scenario involving a telehealth company that contracts with
health care providers to provide patients with remote access via a proprietary SaaS platform. In this
example, the contract is written in such a way that the patient is charged either per distinct telehealth
visit or a flat monthly minimum fee for an indefinite number of visits (in this example, the customer
may choose between the two pricing models before signing the contract). The customer has access
to physicians via synchronous (i.e., in real time) or asynchronous (i.e., recorded exchange of medical
information to be stored and forwarded on the platform between the patient and physician) visits.

In the former scenario in which the customer is charged per telehealth visit, the telehealth provider
may, upon concluding that the performance obligation is the delivery of telehealth visits and that these
visits qualify for revenue recognition over time (see Section 4.1.5.1), assess whether such visits qualify
as substantially the same. For example, the customer may receive differing medical diagnoses or opinions
during each visit in such a way that the underlying activities within each visit may differ; however,
depending on the contract terms, the telehealth provider may conclude that its promise is to facilitate
the visits themselves (not to provide medical diagnoses). In such circumstances, the nature of the visits
would be the same regardless of the medical outcome; therefore, the measure of progress would be the
same and the series guidance would apply.

This example is applicable both when telehealth visits are priced per visit, as discussed above, or when
the customer can make unlimited visits in exchange for a flat monthly fee, in which case the telehealth
provider agrees to make its platform and visits available over a specified period such that the promise
to the customer may be determined to be daily access to its SaaS platform for messaging or real-time
visiting with physicians as needed. The activities and level of service provided by the telehealth company
may therefore differ each day but may still qualify for the series guidance if the days of access to
the telehealth platform — the distinct obligations — can be recognized over time, are considered
substantially the same, and are measured with the same measure of progress.

42
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10-25-18 lists types of promises in a contract that an entity should assess to determine
whether they are distinct performance obligations. For example, ASC 606-10-25-18(e) describes a
service of “standing ready” to provide goods or services (“stand-ready obligation”). The example above
introduces the concept of a “stand-ready” obligation. When an entity enters into a contract with a
customer and agrees to make itself available to provide an unspecified number of goods and services
to the customer over a specified period, such a promise is generally viewed as a stand-ready obligation.
In this type of arrangement, a customer typically receives and consumes a benefit from a stand-ready
obligation — namely, the assurance that a service is available to the customer when and if needed or
called upon.

It may be complex to distinguish a performance obligation to deliver goods or services from a stand-
ready obligation to deliver goods or services. In such cases, an entity will be required to consider the
arrangement’s relevant facts and circumstances. However, an entity should begin by identifying the
nature of the promise in the contract. For example, the determination of whether the promise is an
obligation to provide one or more defined goods or services or is instead an obligation to provide an
unknown type or quantity of goods or services might be a strong indicator of the nature of the entity’s
promise in the contract. While in either case the entity might be required to “stand ready” to deliver
the good(s) or service(s) whenever the customer calls for them or when a contingent event occurs
(e.g., snowfall), the fact that the entity will not know when or how extensively the customer will receive
the entity’s good(s) or service(s) during the contract term may be a strong indicator that the entity is
standing ready to perform.

Example 18 in ASC 606-10-55-184 through 55-186 discusses stand-ready obligations in health club
memberships. The example notes that the entity’s promise is to provide a service of making the health
clubs available because the extent to which a customer uses the health clubs does not affect the
amount of the remaining goods and services to which the customer is entitled. This is consistent with
the discussion in paragraph BC160 of ASU 2014-09.

Other examples of stand-ready performance obligations may include the following:

• Snow removal services — An entity promises to remove snow on an “as needed” basis. In this type
of arrangement, the entity does not know and most likely cannot reasonably estimate whether,
how often, and how much it will snow. This suggests that the entity’s promise is to stand ready
to provide these services on a when-and-if-needed basis.

• Software upgrades — An entity promises to make unspecified (i.e., when-and-if-available)

software upgrades available to a customer, and the entity has no discernible pattern of
providing updates. The nature of the entity’s promise is fundamentally one of providing the
customer with assurance that any upgrades or updates developed by the entity during the
period will be made available because the entity stands ready to transfer updates or upgrades
when and if they become available.

• Extended warranty — A customer purchases an extended product warranty for a good (e.g.,
equipment), and the entity promises to remediate any issues with the product when and if
problems arise. That is, the entity is standing ready to make repairs when and if needed.

The telehealth provider referred to above is promising to deliver remote medical care through various
means (per visit or standing ready to provide an unspecified number of visits) and perhaps through
various types of care (e.g., general, urgent, or specialty). In all cases, however, the specific nature of the
promise to the customer is important to the determination of whether the visits may qualify as one
performance obligation or a series of distinct goods or services that are substantially the same and that
have the same pattern of transfer to the customer under ASC 606-10-25-14 and 25-15.

43
Deloitte | Health Tech Industry Accounting Guide (2023)

The following decision tree illustrates the process for identifying performance obligations in a contract:

Identify all explicitly and implicitly

promised goods and services in the
contract.

Are all
promised
goods and services
Material Promises

material in the
context of the
contract?

No Yes

Continue with the analysis for

Exclude immaterial promises
each material promised good or
from further analysis.
service as follows.

Is
the
good or
Is the good or service (or
service (or bundle bundle of goods and
of goods and services) services) capable of being
distinct within the context of distinct?
the contract? Yes
That is, can the customer benefit
That is, is the good or service from the good or service
Distinct Criteria

separately identifiable on its own or together

from other promises with other readily
in the contract? available
resources?

Yes No
No

Combine two or more promised

goods or services and reevaluate
the new bundle.

Is each transfer of a
distinct good or service
Is the distinct good or satisfied over time, and does
service (or bundle of goods Yes each transfer of a distinct good
and services) part of a series of or service satisfied over time have the
distinct goods or services that same measure of progress? Refer to
are substantially the same? Chapter 8 of Deloitte’s Roadmap
Revenue Recognition.
Series Criteria

Yes

No

Account for the distinct good Account for the series of distinct
or service as a performance goods or services as a single
obligation. performance obligation.

44
 Chapter 4 — Revenue Recognition for Health Tech Companies

In addition, when identifying a performance obligation, an entity should determine whether it is a

principal or an agent in the transaction because that determination will affect how (and sometimes
when) the entity reports the revenue earned. While step 2 is probably the best stage of the revenue
recognition process for determining whether an entity is a principal or an agent, there are many
considerations that go into that determination. Accordingly, principal-versus-agent considerations are
discussed separately in Chapter 10 of Deloitte’s Roadmap Revenue Recognition.

4.1.3 Step 3: Determine the Transaction Price

Once the contract and performance obligations are identified, the entity must determine the transaction
price. In accordance with ASC 606-10-32, the transaction price is the amount of consideration to which
an entity expects to be entitled in exchange for transferring goods or services, excluding amounts
collected on behalf of third parties. To determine the transaction price, an entity considers (1) the terms
of the contract and any amounts of fixed consideration; (2) the effects of variable consideration; (3) the
constraint on variable consideration, if any; (4) the existence of a significant financing component in
the contract; (5) noncash consideration; and (6) consideration payable to the customer. Note that an
entity assumes that the goods or services will be transferred to the customer on the basis of the terms
of the existing enforceable contract and does not take into consideration the possibility of a contract’s
cancellation, renewal, or modification. When determining the transaction price, it is common for health
tech entities to evaluate nonrefundable up-front fees, variable consideration, and significant financing
components.

4.1.3.1 Nonrefundable Up-Front Fees

Health tech contracts may include certain nonrefundable up-front fees that are paid in conjunction
with the execution of the contract, such as set-up fees for SaaS contracts or hosting arrangements.
These fees may (1) be related to a good or service (e.g., implementation fees for a software licensing
arrangement or SaaS contract, which would need to be evaluated to determine whether they are
distinct) or (2) not result in the transfer of a good or service to the customer (e.g., set-up activities in a
SaaS arrangement). In both instances, the fees are not related to a distinct good or service; thus, the
costs associated with such activities should be part of the transaction price allocated to the various
performance obligations in the contract.

Paragraph BC190 of ASU 2014-09 indicates that consideration in a contract with a customer may vary
as a result of many different factors, and variability may arise in many different circumstances. Variable
consideration is easiest to identify in a contract when price, quantity, or both are not fixed and known
at the contract’s inception. Consider again the example of the telehealth company. When the contract is
priced on a per-visit basis, the amount of consideration to which the telehealth provider expects to be
entitled over any given period is variable because the specific quantity of visits that may be billed for is
unknown at contract inception. If the contracts are priced by using a fixed fee for an undefined amount
of visits over a set time frame, the consideration may not be deemed variable since the telehealth
provider already knows the amount of consideration to which it expects to be entitled over the full term
of the contract.

45
Deloitte | Health Tech Industry Accounting Guide (2023)

Regardless of the form of variability or its complexity, once variable consideration is identified, an entity
must estimate the amount of variable consideration to determine the transaction price in a contract
with a customer. Since revenue is one of the most important metrics to users of financial statements,
the boards and their constituents agreed that estimates of variable consideration are only useful to the
extent that an entity is confident that the revenue recognized as a result of those estimates will not be
subsequently reversed. Accordingly, as noted in paragraph BC203 of ASU 2014-09, the FASB and IASB
acknowledged that some estimates of variable consideration should not be included in the transaction
price if the inherent uncertainty could prevent a faithful depiction of the consideration to which the
entity expects to be entitled in exchange for delivering goods or services. Thus, the focus of the boards’
deliberations on a mechanism to improve the usefulness of estimates in revenue as a predictor of future
performance was to limit subsequent downward adjustments in revenue (i.e., reversals of revenue
recognized). The result of those deliberations is commonly referred to as the “constraint.”

ASC 606-10-32-11 further clarifies this point by stating, “[a]n entity shall include in the transaction
price some or all of an amount of variable consideration estimated in accordance with paragraph
606-10-32-8 only to the extent that it is probable that a significant reversal in the amount of cumulative
revenue recognized will not occur when the uncertainty associated with the variable consideration
is subsequently resolved.” Inherent in the language of ASC 606-10-32-11 is a link between the
measurement of variable consideration in the transaction price (step 3) and the recognition of an
appropriate amount of revenue (step 5). That is, the constraint is naturally a measurement concept
because it influences the amount of variable consideration included in the transaction price. However,
its application is driven by a recognition concept and the avoidance of reversing the cumulative amount
of revenue previously recognized.

4.1.3.2 Variable Consideration
Variable consideration is often found in health tech contracts in the form of discounts, rebates, refunds,
credits, price concessions, incentives, usage-based fees in SaaS arrangements, and performance
bonuses or penalties. ASC 606-10-32-8 states that either of the following methods should be used to
estimate variable consideration, depending on which method the entity thinks will better predict the
amount of consideration to which it will be entitled:
a. The expected value — The expected value is the sum of probability-weighted amounts in a range of
possible consideration amounts. An expected value may be an appropriate estimate of the amount of
variable consideration if an entity has a large number of contracts with similar characteristics.
b. The most likely amount — The most likely amount is the single most likely amount in a range of possible
consideration amounts (that is, the single most likely outcome of the contract). The most likely amount
may be an appropriate estimate of the amount of variable consideration if the contract has only two
possible outcomes (for example, an entity either achieves a performance bonus or does not).

To determine the expected value, health tech companies need to have a large number of similar
transactions and must evaluate the similarity and volume of the contracts included in the assessment.
The contracts used in the assessment do not need to be identical; rather, it is sufficient for them to
be substantially similar. Therefore, it is critical for health tech companies to use judgment in making
this determination. Note that ASC 606-10 contains numerous examples of constraining estimates of
variable consideration, including sales with right-of-return considerations, price concessions, volume
discount incentives, and management fees subject to constraint. As mentioned above, the term
“constraint” resulted from the FASB’s and IASB’s deliberations when developing ASU 2014-09 (codified in
ASC 606). The boards tried to create a mechanism to improve estimates in revenue related to variable
consideration (e.g., by limiting revenue reversals in future fiscal periods). Essentially, the boards intended
to create a downward bias in revenue recognition to limit future debits to revenue and thus make the
financial statements more relevant to users of the financial statements.

46
 Chapter 4 — Revenue Recognition for Health Tech Companies

Connecting the Dots

Using the Most Likely Amount Method or the Expected Value Method to Estimate Variable
Consideration
As stated in the first sentence of ASC 606-10-32-9, a single method of estimating variable
consideration should be used throughout the term of the contract with the customer. That is,
the method of estimating variable consideration should not be reassessed or changed once it is
selected as the most appropriate.

In paragraph BC197 of ASU 2014-09, the boards briefly discuss “management’s best estimate”
as a method of estimating variable consideration and acknowledge stakeholders who noted in
deliberations that such a method “would provide management with the flexibility to estimate
on the basis of its experience and available information without the documentation that would
be required when a measurement model is specified.” However, as noted in paragraph BC201
of ASU 2014-09, the boards do not expect that either the most likely amount method or the
expected value method of estimating variable consideration will be too costly or complex for
entities to apply to contracts with customers. Specifically, the boards allow that an entity would
not be expected to develop complex modeling techniques to identify all possible outcomes of
variable consideration when determining the most likely outcome or a probability distribution of
outcomes. Thus, the benefits of applying the most likely amount method or the expected value
method to estimate variable consideration exceed the costs of doing so.

As previously noted, an entity is required to use one of two methods to estimate variable consideration,
and management’s best estimate is not one of those methods. Although we think that it is appropriate
for an entity to be pragmatic in deriving an estimate by using one of the required methods, we do not
think that it is appropriate to use a method described as management’s best estimate as either the most
likely amount or the expected value of variable consideration.

When evaluating whether there is a difference in timing between when goods and services are
transferred and when the promised consideration is paid, health tech entities must evaluate whether a
significant financing component is present. Specifically, ASC 606-10-32-15 states:

ASC 606-10

32-15 In determining the transaction price, an entity shall adjust the promised amount of consideration for
the effects of the time value of money if the timing of payments agreed to by the parties to the contract (either
explicitly or implicitly) provides the customer or the entity with a significant benefit of financing the transfer
of goods or services to the customer. In those circumstances, the contract contains a significant financing
component. A significant financing component may exist regardless of whether the promise of financing is
explicitly stated in the contract or implied by the payment terms agreed to by the parties to the contract.

47
Deloitte | Health Tech Industry Accounting Guide (2023)

A significant financing component may exist in term software and SaaS contracts if there are
significant timing differences between when a good or service is transferred and when cash (or other
consideration) is exchanged so that the time value of money needs to be considered. ASC 606-10-
55-244 through 55-246 provide a related example, which could apply to health tech companies:

ASC 606-10

Example 30 — Advance Payment

55-244 An entity, a technology product manufacturer, enters into a contract with a customer to provide global
telephone technology support and repair coverage for three years along with its technology product. The
customer purchases this support service at the time of buying the product. Consideration for the service is
an additional $300. Customers electing to buy this service must pay for it upfront (that is, a monthly payment
option is not available).

55-245 To determine whether there is a significant financing component in the contract, the entity considers
the nature of the service being offered and the purpose of the payment terms. The entity charges a single
upfront amount, not with the primary purpose of obtaining financing from the customer but, instead, to
maximize profitability, taking into consideration the risks associated with providing the service. Specifically,
if customers could pay monthly, they would be less likely to renew, and the population of customers that
continue to use the support service in the later years may become smaller and less diverse over time (that is,
customers that choose to renew historically are those that make greater use of the service, thereby increasing
the entity’s costs). In addition, customers tend to use services more if they pay monthly rather than making
an upfront payment. Finally, the entity would incur higher administration costs such as the costs related to
administering renewals and collection of monthly payments.

55-246 In assessing the guidance in paragraph 606-10-32-17(c), the entity determines that the payment terms
were structured primarily for reasons other than the provision of finance to the entity. The entity charges a
single upfront amount for the services because other payment terms (such as a monthly payment plan) would
affect the nature of the risks assumed by the entity to provide the service and may make it uneconomical
to provide the service. As a result of its analysis, the entity concludes that there is not a significant financing
component.

The key consideration relevant to the above example (as it is to other health tech companies) is the
business reason behind the contractual payment arrangement. To determine whether a significant
financing component exists, an entity considers the amount of time between the transfer of goods or
services and receipt of payment; an entity must use judgment in making this determination. If such a
significant financing component does exist, the transaction price must be adjusted by the significant
financing component in accordance with ASC 606-10-32-15.

4.1.4 Step 4: Allocate the Transaction Price to the Performance Obligations

In step 4 of ASC 606, an entity allocates the transaction price to each of the identified performance
obligations. For a contract containing more than one performance obligation, the allocation is made
on the basis of the relative SSP of each distinct good or service. As described earlier, health tech
companies often bundle their software offerings with implementation services, training, hardware,
maintenance, and PCS; each of these goods or services would most likely differ with respect to (1) the
costs of providing the good or service to customers, (2) companies’ margin targets, and (3) the revenue
amounts to be recognized for each good or service. ASC 606-10-32-29 requires an entity to allocate
the transaction price to each performance obligation on a relative SSP basis by using observable inputs
to the greatest extent possible or, if no observable inputs are available, by estimating the stand-alone
price. The SSP is the price at which an entity would provide a good or service separately from the other
bundled goods or services promised in a contract.

48
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10-32-31 states, “To allocate the transaction price to each performance obligation on a relative
standalone selling price basis, an entity shall determine the standalone selling price at contract inception
of the distinct good or service underlying each performance obligation in the contract and allocate the
transaction price in proportion to those standalone selling prices.” While the SSP may be the stated
contract price, the best evidence for a performance obligation’s SSP is the price at which the company
sold the good or service on a stand-alone basis to a similar customer, which is an observable input, as
noted in ASC 606-10-32-32. The SSP must also be supported by other factors, such as consistency in
contract prices for multiple contracts with various performance obligations. Further, the allocation that
results from the determination of SSPs must meet the allocation objective (i.e., allocation of an amount
of consideration that the entity would expect to be entitled to in exchange for the promised good or
service).

While the concept of the SSP in ASC 606 replaces the related concepts under ASC 605, the approach
is similar in that the best evidence is an observable price at which entities sell their good or service to
similar customers. In accordance with ASC 606-10-32-33, if no such observable input exists, entities
must estimate the selling price by considering “all information (including market conditions, entity-
specific factors, and information about the customer or class of customer) that is reasonably available
to the entity. In doing so, an entity shall maximize the use of observable inputs and apply estimation
methods consistently in similar circumstances.”

ASC 606-10-32-34 indicates that suitable methods for estimating SSPs may include the following:
a. Adjusted market assessment approach — An entity could evaluate the market in which it sells goods or
services and estimate the price that a customer in that market would be willing to pay for those goods
or services. That approach also might include referring to prices from the entity’s competitors for similar
goods or services and adjusting those prices as necessary to reflect the entity’s costs and margins.
b. Expected cost plus a margin approach — An entity could forecast its expected costs of satisfying a
performance obligation and then add an appropriate margin for that good or service.
c. Residual approach — An entity may estimate the standalone selling price by reference to the total
transaction price less the sum of the observable standalone selling prices of other goods or services
promised in the contract. However, an entity may use a residual approach to estimate, in accordance
with paragraph 606-10-32-33, the standalone selling price of a good or service only if one of the
following criteria is met:
1. The entity sells the same good or service to different customers (at or near the same time) for
a broad range of amounts (that is, the selling price is highly variable because a representative
standalone selling price is not discernible from past transactions or other observable evidence).
2. The entity has not yet established a price for that good or service, and the good or service has not
previously been sold on a standalone basis (that is, the selling price is uncertain).

Entities can assess various data points in estimating the SSP and may consider the costs of providing the
goods or services to customers, their target margins for each good or service, competitor pricing, large
versus small customers, and other entity-specific factors.

Note that SSPs are estimated at contract inception. Health tech companies may have contracts in
which they are delivering a service over a multiyear contractual period. ASC 606-10-32-43 indicates that
even if the SSP changes over time, the company should not reallocate the transaction price to reflect
the changes in the SSP for ongoing contracts. Further, goods or services can be sold to many different
types, or classes, of customers and, with respect to health tech contracts, these customers can be in
multiple sectors within the life sciences and health care industry. These different classes of customers
may have differing SSPs if, for example, each customer class would be willing to pay a different price
for the good or service on the basis of the nature of the company’s relationship with the customer or
other specific circumstances unique to each customer. The SSPs are determined for each performance
obligation, not the contract as a whole, so an entity may have to use a different estimation method

49
Deloitte | Health Tech Industry Accounting Guide (2023)

for each performance obligation. It is important to apply such a method consistently to similar types
of goods and services in different contracts, though it may not be necessary to do so for the different
performance obligations within each contract.

A residual approach may be considered for health tech companies if the SSP of some of the goods
or services is either highly variable or uncertain, as may be the case when contracts include software
licenses along with professional services and PCS. An entity may have observable SSPs for the
professional services and the PCS if they are regularly sold as separate performance obligations, but the
SSPs of licenses in a contract may be highly variable or uncertain. In such a scenario, the entity might
use the residual approach to determine the amount of the transaction price that should be allocated to
the licenses in the aggregate (i.e., the transaction price minus the SSPs of the professional services and
the PCS) and then use another method to further allocate the residual transaction price to each license.
Note, however, that use of the residual approach is not expected to be common and will need to be
thoroughly supported by health tech company management.

Two areas of complexity in allocation arise when the transaction price includes discounts or variable
consideration. Both complexities may be present in health tech contracts, since services, PCS, or
hardware may be discounted from their otherwise stated list price if a customer elects to purchase the
entirety of the bundle. In accordance with the general allocation principle, the discounted transaction
price is allocated proportionately to each distinct good and service on the basis of its relative SSP.
However, there may be instances in which the result of this allocation approach does not faithfully depict
the amount of consideration to which the entity expects to be entitled in exchange for the underlying
goods or services. That is, the allocation approach may result in revenue recognition that is inconsistent
with the core principle in the new revenue standard. This may occur, for example, if certain goods or
services are routinely sold at a very low margin while others are sold at a very high margin. An entity may
routinely discount the high-margin goods or services but not discount the low-margin goods or services.
Allocating a discount proportionately to these goods or services may result in an allocated amount that
does not accurately depict the amount of consideration to which the entity expects to be entitled in
exchange for the goods or services. ASC 606-10-32-37 states the following regarding the allocation of
discounts:

An entity shall allocate a discount entirely to one or more, but not all, performance obligations in the contract if
all of the following criteria are met:
a. The entity regularly sells each distinct good or service (or each bundle of distinct goods or services) in
the contract on a standalone basis.
b. The entity also regularly sells on a standalone basis a bundle (or bundles) of some of those distinct
goods or services at a discount to the standalone selling prices of the goods or services in each bundle.
c. The discount attributable to each bundle of goods or services described in (b) is substantially the
same as the discount in the contract, and an analysis of the goods or services in each bundle provides
observable evidence of the performance obligation (or performance obligations) to which the entire
discount in the contract belongs.

An entity does not need to sell each distinct good or service on a stand-alone basis to allocate a discount
to one or some, but not all, goods or services. Although judgment is integral to making this allocation,
generally for the criterion in ASC 606-10-32-37(a) to be met, the entity will regularly sell bundles of goods
or services at the same discount that is inherent in the contract and have observable evidence that the
discount in the contract is related to one or some (i.e., the bundle of goods or services routinely sold at a
discount), but not all, performance obligations in the contract.

If a contract includes variable consideration, it may have to be allocated to one or more, but not all, of
the performance obligations, depending on the specific requirements, as detailed below.

50
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10

32-39 Variable consideration that is promised in a contract may be attributable to the entire contract or to a
specific part of the contract, such as either of the following:
a. One or more, but not all, performance obligations in the contract (for example, a bonus may be
contingent on an entity [implementing a software platform into a customer’s enterprise resource
planning system within a certain amount of time])
b. 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 in accordance with paragraph 606-10-25-14(b)
(for example, the consideration promised for the second year of a two-year [hardware maintenance
contract] will increase on the basis of movements in a specified inflation index).

32-40 An entity shall allocate a variable amount (and subsequent changes to that amount) entirely to a
performance obligation or to a distinct good or service that forms part of a single performance obligation in
accordance with paragraph 606-10-25-14(b) if both of the following criteria are met:
a. 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 (or to a specific outcome from satisfying the
performance obligation or transferring the distinct good or service).
b. Allocating the variable amount of consideration entirely to the performance obligation or the distinct
good or service is consistent with the allocation objective in paragraph 606-10-32-28 when considering
all of the performance obligations and payment terms in the contract.

Example 35 in ASC 606-10-55-270 through 55-279 further illustrates the allocation of variable
consideration.

ASC 606-10

Example 35 — Allocation of Variable Consideration

55-270 An entity enters into a contract with a customer for two intellectual property licenses (Licenses X and
Y), which the entity determines to represent two performance obligations each satisfied at a point in time. The
standalone selling prices of Licenses X and Y are $800 and $1,000, respectively.

Case A — Variable Consideration Allocated Entirely to One Performance Obligation

55-271 The price stated in the contract for License X is a fixed amount of $800, and for License Y the
consideration is 3 percent of the customer’s future sales of products that use License Y. For purposes of
allocation, the entity estimates its sales-based royalties (that is, the variable consideration) to be $1,000, in
accordance with paragraph 606-10-32-8.

55-272 To allocate the transaction price, the entity considers the criteria in paragraph 606-10-32-40 and
concludes that the variable consideration (that is, the sales-based royalties) should be allocated entirely to
License Y. The entity concludes that the criteria in paragraph 606-10-32-40 are met for the following reasons:
a. The variable payment relates specifically to an outcome from the performance obligation to transfer
License Y (that is, the customer’s subsequent sales of products that use License Y).
b. Allocating the expected royalty amounts of $1,000 entirely to License Y is consistent with the allocation
objective in paragraph 606-10-32-28. This is because the entity’s estimate of the amount of sales-
based royalties ($1,000) approximates the standalone selling price of License Y and the fixed amount
of $800 approximates the standalone selling price of License X. The entity allocates $800 to License X
in accordance with paragraph 606-10-32-41. This is because, based on an assessment of the facts and
circumstances relating to both licenses, allocating to License Y some of the fixed consideration in addition
to all of the variable consideration would not meet the allocation objective in paragraph 606-10-32-28.

51
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 606-10 (continued)

55-273 The entity transfers License Y at inception of the contract and transfers License X one month later.
Upon the transfer of License Y, the entity does not recognize revenue because the consideration allocated to
License Y is in the form of a sales-based royalty. Therefore, in accordance with paragraph 606-10-55-65, the
entity recognizes revenue for the sales-based royalty when those subsequent sales occur.

55-274 When License X is transferred, the entity recognizes as revenue the $800 allocated to License X.

Case B — Variable Consideration Allocated on the Basis of Standalone Selling Prices

55-275 The price stated in the contract for License X is a fixed amount of $300, and for License Y the
consideration is 5 percent of the customer’s future sales of products that use License Y. The entity’s estimate
of the sales-based royalties (that is, the variable consideration) is $1,500 in accordance with paragraph
606-10-32-8.

55-276 To allocate the transaction price, the entity applies the criteria in paragraph 606-10-32-40 to determine
whether to allocate the variable consideration (that is, the sales-based royalties) entirely to License Y. In
applying the criteria, the entity concludes that even though the variable payments relate specifically to an
outcome from the performance obligation to transfer License Y (that is, the customer’s subsequent sales of
products that use License Y), allocating the variable consideration entirely to License Y would be inconsistent
with the principle for allocating the transaction price. Allocating $300 to License X and $1,500 to License Y
does not reflect a reasonable allocation of the transaction price on the basis of the standalone selling prices
of Licenses X and Y of $800 and $1,000, respectively. Consequently, the entity applies the general allocation
requirements in paragraphs 606-10-32-31 through 32-35.

55-277 The entity allocates the transaction price of $300 to Licenses X and Y on the basis of relative standalone
selling prices of $800 and $1,000, respectively. The entity also allocates the consideration related to the sales-
based royalty on a relative standalone selling price basis. However, in accordance with paragraph 606-10-
55-65, when an entity licenses intellectual property in which the consideration is in the form of a sales-based
royalty, the entity cannot recognize revenue until the later of the following events: the subsequent sales occur
or the performance obligation is satisfied (or partially satisfied).

55-278 License Y is transferred to the customer at the inception of the contract, and License X is transferred
three months later. When License Y is transferred, the entity recognizes as revenue the $167 ($1,000 ÷ $1,800
× $300) allocated to License Y. When License X is transferred, the entity recognizes as revenue the $133 ($800
÷ $1,800 × $300) allocated to License X.

55-279 In the first month, the royalty due from the customer’s first month of sales is $200. Consequently, in
accordance with paragraph 606-10-55-65, the entity recognizes as revenue the $111 ($1,000 ÷ $1,800 × $200)
allocated to License Y (which has been transferred to the customer and is therefore a satisfied performance
obligation). The entity recognizes a contract liability for the $89 ($800 ÷ $1,800 × $200) allocated to License
X. This is because although the subsequent sale by the entity’s customer has occurred, the performance
obligation to which the royalty has been allocated has not been satisfied.

If a contract includes both variable consideration and a discount, an entity would first apply the guidance
in ASC 606-10-32-39 through 32-41 on allocation of variable consideration to determine whether
the criteria for allocating the variable consideration to one or more (but not all) of the performance
obligations are met. After considering the guidance on allocating variable consideration, the entity
would look to the discount allocation guidance to determine how to allocate the discount. ASC 606-10-
32-41 establishes a hierarchy that requires an entity to identify and allocate variable consideration to
performance obligations before applying other guidance (e.g., the guidance on allocating a discount).
Once the transaction price is allocated to the performance obligations in the contract, an entity can
recognize revenue when it satisfies a performance obligation.

52
 Chapter 4 — Revenue Recognition for Health Tech Companies

4.1.5 Step 5: Recognize Revenue When (or as) the Entity Satisfies a

Performance Obligation
The final step of the revenue recognition process is to recognize revenue when or as control of
the performance obligation is transferred to the customer. As noted previously, ASC 606-10-25-23
addresses this concept, stating that “[a]n entity shall recognize revenue when (or as) the entity satisfies a
performance obligation by transferring a promised good or service (that is, an asset) to a customer” and
that “[a]n asset is transferred when (or as) the customer obtains control of that asset.”

This guidance underscores the importance of determining when control of the underlying goods or
services (i.e., the asset(s) the customer will receive) related to the performance obligation are transferred
to the customer. ASC 606-10-25-25 defines such control as follows:

Control of an asset refers to the ability to direct the use of, and obtain substantially all of the remaining benefits
from, the asset. Control includes the ability to prevent other entities from directing the use of, and obtaining the
benefits from, an asset. The benefits of an asset are the potential cash flows (inflows or savings in outflows) that
can be obtained directly or indirectly in many ways . . . .

The key takeaway from this portion of the guidance is that the customer must be able to dictate the use
of the asset and either obtain the remaining benefits of the asset or prevent others from obtaining the
economic benefits before concluding that control of the asset has been transferred.

For example, assume that a vendor provides a highly customized on-premise software license to the
customer and implementation of this software within the customer’s existing IT infrastructure. The
software license itself may be delivered to the customer through mechanisms such as an online portal
to download the software or e-mail. However, if it is determined that the performance obligation in
step 2 includes the customization of the software, the customer cannot obtain the benefits of using the
delivered software until it has been customized, which then affects the determination (discussed below)
of when control of the performance obligation is transferred (and consequently, when revenue may be
recognized). This illustrates the importance of properly defining the performance obligation.

Similarly, a customer may be provided with access to a software license for a definite period of time via
a SaaS arrangement, but delivery of the specific access code to the SaaS or other means of providing
the SaaS to the customer may not necessarily be aligned with when control of the service begins to be
transferred. Companies must thoughtfully assess whether any other requirements are associated with
their SaaS offerings that must be implemented or installed for the customer to both begin directing
the use of and receiving the benefits of its SaaS subscription. That is, control of the SaaS itself may only
begin to be transferred once any required implementation is complete.

Once definitions of the performance obligations and transfer of control are understood, an entity then
applies the ASC 606 guidance to determine when control is transferred. ASC 606 notes that control may
be transferred either over time or at a point in time and that this transfer affects the timing and pattern
of revenue recognition. In accordance with ASC 606-10-25-27, the following criteria indicate that an
entity satisfies a performance obligation over time:
a. The customer simultaneously receives and consumes the benefits provided by the entity’s performance
as the entity performs (see paragraphs 606-10-55-5 through 55-6).
b. The entity’s performance creates or enhances an asset (for example, work in process) that the customer
controls as the asset is created or enhanced (see paragraph 606-10-55-7).
c. The entity’s performance does not create an asset with an alternative use to the entity (see paragraph
606-10-25-28), and the entity has an enforceable right to payment for performance completed to date
(see paragraph 606-10-25-29).

53
Deloitte | Health Tech Industry Accounting Guide (2023)

If none of these three criteria are met, the performance obligation would be transferred at a specific
point in time in accordance with ASC 606-10-25-30.

4.1.5.1 Revenue Recognized Over Time

Regarding the criterion in ASC 606-10-25-27(a), a performance obligation is satisfied over time if the
customer simultaneously receives and consumes the benefits provided. A SaaS arrangement serves as
a classic example illustrating when this criterion is met for health tech customers. Once the necessary
steps have been taken to grant the customer functional access to the SaaS platform, the customer has
use of the platform over the term of the arrangement; therefore, the realization of the benefits of this
access coincides with the company’s continual delivery of the access to the customer.

The second criterion in ASC 606-10-25-27(b) — that a customer controls an asset that is being created/
enhanced as it is being built — is similar to the construction- or production-type contracts from legacy
GAAP. This criterion specifically mentions work-in-process, which may be more applicable to companies
in the construction space but would also be relevant to health tech companies. For example, when
a performance obligation is the delivery of a customized, on-premise software license, the bundled
software and implementation services constitute a single performance obligation that represents the
combined good or service that is transferred to the customer (i.e., for which the customer obtains
control) as progress toward complete implementation of the customized on-premise solution occurs.

The third and final criterion in ASC 606-10-25-27(c) was added to clarify situations in which it is unclear
exactly which party controls the asset as it is being built or enhanced. For an entity to conclude that the
performance obligation is satisfied over time in such situations, the asset must not have an alternative
use to the entity and the entity must have an enforceable right to payment of cost plus a margin for the
activity that has occurred to that point. For example, in a contract related to software implementation
services, the nature of the implementation and the degree of customization required may lead the
entity to develop a highly customized solution for that customer and the customer’s IT infrastructure,
regardless of whether the contract addresses who controls the software and the direction of the
implementation service. In such instances, the time spent performing the implementation and the
in-process implementation itself may not be able to be resold or delivered to another customer (since
the time has already been spent and the software in question has been heavily modified to suit the
customer’s particular needs). ASC 606-10-25-29 further addresses the determination of whether an
enforceable right to payment exists (the second condition of this criterion) and states:

An entity shall consider the terms of the contract, as well as any laws that apply to the contract, when evaluating
whether it has an enforceable right to payment for performance completed to date in accordance with
paragraph 606-10-25-27(c). The right to payment for performance completed to date does not need to be for
a fixed amount. However, at all times throughout the duration of the contract, the entity must be entitled to
an amount that at least compensates the entity with a reasonable margin for performance completed to date
if the contract is terminated by the customer or another party for reasons other than the entity’s failure to
perform as promised.

This second criterion associated with the right to payment was included to emphasize that when the
asset is highly customized and there is a right to payment for performance to date, the inclusion of
such payment terms serves to indicate that the economics of the transaction are consistent with other
performance obligations for which control is transferred over time. The reasoning behind this conclusion
is that (1) the right to payment is a protection mechanism for the entity for its efforts incurred over time
as it creates/enhances an asset or performs a service and (2) the customer is expected to receive some
level of benefit over time given the agreed-to terms that require payment before completion of the
asset/service.

54
 Chapter 4 — Revenue Recognition for Health Tech Companies

When the performance obligation is satisfied over time because one of the criteria in ASC 606-10-
25-27(a) through (c) is met, companies must measure their progress toward completion of this
obligation to align the timing of the transfer of control with the timing of the associated revenue
recognition. On this note, ASC 606-10-25-31 states that “[t]he objective when measuring progress is to
depict an entity’s performance in transferring control of goods or services promised to a customer (that
is, the satisfaction of an entity’s performance obligation).” ASC 606-10-25-32 then continues:

An entity shall apply a single method of measuring progress for each performance obligation satisfied over
time, and the entity shall apply that method consistently to similar performance obligations and in similar
circumstances. At the end of each reporting period, an entity shall remeasure its progress toward complete
satisfaction of a performance obligation satisfied over time.

ASC 606-10-25-33 indicates that appropriate methods for companies to use in measuring their progress
“include output methods and input methods.” Output methods (e.g., appraisals of performance to date,
milestones reached, time elapsed, and units produced/delivered) are related to the value received by
the customer over time, while input methods (e.g., resources consumed, labor hours expended, costs
incurred, or time elapsed) are related to the company’s efforts taken to date.

For example, a SaaS arrangement may require a health tech company to give its customer access
to software over a specified period in such a way that the number of days for which this access is
provided may be an appropriate output-based measure of progress. Similarly, stand-ready performance
obligations (see step 2 above), such as maintenance on software licenses, may be defined as occurring
over a distinct set of days in such a way that the passage of days is used as an output method to
measure progress and recognize revenue. Alternatively, companies may be able to reasonably estimate
the total number of hours for an implementation or other professional service and therefore may track
actual labor hours incurred against this total labor hour estimate to measure progress by using an input
method.

The FASB has not explicitly stated whether it prefers an input or output method and acknowledges in
paragraph BC164 of ASU 2014-09 that there are advantages and disadvantages to both. Therefore,
companies must determine which method most reasonably aligns with their particular facts and
circumstances to best reflect the transfer of control and the progress toward complete satisfaction of
the performance obligation.

4.1.5.2 Practical Expedient for Measuring Progress

While the measurement of progress for performance obligations satisfied over time may be complex,
ASC 606-10-55-18 states that “[a]s a practical expedient, if an entity has a right to consideration from
a customer in an amount that corresponds directly with the value to the customer of the entity’s
performance completed to date (for example, a service contract in which an entity bills a fixed amount
for each hour of service provided), the entity may recognize revenue in the amount to which the entity
has a right to invoice.”

Most commonly referred to as the “invoice practical expedient,” this option allows an entity to recognize
revenue in the amount of consideration that the entity has the right to invoice when this amount
corresponds directly to the value transferred to the customer. That is, the invoice practical expedient
cannot be applied in all circumstances because the right to invoice a certain amount does not always
correspond to the progress toward satisfying the performance obligation. Therefore, an entity should
demonstrate its ability to apply the invoice practical expedient to performance obligations satisfied over
time. Because the purpose of the invoice practical expedient is to faithfully depict an entity’s measure
of progress toward completion, the invoice practical expedient can only be applied to performance
obligations satisfied over time (not at a point in time).

55
Deloitte | Health Tech Industry Accounting Guide (2023)

For example, a telehealth company that prices its contracts on a per-visit basis and therefore is subject
to measurement requirements for variable consideration may, if the visits are determined to be a series
accounted for as a single performance obligation satisfied over time, also conclude that it can use the
invoice practical expedient if it can demonstrate that the value to the customer is commensurate with
the amount to be billed (for this example, assume that the company bills on a monthly basis). Other
factors that are important for an entity to consider in reaching this conclusion are the existence of
up-front or back-end fees (which may affect whether the amounts presently billed align with the value
received by the customer) or billing rates that may vary over the contract term and how those changes
may or may not correspond to the value received by the customer.

The entity will need to use judgment in determining whether the amount invoiced for goods or services
reasonably represents the value to the customer of the entity’s performance completed to date.

4.1.5.3 Revenue Recognized at a Point in Time

As mentioned above, ASC 606-10-25-30 stipulates that if none of the three criteria in ASC 606-10-
25-27(a) through (c) are met, the transfer of control and recognition of the associated revenue are at a
point in time. ASC 606-10-25-30 also lists the following indicators (not all-inclusive) of when a customer
obtains control at a specific point in time:
a. The entity has a present right to payment for the asset — If a customer presently is obliged to pay for
an asset, then that may indicate that the customer has obtained the ability to direct the use of, and
obtain substantially all of the remaining benefits from, the asset in exchange.
b. The customer has legal title to the asset — Legal title may indicate which party to a contract has the
ability to direct the use of, and obtain substantially all of the remaining benefits from, an asset or to
restrict the access of other entities to those benefits. Therefore, the transfer of legal title of an asset
may indicate that the customer has obtained control of the asset. If an entity retains legal title solely
as protection against the customer’s failure to pay, those rights of the entity would not preclude the
customer from obtaining control of an asset.
c. The entity has transferred physical possession of the asset — The customer’s physical possession of
an asset may indicate that the customer has the ability to direct the use of, and obtain substantially all
of the remaining benefits from, the asset or to restrict the access of other entities to those benefits.
However, physical possession may not coincide with control of an asset. For example, in some
repurchase agreements and in some consignment arrangements, a customer or consignee may have
physical possession of an asset that the entity controls. Conversely, in some bill-and-hold arrangements,
the entity may have physical possession of an asset that the customer controls. Paragraphs 606-10-
55-66 through 55-78, 606-10-55-79 through 55-80, and 606-10-55-81 through 55-84 provide guidance
on accounting for repurchase agreements, consignment arrangements, and bill-and-hold arrangements,
respectively.
d. The customer has the significant risks and rewards of ownership of the asset — The transfer of the
significant risks and rewards of ownership of an asset to the customer may indicate that the customer
has obtained the ability to direct the use of, and obtain substantially all of the remaining benefits
from, the asset. However, when evaluating the risks and rewards of ownership of a promised asset,
an entity shall exclude any risks that give rise to a separate performance obligation in addition to the
performance obligation to transfer the asset. For example, an entity may have transferred control of an
asset to a customer but not yet satisfied an additional performance obligation to provide maintenance
services related to the transferred asset.
e. The customer has accepted the asset — The customer’s acceptance of an asset may indicate that it has
obtained the ability to direct the use of, and obtain substantially all of the remaining benefits from, the
asset. To evaluate the effect of a contractual customer acceptance clause on when control of an asset is
transferred, an entity shall consider the guidance in paragraphs 606-10-55-85 through 55-88.

56
 Chapter 4 — Revenue Recognition for Health Tech Companies

The above list demonstrates that while a present right to payment is one of the indicators of the
transfer of control, it is not the sole indicator; companies therefore must evaluate the specific nature
of their contracts in accordance with this guidance to determine when control has been transferred.
Four of the five indicators above may occur before or after invoicing the customer; accordingly, in such
cases, revenue may need to be recognized at a point in time other than when the invoice is sent to the
customer.

Of note for health tech companies that may be delivering software, SaaS, telehealth visits, or any of the
other multitude of performance obligations within the expanding health tech market, contracts may
often allow for a period in which the customer tests or evaluates the good or service before deeming
such a deliverable as “accepted.” As stated in ASC 606-10-25-30(e), the guidance in ASC 606-10-55-85
through 55-88 would apply in such situations.

ASC 606-10

55-85 In accordance with paragraph 606-10-25-30(e), a customer’s acceptance of an asset may indicate that
the customer has obtained control of the asset. Customer acceptance clauses allow a customer to cancel
a contract or require an entity to take remedial action if a good or service does not meet agreed-upon
specifications. An entity should consider such clauses when evaluating when a customer obtains control of a
good or service.

55-86 If an entity can objectively determine that control of a good or service has been transferred to the
customer in accordance with the agreed-upon specifications in the contract, then customer acceptance is a
formality that would not affect the entity’s determination of when the customer has obtained control of the
good or service. For example, if the customer acceptance clause is based on meeting specified size and weight
characteristics, an entity would be able to determine whether those criteria have been met before receiving
confirmation of the customer’s acceptance. The entity’s experience with contracts for similar goods or services
may provide evidence that a good or service provided to the customer is in accordance with the agreed-
upon specifications in the contract. If revenue is recognized before customer acceptance, the entity still must
consider whether there are any remaining performance obligations (for example, installation of equipment) and
evaluate whether to account for them separately.

55-87 However, if an entity cannot objectively determine that the good or service provided to the customer is in
accordance with the agreed-upon specifications in the contract, then the entity would not be able to conclude
that the customer has obtained control until the entity receives the customer’s acceptance. That is because, in
that circumstance the entity cannot determine that the customer has the ability to direct the use of, and obtain
substantially all of the remaining benefits from, the good or service.

55-88 If an entity delivers products to a customer for trial or evaluation purposes and the customer is not
committed to pay any consideration until the trial period lapses, control of the product is not transferred to the
customer until either the customer accepts the product or the trial period lapses.

The significance of a customer acceptance clause in a health tech contract can vary. For example, some
health tech contracts may include a substantive customer acceptance clause in which it is clear (perhaps
even determinative) that without such acceptance, control of the asset has not been transferred to the
customer. In such cases, the customer may be allowed to (1) cancel the contract and the remaining
performance obligations and enforceable rights if a good or service does not have the agreed-upon
specifications or functionality, (2) delay the provision of consideration for the good or service, or
(3) otherwise request the entity to remedy the good or service until such specifications are achieved.
Transfer of control most likely has not occurred in this case until the customer has accepted the good or
service. An entity should evaluate the facts and circumstances of the arrangement in such situations.

57
Deloitte | Health Tech Industry Accounting Guide (2023)

The decision tree below illustrates the considerations relevant to customer acceptance provisions.

Does the customer

effectively have a Yes Wait for trial period to lapse or
trial period before it is formal acceptance to occur.
committed to pay?

No

Is customer Depending on the facts and

acceptance based on Subjective circumstances, either revenue should
subjective evaluation or not be recognized until acceptance
objective criteria? occurs or the customer acceptance
should be treated as a right of return.

Objective

The acceptance provisions should

Are the criteria Standard Has the ability to Yes be evaluated as a warranty
standard for the asset or meet the criteria been
(i.e., assurance-type or service-
unique to the contract? demonstrated?
type warranty).

Unique
No

Has compliance
Revenue should not be
with specifications No Acceptance provisions do not
recognized until acceptance
in an environment similar prohibit a conclusion that control
occurs or compliance is
to the customer’s been has transferred.
demonstrated.
demonstrated?

Yes

58
 Chapter 4 — Revenue Recognition for Health Tech Companies

4.1.6 Contract Modifications
Health tech companies may enter into long-term contracts with their customers. During the term of
these contracts, a health tech company may enter into a new agreement with its customers that may
modify the terms of the original agreement. Whenever a health tech company and its customer agree to
change what the entity promises to deliver (i.e., the contract’s scope) or the amount of consideration the
customer will pay (i.e., the contractual price), there is a contract modification. ASC 606-10-25-10 notes
that a contract modification exists if “the parties to a contract approve a modification that either creates
new or changes existing enforceable rights and obligations of the parties to the contract.” Consequently,
whenever the enforceable rights and obligations in a contract with a customer change, a contract
modification is present and the modification framework should be applied.

If a change in an entity’s contract with a customer qualifies as a contract modification, the entity must
assess the goods and services and their selling prices. Depending on whether those goods and services
are distinct or are sold at their SSPs, a modification can be accounted for as:

• A separate contract.
• One of the following (if the modification is not accounted for as a separate contract):
o A termination of the old contract and the creation of a new contract (with no adjustment to
the historical accounting).
o A cumulative catch-up adjustment to revenue under the original contract combined with the
modification.
o A combination of the two sub-bullet points above that faithfully reflects the economics of the
transaction.

These different treatments that might be required by a health tech company are outlined below.

4.1.6.1 Contract Modification Accounted for as a Separate Contract

When an entity determines that its contract has been modified, it should first determine whether the
modification should be accounted for as a separate contract. ASC 606-10-25-12 specifies that an entity
should account for a contract modification as a separate contract if both of the following criteria are
met:

• The modification adds distinct goods or services to the contract.

• The price of the contract increases by an amount equal to the SSPs of the additional distinct
goods or services.

When a health tech company accounts for a contract modification as a separate contract, the health
tech company’s accounting for the original contract is not affected by the modification. Any revenue
recognized through the date of the modification is not adjusted, and remaining performance obligations
will continue to be accounted for under the original contract. The new contract is accounted for
separately from the original contract on a prospective basis.

A contract modification that changes only the price of the contract (and not the contract’s scope) would
not be accounted for as a separate contract because the modification does not add distinct goods
or services to the contract. For example, a modification that only decreases the price a customer is
obligated to pay for goods or services to be transferred in the future would not be accounted for as a
separate contract.

59
Deloitte | Health Tech Industry Accounting Guide (2023)

4.1.6.2 Contract Modification Not Accounted for as a Separate Contract

If a contract modification does not meet the criteria in ASC 606-10-25-12 to be accounted for as a
separate contract, the accounting for the contract modification depends on whether the remaining
goods or services are distinct from the goods and services already transferred under the contract.
To meet this condition, the remaining goods or services do not need to be accounted for as a
performance obligation that is separate from the goods or services already delivered; the key factor
is whether the remaining goods or services are distinct. Therefore, if a contract contains a single
performance obligation that meets the criteria to be accounted for as a series under ASC 606-10-25-15,
a modification to the contract could qualify for prospective accounting treatment because each good or
service in the series is distinct.

4.1.6.3 Contract Modification Accounted for Prospectively

In accordance with ASC 606-10-25-13(a), if the remaining goods or services are distinct from the goods
or services already provided under the original arrangement, the health tech company would, in effect,
terminate the original contract and establish a “new” contract that includes only the remaining goods
or services. In this situation, the entity would allocate the following to the remaining performance
obligations in the contract:

• Consideration from the original contract that has not yet been recognized as revenue.
• Any additional consideration from the modification.
The health tech company would not typically reallocate consideration to goods or services that
were transferred to the customer before the modification (see Section 4.1.6.7). That is, the contract
modification is accounted for prospectively.

4.1.6.4 Contract Modification Accounted for on a Cumulative Catch-Up Basis

In contrast to the guidance in ASC 606-10-25-13(a) on prospective contract modifications, the guidance
in ASC 606-10-25-13(b) indicates that if the remaining promised goods and services at the time of the
contract modification are not distinct, the health tech company should account for the modification
as though any additional goods and services were an addition to an incomplete performance
obligation. This may be the case when the health tech company and its customer modify the terms of a
construction-type contract (for which revenue is recognized over time) as the construction progresses to
change certain requested features of the complex the entity is building for the customer and change the
price accordingly, though a price change is not necessary to be within the scope of ASC 606-10-25-13(b).
In this instance, the health tech company would update both the transaction price and the measure
of progress after considering the enforceable rights and obligations under the modified contract. As a
result of the modification, the health tech company would calculate an updated revenue amount on the
basis of the revised contract and record a cumulative catch-up adjustment to revenue.

4.1.6.5 Combination of Contract Modification Types

There may be modified contracts in which some performance obligations include remaining goods or
services that are distinct from the goods or services already provided under the original arrangement
but other performance obligations include remaining goods and services that are not (e.g., a change in
scope of a partially satisfied performance obligation). In those circumstances, it may be appropriate for a
health tech company to apply both the ASC 606-10-25-13(a) model and the ASC 606-10-25-13(b) model
to a single contract in the manner described in ASC 606-10-25-13(c).

60
 Chapter 4 — Revenue Recognition for Health Tech Companies

4.1.6.6 Accounting for Contract Assets as Part of a Contract Modification

ASC 606 requires recognition of a contract asset in certain circumstances, such as when a health tech
company has a contract with a customer for which revenue has been recognized (i.e., goods or services
have been transferred to the customer) but customer payment is contingent on something other than
the passage of time, such as the satisfaction of additional performance obligations. A contract asset
may exist at the time of a contract modification. Upon a contract modification, existing contract assets
should be carried forward to the new contract. That is, the contract assets should not be impaired or
reversed unless (1) their impairment or reversal is otherwise required by ASC 310 or (2) the customer
was provided with a price concession.

4.1.6.7 Contract Modifications Versus Price Concessions

While contract modifications often result in a change in the transaction price, not all changes in the
transaction price should be accounted for as a contract modification. This is because a contract
modification results in a change to enforceable rights and obligations in a contract.

Some changes in the transaction price may result from new information that confirms what could
be enforced under an existing contract. This could be case when a price concession is granted for
goods or services already delivered (even if the price concession is granted through a prospective
price adjustment). When determining whether a price concession should be accounted for as a
contract modification, a health tech company should consider whether the price concession is due
to (1) the resolution of variability that existed at contract inception or (2) a modification that changes
the parties’ rights and obligations after contract inception. This distinction is important because the
resolution of variability that existed at contract inception (even if not initially identified as a form of
variable consideration) is accounted for in accordance with ASC 606-10-32-43 and 32-44, whereas ASC
606-10-32-45 states that changes in the transaction price that are related to a contract modification are
accounted for in accordance with the contract modification guidance in ASC 606-10-25-10 through 25-13.

Price concessions may be provided solely as a result of current economic conditions. If such conditions
did not exist at contract inception (e.g., an unexpected economic downturn), a price concession most
likely represents a contract modification. However, if a health tech company’s customer has a valid
expectation that it could be entitled to a price concession (e.g., because of past business practices or
statements made by the health tech company), the health tech company should consider whether
a price concession ultimately granted should be accounted for as a change in the transaction price
(related to variability that existed at contract inception) rather than as a contract modification.
Accounting for the price concession as a contract modification would be appropriate if the price
concession resulted from a change to the enforceable rights and obligations in the contract. An entity
may need to use significant judgment in making this distinction.

4.2 Gross Versus Net Revenue Recognition

A health tech company may encounter challenges in determining whether to recognize revenue and
the associated cost of services as a gross amount or whether the revenue and cost should be recorded
net. In making this determination, the entity must assess whether it is acting as a principal or as an
agent. When a revenue transaction involves a third party in providing goods or services to a customer,
the entity must evaluate whether the nature of its promise to the customer is to provide the underlying
goods or services itself (i.e., the entity is the principal in the transaction) or to arrange for the third
party to provide the underlying goods or services directly to the customer (i.e., the entity is the agent
in the transaction). Examples of health tech companies that operate in environments in which third
parties may be involved include, but are not limited to, those that process claims on behalf of payors
or providers; transact prescriptions or other medical data between providers and pharmacies; or

61
Deloitte | Health Tech Industry Accounting Guide (2023)

transfer coupons or vouchers to patients on behalf of pharmaceutical manufacturers. To determine

the nature of its promise to the customer, the entity must first identify each specified good or service
that is distinct (or a bundle of goods or services that is distinct) to be provided to the customer and
then assess whether the entity obtains control of each specified good or service (or a right to a good or
service) before it is transferred to the customer. In arrangements involving more than one distinct good
or service, an entity could be a principal for certain aspects of a contract with a customer and an agent
for others.

When an entity controls the specified good or service before it is transferred to the customer, the
entity is acting as a principal and recognizes revenue on a gross basis. If the entity does not control the
specified good or service before it is transferred to the customer, the nature of the entity’s promise is
to arrange for another party to provide the specified good or service to the customer and the entity is
acting as an agent and must recognize revenue on a net basis.

The meaning of “control” under the principal-versus-agent guidance is consistent with its meaning
under ASC 606-10-25-25. Therefore, an entity controls a specified good or service if it has the ability to
direct (or prevent another party from directing) the use of, and obtain substantially all of the remaining
benefits from, the specified good or service. ASC 606-10-25-25 notes that there are many ways in which
an entity can directly or indirectly obtain benefits (i.e., potential cash inflows or savings in cash outflows)
from an asset (i.e., a good or service), including the following:

• “Using the asset to produce goods or provide services (including public services).”
• “Using the asset to enhance the value of other assets.”
• “Using the asset to settle liabilities or reduce expenses.”
• “Selling or exchanging the asset.”
• “Pledging the asset to secure a loan.”
• “Holding the asset.”
There are three indicators codified in ASC 606-10-55-39 that an entity can use to support its conclusion
that the entity does or does not obtain control of the specified good or service before control is
transferred to a customer:

• “The entity is primarily responsible for fulfilling the promise to provide the specified good or service”
to the customer (including responsibility for determining whether a third party’s good or service
is acceptable) — The entity that has primary responsibility for fulfilling the obligation to the
customer is often the entity that is most visible to the customer and the entity from which
the customer believes it is acquiring goods or services. Often, the entity that has primary
responsibility for fulfilling the promise to transfer goods or services to the customer will assume
fulfillment risk (i.e., risk that the performance obligation will not be satisfied) and risks related
to the acceptability of specified goods or services. That is, such an entity will typically address
customer complaints, rectify service issues, and be primarily responsible for exchanges or
refunds.

• “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 (for example, if the customer has a right of return)” —
Although holding inventory is not typically relevant to health tech companies, inventory as
described herein can be related to both goods and services. When an entity has inventory risk,
it is exposed to economic risk associated with either (1) holding the inventory before a customer
is identified or (2) accepting product returns and being required to mitigate any resulting losses
by reselling the product or negotiating returns with the vendor. While holding the inventory,

62
 Chapter 4 — Revenue Recognition for Health Tech Companies

the entity bears the risk of loss as a result of obsolescence or destruction of inventory. This
risk is generally referred to as front-end inventory risk. In the case of a service, the entity may
commit to pay for a service before it identifies a customer for the service, which is also a form of
inventory risk. Another type of inventory risk is back-end inventory risk, which is economic risk
assumed upon product return (when there is a general right of return). If an entity is willing to
assume economic risk upon product return (and there is a general right of return), it is assuming
some risk that is typically borne by a principal in a transaction.

• “The entity has discretion in establishing the price for the specified good or service,” which may
indicate that it has “the ability to direct the use of that good or service and obtain substantially all
of the remaining benefits” — When an entity has control over the establishment of pricing, it
generally assumes substantial risks and rewards related to the demand of the specified product
or service, especially when the price it is required to pay a third party for the specified good or
service is fixed. While this indicator is helpful, the FASB cautioned that an agent may also have
discretion in setting prices (e.g., “to generate additional revenue from its service of arranging for
goods or services to be provided by other parties to customers”).

While these indicators are intended to help an entity determine whether it is acting as a principal or
as an agent, in accordance with ASU 2016-08, they “do not override the assessment of control, should
not be viewed in isolation, do not constitute a separate or additional evaluation, and should not be
considered a checklist of criteria to be met in all scenarios.” Further, no one indicator is weighted more
heavily than any other, and no indicator is considered to be individually determinative of whether an
entity controls a specified good or service before it is transferred to a customer. An entity should use
judgment to determine which indicators are more relevant depending on the facts and circumstances of
the specific transaction.

4.3 U.S. Federal Income Tax Considerations

Under the general rules for revenue recognition, an accrual method taxpayer must recognize revenue
when all events have occurred that fix the taxpayer’s right to revenue and the amount of the revenue
can be determined with reasonable accuracy. Accordingly, revenue is typically recognized at the earliest
of when that revenue is earned, due, or received. In addition, an accrual method taxpayer generally
may not recognize revenue any later than when it is recognized as revenue in its applicable financial
statements (i.e., generally audited financial statements based on GAAP or IFRS® Accounting Standards).

Taxpayers have the option of deferring the recognition of certain advance payments. Under this option,
a taxpayer recognizes revenue in the year the payment is received, to the extent that this amount is
recognized in revenue in its financial statements, and recognizes any unrecognized amounts in the
tax year after the year in which the payment is received. There are exceptions and special rules that
may shorten or lengthen the deferral period. Because taxpayers are only permitted to defer up-front
payments to the next taxable year after receipt, there may be a book/tax difference in cases in which
a taxpayer defers the recognition of up-front payments for financial statement purposes into revenue
over a period longer than one year.

63
Deloitte | Health Tech Industry Accounting Guide (2023)

4.4 Considerations Related to Accounting for Income Taxes

ASC 740-10-25-19 acknowledges that “because tax laws and financial accounting standards differ in
their recognition and measurement of assets, liabilities, equity, revenues, expenses, gains, and losses,
differences arise between:
a. The amount of taxable income and pretax financial income for a year.
b. The tax bases of assets or liabilities and their reported amounts in financial statements.”

Because of the potential differences in timing of recognition of revenue, deferred taxes may result. For
more information, see Chapter 3 of Deloitte’s Roadmap Income Taxes.

4.5 Applying the Revenue Standard to Identify the Performance Obligations

in Arrangements That Include Smart Devices, Updates, and Cloud-Based
Services
Many health tech entities offer solutions in which a customer purchases (1) a smart device with an
embedded software component (e.g., firmware), (2) maintenance and support (i.e., PCS), and (3) a cloud-
based service. In these offerings, the firmware allows the smart device to connect to the cloud-based
application, which is physically hosted on the health tech entity’s systems (or hosted by the entity’s
cloud computing vendor) and accessed by the customer over the Internet. For arrangements in which
the software is always embedded in the smart device and the software is essential to the device’s
core functionality, an entity will typically conclude that the embedded software is not distinct from the
smart device. This is because the software is a component of the tangible device and integral to the
functionality of that device in accordance with ASC 606-10-55-56(a).

Connecting the Dots

At the 2021 AICPA & CIMA Conference on Current SEC and PCAOB Developments, OCA
Senior Associate Chief Accountant Jonathan Wiggins noted that complex consultations on the
identification of performance obligations have included fact patterns in which an entity promises
to provide (1) a good or service up front, such as a software license or a “smart” device, and (2) a
related service over time, such as PCS for the software license or a cloud-based service for the
smart device. This topic was also addressed by then OCA Professional Accounting Fellow Sheri
York in her speech at the 2018 AICPA Conference on Current SEC and PCAOB Developments.
In that speech, Ms. York discussed a consultation with an SEC registrant regarding the
identification of performance obligations with respect to a commercial security monitoring
service. The registrant’s technology platform incorporated an element of AI to create a “smart”
security monitoring service. As Ms. York observed, the registrant concluded that the promises
in the contract were not distinct within the context of the contract because it “believed it was
providing a significant service of integrating the goods and services in the contract into a bundle
that represented the combined output for which the customer had contracted.” Ms. York noted
that the SEC staff did not object to the registrant’s conclusion.

The functionality of smart devices and subscription services (e.g., PCS and cloud-based services) can
vary between offerings to customers and between entities. When identifying performance obligations in
these arrangements, an entity should consider the guidance in ASC 606-10-25-19 to determine whether
the smart device and the subscription services are distinct (i.e., whether each promise is capable
of being distinct and distinct within the context of the contract). While a smart device and related
subscription services are each often capable of being distinct, determining whether they are distinct
within the context of the contract is much more challenging. An entity should consider the guidance in
ASC 606-10-25-21 in making such a determination.

64
 Chapter 4 — Revenue Recognition for Health Tech Companies

We believe that an entity may consider the following indicators, which are not individually determinative
or all-inclusive, in determining whether its smart device is distinct from its subscription services:

• Whether the entity’s smart device and subscription services are ever sold separately — The entity’s
practice of selling the smart device and the subscription services separately typically indicates
that there are two separate performance obligations (i.e., the promises should not be combined)
since the customer may benefit from the smart device or the subscription services offering
on its own. In addition, separate sales also suggest that the smart device and the subscription
services each have significant stand-alone functionality, which indicates that those items are
distinct within the context of the contract.

• Whether the customer can benefit from each product or service (i.e., the smart device or the
subscription services) either on its own or together with other resources that are readily available
to the customer — For example, suppose that the customer has the ability to (1) obtain from a
different vendor a smart device or subscription services offering that is the same as or similar to
that sold by the entity, (2) use the alternative vendor’s smart device with the entity’s subscription
services (or use the alternative vendor’s subscription services with the entity’s smart device), and
(3) receive substantially the same functionality as that of the entity’s combined offering. That
ability may indicate that the entity’s smart device and subscription services are each capable
of being distinct and are distinct within the context of the contract since (1) the entity is not
providing a significant integration service for the device and the subscription services and (2) it
is less likely that the smart device and the subscription services are highly interdependent or
highly interrelated.
Alternatively, suppose that the functionality of the smart device is significantly integrated with
(rather than just improved by) the subscription services in such a way that the entity’s combined
offering provides significant additional capabilities that cannot be obtained from an alternative
vendor providing the subscription services. In that case, the presence of an alternative vendor
providing a portion of the same utility with its subscription services would indicate that the
promises are capable of being distinct, but the integrated nature of the promises would indicate
that the promises are not distinct within the context of the contract.

• Whether the subscription services significantly modify the smart device — The subscription services
and the smart device may not be distinct within the context of the contract if rather than just
enhancing the capabilities of the smart device, the subscription services modify and significantly
affect the functionality of the smart device. For example, suppose that the subscription services
(1) employ AI or machine learning that teaches and significantly affects the functionality of the
smart device and (2) cannot employ the AI or machine learning without using the functionality
of the smart device. This situation would indicate that the subscription services and the smart
device are not distinct within the context of the contract because rather than just enhancing
the capabilities of the smart device, the subscription services modify and significantly affect the
functionality of the smart device.

• Whether the absence of either the smart device or the subscription services significantly limits or
diminishes the utility (i.e., the ability to provide benefit or value) of the other — If the smart device’s
functionality is significantly limited or diminished without the use of the subscription services,
and vice versa, that significantly limited or diminished functionality may indicate that the smart
device and the subscription services (1) are highly interdependent or highly interrelated (i.e.,
they significantly affect each other) and (2) function together as inputs to a combined output.
This, in turn, may indicate that the promises are not distinct within the context of the contract
since the customer cannot obtain the intended benefit of the smart device or the subscription
services without the other. That is, while the customer may be able to obtain some functionality

65
Deloitte | Health Tech Industry Accounting Guide (2023)

from the smart device on a stand-alone basis, it would not obtain the intended outputs from
the smart device if the smart device is not updated by or connected to the subscription services
because the subscription services are critical to the customer’s intended use of the combined
solution. In this situation, the entity cannot fulfill its promise to the customer by transferring the
smart device or the subscription services independently (i.e., the customer could not choose
to purchase one good or service without significantly affecting the other good or service in the
contract).

• Whether the functionality of the combined smart device and subscription services is transformative
rather than additive — Transformative functionality should be assessed separately from added
functionality. Transformative functionality comprises features that significantly affect the overall
operation and interaction of the smart device and the subscription services (e.g., integrated
data analytics, pushdown learning, customization). To be transformative, the smart device and
the subscription services must significantly affect each other. That is, the smart device and
the subscription services are inputs to a combined output such that the combined output
has greater value than, or is substantively different from, the sum of the inputs. By contrast,
added functionality comprises features that provide an added benefit to the customer without
substantively altering (1) the manner in which the functionality is used and (2) the benefits
derived from that functionality of the smart device or the subscription services on a stand-
alone basis. Even if the added functionality is significant, it may not be transformative. It is more
likely that the smart device and the subscription services are highly interdependent or highly
interrelated when the functionality of the combined offering is transformative rather than
additive.

• Whether the entity’s smart devices and subscription services are always sold on a one-to-one basis —
If the entity has a practice of selling smart devices without the subscription services, this may
indicate that the customer can obtain its intended benefit from the smart devices separately. For
example, if a customer purchases the entity’s subscription services and 10 devices and has an
option to subsequently purchase additional devices without additional subscription services, the
entity is able to fulfill any promise to provide additional devices without any related subscription
services. If the entity is able to fulfill its promise to provide a smart device independently from
its promise to provide subscription services, the smart device and the subscription services may
not be highly interdependent or highly interrelated. By contrast, if a customer is always required
to purchase additional subscription services for each smart device purchased, this may indicate
that the smart device and the subscription services are not distinct.

• Whether the smart devices are sold on a stand-alone basis through a distribution channel or in an
aftermarket — If the entity’s smart devices are sold on a stand-alone basis by other third parties
and the entity will sell its subscription services separately to any customer that has purchased
or obtained a smart device from a third party, the entity is able to fulfill its promise to provide
subscription services independently from any promise to provide smart devices. This indicates
that the smart device and the subscription services are not highly interdependent or highly
interrelated. By contrast, if the entity will not sell its subscription services to a customer unless
the customer has purchased a smart device directly from the entity, this may indicate that the
smart device and the subscription services are not distinct.

• Whether the entity’s marketing materials support a conclusion that the arrangement is for a combined
solution rather than separate products or service offerings — The entity’s marketing materials
may help clarify what the entity has promised to deliver to its customer and may provide
evidence of the customer’s intended use of the smart device and the subscription services.
Circumstances in which an entity markets its product as a “solution” (i.e., the materials discuss

66
 Chapter 4 — Revenue Recognition for Health Tech Companies

the functions, features, and benefits of the combined offering with little or no discussion of the
smart device and the subscription services separately) may help support a conclusion that the
entity’s promise is a combined performance obligation. However, the entity should exercise
caution when relying on its marketing materials since the manner in which the entity markets
its combined offering would not, by itself, be sufficient to support a conclusion that the smart
device and the subscription services represent a combined performance obligation.

Challenges arise when health tech companies need to identify performance obligations in arrangements
that include promises to provide (1) hardware and embedded software (i.e., a smart device), (2) PCS,
and (3) a cloud-based service. There are additional considerations when an entity leases the smart
device with the related PCS and cloud-based service instead of selling it. The interpretive guidance
below addresses factors that an entity may consider in identifying the performance obligations in these
arrangements and discusses situations in which a smart device is subject to a lease accounted for under
ASC 842 (it is assumed that the entity has already adopted ASC 842).

Because PCS and a cloud-based service typically are sold together, are coterminous, and have the same
pattern of transfer to a health tech customer (i.e., ratably over time as stand-ready obligations), they will
be referred to collectively as “subscription services.” When control of two or more goods or services,
such as customer support and a cloud-based service, is transferred at exactly the same time, or on the
same basis over the same period, and if those items do not need to be segregated for presentation or
disclosure purposes, it will usually not be necessary to unbundle each of those concurrently delivered
performance obligations because the amount and timing of revenue recognized and disclosed would
not differ if the items were unbundled. The FASB acknowledges this in paragraph BC116 of ASU 2014-09
and paragraph BC47 of ASU 2016-10. In some cases, the smart device and both the PCS and the cloud-
based service may constitute a combined performance obligation. However, there may be instances in
which the smart device and either the PCS (without the cloud-based service) or the cloud-based service
(without the PCS) constitute a combined performance obligation.

The functionality of smart devices and subscription services can vary between offerings to customers
and between entities. When identifying performance obligations in these arrangements, a health tech
company should consider the guidance in ASC 606-10-25-19 to determine whether the smart device
and the subscription services are distinct (i.e., whether each promise is capable of being distinct and
distinct within the context of the contract). While a smart device and related subscription services are
each often capable of being distinct, determining whether they are distinct within the context of the
contract is much more challenging. See Section 4.1.2.1 for further discussion of the determination of
whether a performance obligation is distinct in the context of a contract.

Example 55 below illustrates circumstances in which promised goods or services are not distinct from
one another. While this example may not specifically apply to health tech companies, it is relevant to the
appropriate application of this guidance.

ASC 606-10

Example 55 — License of Intellectual Property

55-364 An entity enters into a contract with a customer to license (for a period of three years) intellectual
property related to the design and production processes for a good. The contract also specifies that the
customer will obtain any updates to that intellectual property for new designs or production processes that
may be developed by the entity. The updates are integral to the customer’s ability to derive benefit from the
license during the license period because the intellectual property is used in an industry in which technologies
change rapidly.

67
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 606-10 (continued)

55-365 The entity assesses the goods and services promised to the customer to determine which goods and
services are distinct in accordance with paragraph 606-10-25-19. The entity determines that the customer
can benefit from (a) the license on its own without the updates and (b) the updates together with the initial
license. Although the benefit the customer can derive from the license on its own (that is, without the updates)
is limited because the updates are integral to the customer’s ability to continue to use the intellectual property
in an industry in which technologies change rapidly, the license can be used in a way that generates some
economic benefits. Therefore, the criterion in paragraph 606-10-25-19(a) is met for the license and the
updates.

55-365A The fact that the benefit the customer can derive from the license on its own (that is, without the
updates) is limited (because the updates are integral to the customer’s ability to continue to use the license
in the rapidly changing technological environment) also is considered in assessing whether the criterion in
paragraph 606-10-25-19(b) is met. Because the benefit that the customer could obtain from the license over
the three-year term without the updates would be significantly limited, the entity’s promises to grant the license
and to provide the expected updates are, in effect, inputs that, together fulfill a single promise to deliver a
combined item to the customer. That is, the nature of the entity’s promise in the contract is to provide ongoing
access to the entity’s intellectual property related to the design and production processes for a good for the
three-year term of the contract. The promises within that combined item (that is, to grant the license and to
provide when-and-if available updates) are therefore not separately identifiable in accordance with the criterion
in paragraph 606-10-25-19(b).

55-366 The nature of the combined good or service that the entity promised to transfer to the customer
is ongoing access to the entity’s intellectual property related to the design and production processes for a
good for the three-year term of the contract. Based on this conclusion, the entity applies paragraphs 606-10-
25-23 through 25-30 to determine whether the single performance obligation is satisfied at a point in time or
over time and paragraphs 606-10-25-31 through 25-37 to determine the appropriate method for measuring
progress toward complete satisfaction of the performance obligation. The entity concludes that because the
customer simultaneously receives and consumes the benefits of the entity’s performance as it occurs, the
performance obligation is satisfied over time in accordance with paragraph 606-10-25-27(a) and that a time-
based input measure of progress is appropriate because the entity expects, on the basis of its relevant history
with similar contracts, to expend efforts to develop and transfer updates to the customer on a generally even
basis throughout the three-year term.

In addition, Example 9-2-3 in the AICPA Audit and Accounting Guide Revenue Recognition states, in part:

Many hybrid offerings will enable customers to perform some functions with the on-premise software even
when they are not connected to the hosting service. An entity may determine that the on-premise software
meets the criteria of FASB ASC 985-20-15-5 and is capable of being distinct. However, even when the software
license is within the scope of FASB ASC 606-10-55-54a and is capable of being distinct, it may not be distinct
in the context of the contract because it is, for example, highly interdependent or interrelated with the hosting
service. In making this determination, the entity may consider indicators such as the following:
a. Hosted functionality is limited to capabilities that are widely available from other vendors. For example,
the entity offers online file storage and sharing with minimal integration to the on-premise software
workflow. In such cases, a customer could gain substantially all of the benefits included in the offering
by utilizing alternative vendor services. This would indicate that the software license likely is both
capable of being distinct from the hosted service and distinct within the context of the contract because
the entity is not providing unique and additional value from the integration of the software and the file
storage.
b. A portion of the hosted functionality is available from other vendors, but the entity provides significant
additional utility from the manner in which it integrates the software with its own hosted functionality.
For example, the online storage and sharing is integrated with the on-premise software in such a
manner that the customer gains significant capabilities or workflow efficiencies that would not be
available when using another vendor’s hosted services. In such circumstances, the on-premise software
is capable of being distinct, but the customer obtains a significant functional benefit by purchasing the
complete hybrid offering from the entity. This may indicate that the software license and hosting service
are highly interrelated to each other and are not distinct within the context of the contract.

68
 Chapter 4 — Revenue Recognition for Health Tech Companies

c. Hosted functionality is limited to functions that the customer may also perform locally with the
on-premise software. For example, the customer has the option to perform computationally intensive
tasks on its own computer or upload them to the entity’s servers as part of the hosting service. In such
circumstances, the customer can obtain the intended benefit of the offering with only the on-premise
software. This may indicate that the software is not highly dependent on or interrelated with the hosting
service and is therefore distinct within the context of the contract.
d. The hybrid offering workflow involves ongoing interactions between the on-premise software and
hosted services. As a result, the utility of the offering would be significantly diminished if the customer
is not connected to the hosting service. For example, the utility of the offering would be significantly
diminished if the customer is unable to perform computationally intensive tasks when not connected to
the hosting services. In such circumstances, the software and hosted services are highly interdependent
or interrelated because (1) the customer gains significant functionality from the software and hosting
services functioning together and (2) the entity fulfills its overall promise to the customer only by both
transferring the on-premise license and providing the hosting services. This would indicate that the
software is not distinct within the context of the contract.

4.6 Cloud Conversion or Switching Rights

As discussed in Chapter 3 of this guide, a health tech company must use judgment in determining the
appropriate model to use in accounting for the capitalized software costs it incurs. Some software is
internally developed or modified solely to meet the company’s needs, while other software is marketed
and sold to the company’s customers. In addition, some health tech companies may develop software
that is sold both as a licensed product (on-premise license) and as a hosted solution (e.g., SaaS).
Further, some health tech companies enter into contracts that include (or are subsequently modified
to include) an option that allows the customer to convert from an on-premise license arrangement to a
cloud-based arrangement under which the software is hosted (e.g., SaaS). This issue has become more
prevalent because customers of health tech companies and other software entities frequently migrate
from on-premise software solutions to cloud-based platforms. Often, when a customer converts from
an on-premise software arrangement to a SaaS arrangement, the customer will lose or forfeit its rights
to the on-premise version of the software. Views differ on how to account for the revocation of the initial
licensing rights and the conversion to a hosted solution.

From inception or after modification, a health tech company’s software arrangement may include a
feature that allows a customer to convert a nonexclusive on-premise term-based software license
to a cloud-based or hosted software solution (e.g., a SaaS arrangement) for the same software (i.e.,
software with the same functionality and features). A health tech entity may also modify a nonexclusive
on-premise term-based software arrangement to immediately convert it to a SaaS arrangement. Further,
an entity’s software arrangement may allow a customer to (1) deploy a certain number of licenses to
software (e.g., 1,000 seats) and (2) use discretion to determine how many licenses to deploy on an
on-premise basis or as SaaS at any point in time or at discrete points in time during the arrangement
term. Cloud conversion or switching rights vary widely in practice, and the determination of the
appropriate accounting for an arrangement that provides for such rights will depend on the particular
complexities involved.

In accordance with the guidance in ASC 606 as well as that in Section 4.1.5 of this guide (where the
appropriate pattern of revenue recognition is discussed), revenue from on-premise software licenses is
typically recognized at the point in time when both (1) the entity provides (or otherwise makes available)
a copy of the software to the customer and (2) the period in which the customer is able to use and
benefit from the license has begun. Revenue from a SaaS arrangement is typically recognized over time
because the performance obligation is likely to meet the conditions for such recognition, particularly
if the SaaS is a stand-ready obligation. SaaS arrangements typically qualify to be treated as a series
(see Section 4.1.2) and thus are recognized over time, as discussed in Section 4.1.5. While ASC 606
includes guidance on contract modifications, material rights, and sales with a right of return, it does
not directly address transactions in which a nonexclusive software license is revoked or converted to a

69
Deloitte | Health Tech Industry Accounting Guide (2023)

SaaS arrangement. Views therefore differ on the accounting for such arrangements, particularly those
in which a nonexclusive on-premise software license for which revenue is recognized at a point in time
is converted to a SaaS arrangement for the same underlying software product for which revenue is
recognized over time.

In the absence of additional standard setting, there could be more than one acceptable accounting
model for certain types of cloud conversion or switching arrangements. The sections below contain
examples illustrating such arrangements and discuss views on how entities may account for them.
However, neither the examples nor the views discussed are all-inclusive, and entities should carefully
consider their specific facts and circumstances in determining the appropriate accounting model.

4.6.1 Initial Contract Includes a Cloud Conversion Right

The example below illustrates an initial nonexclusive on-premise term-based software license contract
that includes the right to convert the on-premise software license to a SaaS arrangement.

Example 4-2

On January 1, 20X0, Entity A enters into a noncancelable two-year contract with a customer for an up-front fee
of $1 million to provide a nonexclusive on-premise software license with maintenance or PCS for 100 seats and
a right to convert any of the on-premise license seats to a SaaS arrangement at the beginning of the second
year (i.e., January 1, 20X1). The SaaS has the same functionality and features as the on-premise software but
would be hosted by A instead of being provided on an on-premise basis. Upon exercise of the conversion
right, the customer would be required to forfeit the on-premise software license seats and related PCS, and
the conversion is irrevocable (i.e., the customer cannot convert back to an on-premise software license). Upon
conversion, the customer would be required to pay an incremental fee of $500 per seat and would receive a
credit for a pro rata portion of the “unused” on-premise software license and related PCS to apply to the price
the customer would pay for the SaaS.

Entity A has similar arrangements with other customers and expects the customer to convert 50 seats at the
beginning of the second year. The SSPs are as follows:

Performance Obligation SSP

On-premise software license $4,000 per seat per year

PCS $1,000 per seat per year

SaaS $5,500 per seat per year

4.6.1.1 Alternative 1A — Material Right Model (Preferred View)

Under this alternative, an entity should determine whether the conversion right represents a material
right. ASC 606-10-55-42 through 55-44 state the following:

ASC 606-10

55-42 If, in a contract, an entity grants a customer the option to acquire additional goods or services, that
option gives rise to a performance obligation in the contract only if the option provides a material right to
the customer that it would not receive without entering into that contract (for example, a discount that is
incremental to the range of discounts typically given for those goods or services to that class of customer in
that geographical area or market). If the option provides a material right to the customer, the customer in effect
pays the entity in advance for future goods or services, and the entity recognizes revenue when those future
goods or services are transferred or when the option expires.

70
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10 (continued)

55-43 If a customer has the option to acquire an additional good or service at a price that would reflect the
standalone selling price for that good or service, that option does not provide the customer with a material
right even if the option can be exercised only by entering into a previous contract. In those cases, the entity has
made a marketing offer that it should account for in accordance with the guidance in this Topic only when the
customer exercises the option to purchase the additional goods or services.

55-44 Paragraph 606-10-32-29 requires an entity to allocate the transaction price to performance obligations
on a relative standalone selling price basis. If the standalone selling price for a customer’s option to acquire
additional goods or services is not directly observable, an entity should estimate it. That estimate should reflect
the discount that the customer would obtain when exercising the option, adjusted for both of the following:
a. Any discount that the customer could receive without exercising the option
b. The likelihood that the option will be exercised.

Under the material right guidance, a health tech company provides a material right if its customer has
the option of purchasing the SaaS at a discount that is incremental to the range of discounts typically
provided for the SaaS to that class of customer in similar circumstances. Any incremental fee the
customer is required to pay to exercise the conversion right is compared with the SSP of the SaaS. (See
Section 4.1.4 for further discussion of the determination of a performance obligation’s SSP.) While the
customer may receive a credit for the “unused” portion of the on-premise term-based software license
and related PCS, only the incremental fee to exercise the right is considered. This is because under
Alternative 1A, a nonexclusive on-premise term-based software license is not subject to the right-of-
return guidance since the entity does not receive an asset back when the right is exercised (i.e., there is
no return of an asset). This alternative view is consistent with the accounting for on-premise term-based
software licenses that enable the customer to terminate the license agreement without penalty. For
example, if a customer paid for a one-year on-premise term-based software license but had the ability
to cancel the arrangement for a pro rata refund with 30 days’ notice, the term of the initial arrangement
would be 30 days, with optional renewals thereafter. In those circumstances, the right-of-return
guidance would not be applied. Specifically, the health tech company is not compensated with an asset
of any value as a result of the conversion since it can replicate a nonexclusive software license for sale
to any of its customers for a nominal cost. If the incremental fee that the customer is required to pay
to convert to the SaaS reflects the SSP of the SaaS, no material right exists under ASC 606-10-55-43, as
discussed above. Instead, the conversion right is accounted for only if and when it is exercised.

On the other hand, if the conversion right represents a material right because the incremental fee is
less than the SSP of the SaaS, that material right would be accounted for as a separate performance
obligation. In accordance with ASC 606-10-55-44, as discussed above, the health tech company would
estimate the SSP of the material right as the discount the customer would obtain when exercising
the material right, adjusted for any discount the customer could receive without exercising the option
and the likelihood that the option will be exercised. If the conversion option is exercised, the amount
allocated to the material right plus any incremental fee paid would generally be recognized over the
remaining term of the SaaS (and the PCS if not all licenses are converted).

In Example 4-2, Entity A would need to assess whether the option to receive the SaaS at a discount
represents a material right in line with the guidance outlined above. Because the incremental fee to be
paid by the customer of $500 per seat per year is significantly less than the SSP for the SaaS of $5,500
per seat per year, A would conclude that a material right exists at contract inception. Entity A could
estimate the material right’s SSP as the $5,000 per seat per year discount ($5,500 SaaS SSP − $500
incremental fee to be paid), adjusted for the likelihood that the option will be exercised. It would also
be acceptable for A to estimate the SSPs of the on-premise software license and the PCS by applying

71
Deloitte | Health Tech Industry Accounting Guide (2023)

a similar adjustment for the likelihood that the option will be exercised (which could truncate the
term of the on-premise software license and the PCS). For example, A might estimate the SSPs of the
on-premise software license and the PCS under the assumption that 50 seats of the license and related
PCS will have only a one-year term if customers are expected to convert half the seats of the license
to SaaS after one year. While the material right’s SSP could be adjusted for any discount the customer
could receive without exercising the option, in this example it is assumed that the customer could not
receive a discount without exercising the option.

Assume that A determines that the relative SSP allocation of the transaction price results in allocations
to the on-premise software license, PCS for 20X0, PCS for 20X1, and the material right of $600,000,
$100,000, $50,000, and $250,000, respectively. This pattern of allocation is purely for illustrative
purposes. Entity A will recognize $600,000 of revenue on January 1, 20X0, for the on-premise software
license and $100,000 for PCS ratably over 20X0. Revenue is deferred for the $50,000 allocated to PCS
for 20X1 and the $250,000 allocated to the material right, and those amounts are recognized as contract
liabilities. If the customer elects to exercise the conversion right on 100 seats on January 1, 20X1, A
would assess its policy for accounting for the exercise of an option that includes a material right and
apply either of the following approaches:

• Separate contract model — The remaining unrecognized revenue of $50,000 related to PCS is
recognized immediately since PCS for all 100 seats is forfeited and therefore will not be provided
in 20X1. Revenue of $300,000, which is calculated by adding the material right allocation of
$250,000 and the incremental fee of $50,000 ($500 incremental fee × 100 seats), is recognized
over the remaining one-year SaaS term.

• Contract modification model — Revenue of $350,000, which is calculated by adding the remaining
unrecognized revenue of $50,000 related to PCS, the material right allocation of $250,000, and
the incremental fee of $50,000, is recognized over the remaining one-year SaaS term.

Alternative 1A may be less costly to implement than Alternative 1B (discussed below) because the
SSP of the material right is estimated only at contract inception and is not subsequently revised. In
addition, because the right-of-return model is not applied, the variable consideration constraint would
likewise not be applicable. (See Section 4.1.3.1 for more information about the variable consideration
constraint.) Therefore, revenue recognition could potentially be less volatile under the material right
model than under the right-of-return model discussed below.

4.6.1.2 Alternative 1B — Right-of-Return Model (Acceptable View)

Under this alternative, a health tech company applies the right-of-return guidance when accounting for
the potential that a nonexclusive on-premise term-based software license will be converted to a SaaS
arrangement. ASC 606-10-55-22 through 55-26 state the following:

ASC 606-10

55-22 In some contracts, an entity transfers control of a product to a customer and also grants the customer
the right to return the product for various reasons (such as dissatisfaction with the product) and receive any
combination of the following:
a. A full or partial refund of any consideration paid
b. A credit that can be applied against amounts owed, or that will be owed, to the entity
c. Another product in exchange.

72
 Chapter 4 — Revenue Recognition for Health Tech Companies

ASC 606-10 (continued)

55-23 To account for the transfer of products with a right of return (and for some services that are provided
subject to a refund), an entity should recognize all of the following:
a. Revenue for the transferred products in the amount of consideration to which the entity expects to be
entitled (therefore, revenue would not be recognized for the products expected to be returned)
b. A refund liability
c. An asset (and corresponding adjustment to cost of sales) for its right to recover products from
customers on settling the refund liability.

55-24 An entity’s promise to stand ready to accept a returned product during the return period should not be
accounted for as a performance obligation in addition to the obligation to provide a refund.

55-25 An entity should apply the guidance in paragraphs 606-10-32-2 through 32-27 (including the guidance
on constraining estimates of variable consideration in paragraphs 606-10-32-11 through 32-13) to determine
the amount of consideration to which the entity expects to be entitled (that is, excluding the products expected
to be returned). For any amounts received (or receivable) for which an entity does not expect to be entitled,
the entity should not recognize revenue when it transfers products to customers but should recognize those
amounts received (or receivable) as a refund liability. Subsequently, at the end of each reporting period,
the entity should update its assessment of amounts for which it expects to be entitled in exchange for the
transferred products and make a corresponding change to the transaction price and, therefore, in the amount
of revenue recognized.

55-26 An entity should update the measurement of the refund liability at the end of each reporting period for
changes in expectations about the amount of refunds. An entity should recognize corresponding adjustments
as revenue (or reductions of revenue).

Under Alternative 1B, an on-premise software license is generally treated as a tangible product, and
the right-of-return guidance applies to the exchange of a product for another product in accordance
with ASC 606-10-55-22(c), as outlined above. However, while an entity would generally record an asset
for its right to recover a tangible product, an entity would not record an asset for its right to recover
a nonexclusive software license in accordance with ASC 606-10-55-23(c) above, since the returned
license has no value to the entity. Therefore, in applying the right-of-return guidance, the health tech
company would estimate and recognize an adjustment to the transaction price (and reduce revenue)
at contract inception to account for the potential conversion. The right of return would be accounted
for as variable consideration, subject to the constraint in ASC 606-10-32-11 and 32-12. See Section
4.1.3.1 for further discussion of the variable consideration constraint. The estimate of the variable
consideration associated with the right of return would be reassessed at the end of each reporting
period in accordance with ASC 606-10-55-25 and 55-26, with changes in the estimate recognized as an
adjustment to revenue. If the conversion right is exercised, the amount previously deferred as a liability,
plus the incremental fee paid, would generally be recognized as revenue over the remaining term of the
SaaS (and the PCS for any licenses that are not converted).

In Example 4-2, Entity A would need to determine its estimate of variable consideration and how
much of that consideration, if any, should be constrained in line with the discussion in Section 4.1.3.1.
Assume that A determines that $500,000 of the $1 million transaction price is variable consideration,
which is calculated as ($4,000 on-premise software license SSP + $1,000 PCS SSP) × 100 seats × 1
year. In addition, assume that A estimates variable consideration of $250,000 — calculated as ($4,000
on-premise software license SSP + $1,000 PCS SSP) × 50 seats × 1 year — and concludes that none
of the estimated variable consideration should be constrained. Therefore, A will recognize revenue
of $600,000, or ($4,000 on-premise software license SSP × 100 seats × 1 year) + ($4,000 on-premise
software license SSP × 50 seats × 1 year), on January 1, 20X0, for the on-premise software license and

73
Deloitte | Health Tech Industry Accounting Guide (2023)

$100,000, or $1,000 PCS SSP × 100 seats × 1 year, for PCS ratably over 20X0. In addition, A will recognize
a liability of $250,000, or $1 million − $500,000 fixed consideration − $250,000 variable consideration,
for the credit that the customer is expected to receive for the on-premise software license and PCS that
are expected to be forfeited. Entity A will reassess its estimate of variable consideration at the end of
each reporting period.

Assume that on December 31, 20X0, A revises its estimate of the liability associated with the right
of return to $500,000 because it now expects that the customer will convert all 100 seats to a SaaS
arrangement. Entity A will reverse $200,000 of revenue for the incremental 50 seats of on-premise
software expected to be forfeited ($4,000 on-premise software license SSP × 50 seats × 1 year) and
reclassify the $50,000 PCS contract liability for the incremental PCS expected to be forfeited ($1,000 PCS
SSP × 50 seats × 1 year) for a total increase in liability of $250,000 related to the credit expected to be
granted to the customer. If the customer elects to exercise the conversion right on 100 seats on January
1, 20X1, revenue of $550,000, which is calculated by adding the liability of $500,000 and the incremental
fee of $50,000 ($500 incremental fee × 100 seats × 1 year), is recognized over the remaining one-year
SaaS term.

Because A’s initial estimate of the liability for the credit expected to be granted to the customer was
not sufficient, a significant amount of revenue ultimately had to be reversed in a subsequent reporting
period. This example highlights the importance of critically evaluating how much revenue should be
constrained to ensure that it is probable that a significant reversal in cumulative revenue recognized
will not occur. Given the risk of overestimating the amount of variable consideration to which an entity
can expect to be entitled for the on-premise software license and PCS, we believe that many software
entities, particularly those that do not have sufficient historical data on conversion rates, may find it
challenging to determine an appropriate estimate of variable consideration and constraint as required
under Alternative 1B.

4.6.2 Initial Contract Is Modified to Convert a Term-Based License to SaaS

The example below illustrates a situation in which a nonexclusive on-premise term-based software
license contract (1) initially does not include the right to convert the on-premise software license to a
SaaS arrangement but (2) is subsequently modified to immediately convert the on-premise software
license to a SaaS arrangement.

Example 4-3

On January 1, 20X0, Entity B enters into a noncancelable two-year contract with a customer for an up-front
fee of $1 million to provide a nonexclusive on-premise software license with PCS for 100 seats. At contract
inception, there is no explicit or implied right to convert any of the on-premise license seats to a SaaS
arrangement.

On January 1, 20X1, B and the customer modify the contract to convert 50 seats of the on-premise software
license to a SaaS arrangement for the remaining term. The SaaS has the same functionality and features as the
licensed software but would be hosted by B instead of being provided on an on-premise basis. The customer is
required to forfeit the 50 on-premise software license seats and related PCS (but will retain the other 50 seats
on an on-premise basis with the related PCS for the remaining term), and the conversion is irrevocable (i.e., the
customer cannot convert back to an on-premise software license). Upon contract modification and conversion,
the customer is required to pay an incremental fee of $500 per seat and receives a credit for the pro rata
portion of the “unused” term-based license and related PCS to apply to the price the customer will pay for the
SaaS.

74
 Chapter 4 — Revenue Recognition for Health Tech Companies

Example 4-3 (continued)

The SSPs are as follows:

Performance Obligation SSP

On-premise software license $4,000 per seat per year

PCS $1,000 per seat per year

SaaS $5,500 per seat per year

4.6.2.1 Alternative 2A — Prospective Model (Preferred View)

Under this alternative, a health tech company should evaluate the contract modification guidance since
the contract has been modified (i.e., there is a change in the scope and price). Contract modifications
are further discussed in Section 4.1.6 of this guide. Specifically, ASC 606-10-25-12 and 25-13 state the
following:

ASC 606-10

25-12 An entity shall account for a contract modification as a separate contract if both of the following
conditions are present:
a. The scope of the contract increases because of the addition of promised goods or services that are
distinct (in accordance with paragraphs 606-10-25-18 through 25-22).
b. The price of the contract increases by an amount of consideration that reflects the entity’s standalone
selling prices of the additional promised goods or services and any appropriate adjustments to that
price to reflect the circumstances of the particular contract. For example, an entity may adjust the
standalone selling price of an additional good or service for a discount that the customer receives,
because it is not necessary for the entity to incur the selling-related costs that it would incur when selling
a similar good or service to a new customer.

25-13 If a contract modification is not accounted for as a separate contract in accordance with paragraph
606-10-25-12, an entity shall account for the promised goods or services not yet transferred at the date of the
contract modification (that is, the remaining promised goods or services) in whichever of the following ways is
applicable:
a. An entity shall account for the contract modification as if it were a termination of the existing contract,
and the creation of a new contract, if the remaining goods or services are distinct from the goods or
services transferred on or before the date of the contract modification. The amount of consideration to
be allocated to the remaining performance obligations (or to the remaining distinct goods or services in
a single performance obligation identified in accordance with paragraph 606-10-25-14(b)) is the sum of:
1. The consideration promised by the customer (including amounts already received from the
customer) that was included in the estimate of the transaction price and that had not been
recognized as revenue and
2. The consideration promised as part of the contract modification.
b. An entity shall account for the contract modification as if it were a part of the existing contract if the
remaining goods or services are not distinct and, therefore, form part of a single performance obligation
that is partially satisfied at the date of the contract modification. The effect that the contract modification
has on the transaction price, and on the entity’s measure of progress toward complete satisfaction
of the performance obligation, is recognized as an adjustment to revenue (either as an increase in or
a reduction of revenue) at the date of the contract modification (that is, the adjustment to revenue is
made on a cumulative catch-up basis).
c. If the remaining goods or services are a combination of items (a) and (b), then the entity shall account for
the effects of the modification on the unsatisfied (including partially unsatisfied) performance obligations
in the modified contract in a manner that is consistent with the objectives of this paragraph.

75
Deloitte | Health Tech Industry Accounting Guide (2023)

The contract modification is accounted for as a termination of the existing contract and the creation of
a new contract in accordance with ASC 606-10-25-13(a), as discussed above, because the modification
does not solely add goods or services at their SSPs (i.e., goods and services are also forfeited, and
any incremental fee paid for the SaaS is not at its SSP) and the remaining SaaS (and PCS for any
licenses that are not converted) is distinct. See Section 4.1.4 of this guide for more information about
the determination of a performance obligation’s SSP. The contract modification is accounted for
prospectively, and any unrecognized revenue that was included in the transaction price from the original
contract, plus any additional consideration paid as part of the contract modification, is recognized
over the remaining term of the SaaS (and the PCS for any licenses that are not converted). There is no
adjustment to or reversal of revenue for the “unused” portion of the on-premise software license since
the modification is accounted for prospectively (i.e., revenue is not “recycled”). Further, the entity does
not receive a “returned” asset since, as similarly noted in the discussion of Alternative 1A, the entity does
not receive an asset of any value back. Therefore, none of the pro rata credit provided for the “unused”
portion of the on-premise software license that has been forfeited would be included as part of the
consideration allocated to the SaaS (and PCS for any licenses that are not converted).

In Example 4-3, Entity B will recognize revenue of $800,000 ($4,000 on-premise software license SSP ×
100 seats × 2 years) on January 1, 20X0, for the on-premise software license and $100,000 ($1,000 PCS
SSP × 100 seats × 1 year) for PCS ratably over 20X0. When the contract is modified on January 1, 20X1, B
has a PCS-related contract liability of $100,000 and receives incremental consideration of $25,000 ($500
incremental fee × 50 seats). Entity B will therefore recognize $125,000 ($100,000 + $25,000) for both
PCS and the SaaS over the remaining one-year term. Entity B could further allocate the value between
both the PCS and the SaaS on the basis of their relative SSPs if it is required to do so for presentation
and disclosure purposes.

4.6.2.2 Alternative 2B — Return Model (Acceptable View)

Under this alternative, in a manner similar to that in Alternative 2A, the contract modification is
accounted for as a termination of the existing contract and the creation of a new contract because
the modification does not solely add goods or services at their SSPs (i.e., goods and services are also
forfeited, and any incremental fee paid for the SaaS is not at its SSP) and the remaining SaaS (and PCS
if not all licenses are converted) is distinct. However, unlike Alternative 2A, Alternative 2B treats the
“unused” portion of the on-premise software license as being effectively returned for a credit that can
be applied toward the purchase of the SaaS. Therefore, revenue associated with the unused portion of
the returned on-premise software license is reversed. The amount of revenue reversed (i.e., the credit
associated with the unused portion of the returned on-premise software license), together with any
unrecognized revenue that was included in the transaction price from the original contract and any
additional consideration paid as part of the contract modification, is recognized over the remaining term
of the SaaS (and the PCS for any licenses that are not converted).

In Example 4-3, Entity B will recognize revenue of $800,000 ($4,000 on-premise software license SSP ×
100 seats × 2 years) on January 1, 20X0, for the on-premise software license and $100,000 ($1,000 PCS
SSP × 100 seats × 1 year) for PCS ratably over 20X0. When the contract is modified on January 1, 20X1,
B will reverse revenue of $200,000 ($4,000 on-premise software license SSP × 50 seats × 1 year) for the
returned portion of the on-premise software license. Entity B also has a PCS-related contract liability of
$100,000 and receives incremental consideration of $25,000 ($500 incremental fee × 50 seats). Entity
B will therefore recognize revenue of $325,000 ($200,000 + $100,000 + $25,000) for both PCS and the
SaaS over the remaining one-year term. Entity B could further allocate the value between both the PCS
and the SaaS on the basis of their relative SSPs if it is required to do so for presentation and disclosure
purposes.

76
 Chapter 4 — Revenue Recognition for Health Tech Companies

4.6.3 Initial Contract Is Modified to Add a Cloud Conversion Right

The example below illustrates a situation in which a nonexclusive on-premise term-based software
license contract (1) initially does not include the right to convert the on-premise software license to a
SaaS arrangement but (2) is subsequently modified to add a right to convert the on-premise software
license to a SaaS arrangement.

Example 4-4

On January 1, 20X0, Entity C enters into a noncancelable three-year contract with a customer for an up-front
fee of $3 million to provide a nonexclusive on-premise software license with PCS for 100 seats. At contract
inception, there is no explicit or implied right to convert any of the on-premise license seats to a SaaS
arrangement.

On January 1, 20X1, C and the customer modify the contract to add a right to convert any of the on-premise
license seats to a SaaS arrangement at the beginning of the third year (i.e., January 1, 20X2). The SaaS has
the same functionality and features as the on-premise software but would be hosted by C instead of being
provided on an on-premise basis. As in Example 4-2, the customer would be required to forfeit the on-premise
software license seats and related PCS upon exercise of the conversion right, and the conversion is irrevocable
(i.e., the customer cannot convert back to an on-premise software license). Upon conversion, the customer
would be required to pay an incremental fee of $1,000 per seat and would receive a credit for a pro rata
portion of the “unused” on-premise software license and related PCS to apply to the price the customer would
pay for the SaaS.

The SSPs are as follows:

Performance Obligation SSP

On-premise software license $8,000 per seat per year

PCS $2,000 per seat per year

SaaS $11,000 per seat per year

4.6.3.1 Alternative 3A — Prospective-Material-Right Model (Preferred View)

Under this alternative, in a manner similar to that under Alternative 2A, the contract modification is
accounted for as a termination of the existing contract and the creation of a new contract because the
modification does not solely add goods or services at their SSPs (i.e., a conversion right is added for
no additional consideration, and any incremental fee to be paid for the SaaS is not at its SSP) and the
remaining performance obligations (PCS and a material right) are distinct. The contract modification
is accounted for prospectively, and any unrecognized revenue that was included in the transaction
price from the original contract is allocated to the remaining performance obligations (PCS and a
material right). If the conversion option is exercised, the amount allocated to the material right plus any
incremental fee paid would generally be recognized over the remaining term of the SaaS (and the PCS
for any licenses that are not converted).

In Example 4-4, Entity C will recognize revenue of $2.4 million ($8,000 on-premise software license SSP
× 100 seats × 3 years) on January 1, 20X0, for the software license and $200,000 ($2,000 PCS SSP × 100
seats × 1 year) for PCS ratably over 20X0. When the contract is modified on January 1, 20X1, C has a
PCS-related contract liability of $400,000. Entity C will allocate that amount to the remaining PCS and
the material right on the basis of their relative SSPs. The material right’s SSP would be estimated as the
$10,000 per seat per year discount ($11,000 SaaS SSP − $1,000 incremental fee to be paid), adjusted
for the likelihood that the option will be exercised. We believe that it would also be acceptable for C to
estimate the SSP of the PCS by applying a similar adjustment for the likelihood that the option will be
exercised (which could truncate the term of the PCS).

77
Deloitte | Health Tech Industry Accounting Guide (2023)

Assume that C determines that the relative SSP allocation of the transaction price results in allocations
to the PCS for 20X1, the PCS for 20X2, and the material right of $100,000, $50,000, and $250,000,
respectively. (Note that this allocation is hypothetical and for illustrative purposes only.) Entity C will
recognize $100,000 for PCS ratably over 20X1. If the customer elects to exercise the conversion right
on 100 seats on January 1, 20X2, C would assess its policy related to accounting for the exercise of an
option that includes a material right and would apply either of the following approaches:

• Separate contract model — The remaining unrecognized revenue of $50,000 related to PCS is
recognized immediately since PCS for all 100 seats is forfeited and therefore will not be provided
in 20X2. Revenue of $350,000, which is calculated by adding the material right allocation
of $250,000 and the incremental fee of $100,000 ($1,000 incremental fee × 100 seats), is
recognized over the remaining one-year SaaS term.

• Contract modification model — Revenue of $400,000, which is calculated by adding the remaining
unrecognized revenue of $50,000 related to PCS, the material right allocation of $250,000, and
the incremental fee of $100,000, is recognized over the remaining one-year SaaS term.

Alternative 3A may be less costly to implement than Alternative 3B below because the SSP of the
material right is estimated only upon contract modification and is not subsequently revised. In
addition, because the right-of-return model is not applied, the variable consideration constraint would
likewise not be applicable. Therefore, revenue recognition could potentially be less volatile under the
prospective-material-right model than under the right-of-return model discussed below.

4.6.3.2 Alternative 3B — Right-of-Return Model (Acceptable View)

Under this alternative, in a manner similar to that under Alternative 3A, the contract modification is
accounted for as a termination of the existing contract and the creation of a new contract because
the modification does not solely add goods or services at their SSPs (i.e., a conversion right is added
for no additional consideration, which could result in the forfeiture of goods and services, and any
incremental fee to be paid for the SaaS is not at its SSP) and the remaining PCS is distinct. However,
unlike Alternative 3A, Alternative 3B treats any “unused” portion of the on-premise software license as
being effectively returned for a credit that can be applied toward the purchase of the SaaS. Therefore,
revenue associated with the expected unused portion of the returned on-premise software license is
reversed. The amount of revenue reversed (i.e., the credit associated with the potential unused portion
of the returned on-premise software license), together with any unrecognized revenue that was included
in the transaction price from the original contract, is accounted for prospectively over the remaining
two-year term. In applying the right-of-return guidance, the entity would estimate and recognize an
adjustment to the transaction price (and reduce revenue) upon contract modification to account
for the potential conversion. The right of return would be accounted for as variable consideration,
subject to the constraint in ASC 606-10-32-11 and 32-12 and further discussed in Section 4.1.3.1. The
estimate of variable consideration associated with the right of return would be reassessed at the end
of each reporting period in accordance with ASC 606-10-55-25 and 55-26, with changes in the estimate
recognized as an adjustment to revenue. If the conversion right is exercised, the amount previously
deferred as a liability, plus the incremental fee paid, would generally be recognized as revenue over the
remaining term of the SaaS (and the PCS for any licenses that are not converted).

78
 Chapter 4 — Revenue Recognition for Health Tech Companies

In Example 4-4, Entity C will recognize revenue of $2.4 million ($8,000 on-premise software license
SSP × 100 seats × 3 years) on January 1, 20X0, for the software license and $200,000 ($2,000 PCS SSP
× 100 seats × 1 year) for PCS ratably over 20X0. When the contract is modified on January 1, 20X1, C
would need to determine its estimate of variable consideration and how much of that consideration, if
any, should be constrained. Assume that C determines that $1 million of the original transaction price
of $3 million is variable consideration, which is calculated as ($8,000 on-premise software license SSP
+ $2,000 PCS SSP) × 100 seats × 1 year. In addition, assume that C estimates variable consideration
of $500,000 — calculated as ($8,000 on-premise software license SSP + $2,000 PCS SSP) × 50 seats
× 1 year — and concludes that none of the estimated variable consideration should be constrained.
Therefore, C will reverse revenue of $400,000 ($8,000 on-premise software license × 50 seats × 1 year)
and reclassify $100,000 of the PCS contract liability for the PCS expected to be forfeited ($2,000 PCS SSP
× 50 seats × 1 year) for a total liability of $500,000 for the credit the customer is expected to receive.
Entity C also has a remaining PCS-related contract liability of $300,000 and recognizes $200,000 ($2,000
PCS SSP × 100 seats × 1 year) for PCS ratably over 20X1.

Assume that on December 31, 20X1, C revises its estimate of the liability associated with the right
of return to $1 million because it now expects that the customer will convert all 100 seats to a SaaS
arrangement. Entity C will reverse an additional $400,000 of revenue for the incremental 50 seats of
on-premise software expected to be forfeited ($8,000 software license SSP × 50 seats × 1 year) and
reclassify $100,000 of the remaining PCS contract liability for the incremental PCS expected to be
forfeited ($2,000 PCS SSP × 50 seats × 1 year) for a total increase in liability of $500,000 related to the
credit expected to be granted to the customer. If the customer elects to exercise the conversion right
on 100 seats on January 1, 20X2, revenue of $1.1 million, which is calculated by adding the liability of $1
million and the incremental fee of $100,000 ($1,000 incremental fee × 100 seats × 1 year), is recognized
over the remaining one-year SaaS term.

Because C’s initial estimate of the liability for the credit expected to be granted to the customer was
not sufficient, a significant amount of revenue ultimately had to be reversed in a subsequent reporting
period. This example highlights the importance of critically evaluating how much revenue should be
constrained, as discussed in Section 4.1.3.1, to ensure that it is probable that a significant reversal in
cumulative revenue recognized will not occur. Given the risk of overestimating the amount of variable
consideration to which an entity can expect to be entitled for the on-premise software license and PCS,
we believe that many software entities, particularly those that do not have sufficient historical data on
conversion rates, may find it challenging to determine an appropriate estimate of variable consideration
and constraint as required under Alternative 3B.

4.6.4 Initial Contract Includes Cloud Mixing Rights With a Cap

The example below illustrates an initial contract that gives the customer the right to use nonexclusive
licensed software on both an on-premise basis and a cloud basis, subject to a cap on the total number
of seats.

Example 4-5

On January 1, 20X0, Entity D enters into a noncancelable two-year contract with a customer for an up-front fee
of $1 million to provide 1,000 nonexclusive software licenses. Under the terms of the contract, the customer
has an option to deploy each of the 1,000 licenses as either on-premise software or SaaS throughout the
two-year license term. That is, the customer can use any mix of on-premise software and SaaS at any point
during the license term as long as the number of licenses used does not exceed 1,000 seats. The on-premise
software license and the SaaS (1) are each fully functional on their own and (2) provide the same functionality
and features (other than D’s hosting of the SaaS). At contract inception, the customer decides to use 600
licenses as on-premise software and 400 licenses as SaaS. Six months later, the customer decides to use
500 licenses as on-premise software and 500 licenses as SaaS.

79
Deloitte | Health Tech Industry Accounting Guide (2023)

We believe that in the example above, Entity D may reasonably conclude that it has promised to
(1) provide the right to use on-premise software and (2) stand ready to provide SaaS (i.e., to host
the software license). Since each of the promises is likely to be distinct, there are two performance
obligations to which the $1 million fee should be allocated on a relative SSP basis. We believe that
it would be acceptable for D to estimate the SSP of each performance obligation by considering
the expected mix of on-premise software and SaaS. The SSPs are determined at contract inception
and should not be subsequently revised regardless of whether the mix of on-premise software and
SaaS changes after the initial estimate. Consideration allocated to the on-premise software would be
recognized once control of the license is transferred to the customer. In addition, since the performance
obligation to provide SaaS is satisfied over time, consideration allocated to this performance obligation
would be recognized as revenue over the two-year contract term (i.e., the period over which D is
required to stand ready to provide SaaS).

80
Chapter 5 — Costs of Obtaining a
Contract

5.1 Introduction
ASC 340-40 introduces comprehensive guidance on accounting for the costs of obtaining a contract
within the scope of ASC 606. Under U.S. GAAP, there is separate cost guidance in ASC 340-40 but not in
ASC 606.

Changing Lanes
Impact of the New Cost Guidance
Legacy guidance under U.S. GAAP does not contain a comprehensive cost framework for costs
of obtaining a contract. Regardless of an entity’s prior policies related to the costs of obtaining a
contract (i.e., capitalize or expense), there could be changes upon adoption of the new revenue
standard.

Specifically, ASC 340-40 provides the following guidance on recognizing the incremental costs of
obtaining a contract with a customer:

ASC 340-40

25-1 An entity shall recognize as an asset the incremental costs of obtaining a contract with a customer if the
entity expects to recover those costs.

25-2 The incremental costs of obtaining a contract are those costs that an entity incurs to obtain a contract
with a customer that it would not have incurred if the contract had not been obtained (for example, a sales
commission).

25-3 Costs to obtain a contract that would have been incurred regardless of whether the contract was obtained
shall be recognized as an expense when incurred, unless those costs are explicitly chargeable to the customer
regardless of whether the contract is obtained.

81
Deloitte | Health Tech Industry Accounting Guide (2023)

The flowchart below illustrates the process that entities should use in applying the guidance in ASC
340-40-25-1 through 25-3 to determine the treatment of costs of obtaining a contract with a customer.

Did the entity

incur costs in
its efforts to obtain
a contract with a
customer?

Yes

Are
Are those
those costs
costs explicitly
incremental No chargeable to the Yes
(incurred only as a customer regardless
direct result of of whether the
obtaining the contract is
contract)? obtained?

Yes
No

Does the entity No

expect to recover Expense costs as incurred.
those costs?

Yes

Is the
amortization
period of the Yes
The entity may either expense as
asset the entity will
incurred or recognize as an asset.
recognize one
year or less?

No Recognize as an asset the

incremental costs of obtaining a
contract.

82
 Chapter 5 — Costs of Obtaining a Contract

Under ASC 340-40-25-1, an entity must capitalize the incremental costs of obtaining a contract with a
customer if the entity expects to recover them.1 ASC 340-40-25-2 defines such incremental costs as
those that the entity “would not have incurred if the contract had not been obtained (for example, a
sales commission).” Questions have arisen about the types of costs that would qualify for capitalization
under the new revenue standard.

In TRG Agenda Paper 57 and Q&A 78 of the FASB staff’s Revenue Recognition Implementation Q&As,
which the FASB staff drafted in preparation for the TRG’s November 2016 meeting,2 the staff noted that
an entity should consider whether costs would have been incurred if the customer (or the entity) had
decided that it would not enter into the contract just as the parties were about to sign the contract. If
the costs (e.g., the legal costs of drafting the contract) would have been incurred even if the contract had
not been executed, they would not be incremental costs of obtaining a contract.

At the TRG’s November 2016 meeting, TRG members generally agreed with the FASB staff’s views on
which costs of obtaining a contract are incremental and the framework for analyzing whether costs
are incremental. In a manner consistent with prior discussions of the timing of revenue recognition,
TRG members confirmed their general agreement that entities should continue to refer to legacy U.S.
GAAP on liability recognition to determine whether and, if so, when a liability needs to be recorded
in connection with a contract with a customer. Therefore, an entity should initially apply the specific
guidance on determining the recognition and measurement of the liability (e.g., commissions, payroll
taxes, 401(k) match). If the entity recognizes a liability, only then should the entity determine whether to
record the related debit as an asset or as an expense.

One TRG member highlighted a difference between the new revenue standard’s guidance on capitalizing
costs to obtain a contract and the accounting under legacy practice. The new standard requires that
costs be incremental rather than both direct and incremental as they were under legacy U.S. GAAP (e.g.,
on loan origination and insurance policy acquisition). Accordingly, the TRG generally acknowledged that
this difference may lead to a broader pool of costs that are subject to capitalization (i.e., entities may
be required to capitalize certain costs in accordance with the new standard that they would not have
capitalized under legacy U.S. GAAP if they had elected a capitalization policy).

However, the TRG cautioned that entities would need to use judgment to determine whether
certain costs, such as commissions paid to multiple employees for the signing of a contract, are truly
incremental. The FASB staff encouraged entities to apply additional skepticism to understand whether
an employee’s compensation (i.e., commissions or bonus) — particularly for individuals in different
positions in the organization and employees who are ranked higher in an organization — is related
solely to executed contracts or is also influenced by other factors or metrics (e.g., employee general
performance or customer satisfaction ratings). TRG members emphasized that only those costs that are
incremental (e.g., costs that resulted from obtaining the contract) may be capitalized (as long as other
asset recognition criteria are met).

1
However, the practical expedient in ASC 340-40-25-4 allows an entity to “recognize the incremental costs of obtaining a contract as an expense
when incurred if the amortization period of the asset that the entity otherwise would have recognized is one year or less.”
2
For more information about the TRG’s November 2016 meeting, see TRG Agenda Paper 60 and Deloitte’s November 2016 TRG Snapshot.

83
Deloitte | Health Tech Industry Accounting Guide (2023)

The table below outlines the views discussed at the TRG meeting on the examples in TRG Agenda Paper
57 and the views selected by the FASB staff. Quoted text is from TRG Agenda Paper 57.

View Selected by FASB

Topic Example/Question Views Discussed Staff

Fixed employee “Example 1: An entity pays View A: “Determine what View B. “[N]one of the
salaries an employee an annual portion of the employee’s employee’s salary should be
salary of $100,000. The salary is related to sales capitalized as an incremental
employee’s salary is based projections and allocate cost to obtain a contract. . . .
upon the employee’s that portion of the salary Whether the employee sells
prior-year signed contracts as an incremental cost to 100 contracts, 10 contracts,
and the employee’s obtain a contract.” or no contracts, the
projected signed contracts employee is still only entitled
for the current year. The View B: “Do not capitalize to a fixed salary.”
employee’s salary will any portion of the
not change based on employee’s salary as an “[T]he objective of the
the current year’s actual incremental cost to obtain requirements in [ASC]
signed contracts; however, a contract. The costs are 340-40-25-1 is not to allocate
salary in future years likely not incremental costs to costs that are associated in
will be impacted by the any contract because the some manner with an entity’s
current year’s actual signed costs would have been marketing and sales activity.
contracts. What amount, incurred regardless of The objective is to identify
if any, should the entity the employee’s signed the incremental costs that
record as an asset for contracts in the current an entity would not have
incremental costs to obtain year.” incurred if the contract had
a contract during the year?” not been obtained.”

Some, but not “Example 2: An entity pays View A: “The entity should View A. “[T]he sales
all, costs are a 5% sales commission to capitalize only $25,000 commission is the only cost
incremental its employees when they for the sales commission. that the entity would not
obtain a contract with a Those costs are the only have incurred if the contract
customer. An employee costs that are incremental had not been obtained.
begins negotiating a costs to obtain the contract While the entity incurs other
contract with a prospective because the entity would costs that are necessary to
customer and the entity not have incurred the costs facilitate a sale (such as legal,
incurs $5,000 of legal and if the contract had not been travel and many others),
travel costs in the process obtained.” those costs would have
of trying to obtain the been incurred even if the
contract. The customer View B: “The entity customer decided at the last
ultimately enters into a should capitalize $30,000, moment not to execute the
$500,000 contract and, which includes the contract.”
as a result, the employee sales commission, legal
receives a $25,000 sales expenses, and travel If an entity “incurs the same
commission. What amount expenses. The entity would type of legal and travel
should the entity capitalize not have been able to expenses to negotiate a
as an incremental cost to obtain the contract without contract, but the customer
obtain the contract?” incurring those expenses.” decides not to enter into
the contract right before the
contract was to be signed
by both parties. [T]he travel
and legal expenses would
still have been incurred even
though the contract was
not obtained. However, the
commission would not have
been incurred.”

84
 Chapter 5 — Costs of Obtaining a Contract

(Table continued)

View Selected by FASB

Topic Example/Question Views Discussed Staff

Timing of “Example 3: An entity View A: “Capitalize half of View B. “The commission

commission pays an employee a 4% the commission ($1,000) is an incremental cost that
payments sales commission on and expense the other relates specifically to the
all of the employee’s half of the commission signed contract and the
signed contracts with ($1,000).” employee is entitled to the
customers. For cash flow unpaid commission. [T]he
management, the entity View B: “Capitalize timing of payment does not
pays the employee half the entire commission impact whether the costs
of the commission (2% of ($2,000).” would have been incurred if
the total contract value) the contract had not been
upon completion of the obtained.”
sale, and the remaining
half of the commission “In this fact pattern, only
(2% of the total contract the passage of time needs
value) in six months. The to occur for the entity to
employee is entitled to the pay the second half of the
unpaid commission, even if commission. However, . . .
the employee is no longer there could be other fact
employed by the entity patterns in which additional
when payment is due. An factors might impact the
employee makes a sale of payment of a commission
$50,000 at the beginning to an employee.” For
of year one. What amount example, an entity could
should the entity capitalize make the second half of
as an incremental cost to the commission contingent
obtain the contract?” upon the employee’s selling
additional services to the
customer or upon the
customer’s “completing a
favorable satisfaction survey
about its first six months
of working with the entity.”
Therefore, an “entity will
need to assess its specific
compensation plans to
determine the appropriate
accounting for incremental
costs of obtaining a
contract.”

85
Deloitte | Health Tech Industry Accounting Guide (2023)

(Table continued)

View Selected by FASB

Topic Example/Question Views Discussed Staff

Commissions paid “Example 4: An entity’s View A: “Only the View C. “The new revenue
to different levels salesperson receives a commission paid to the standard does not make
of employees 10% sales commission on salesperson is considered a differentiation based on
each contract that he or incremental because the the function or title of the
she obtains. In addition, salesperson obtained the employee that receives
the following employees contract.” the commission. It is the
of the entity receive sales entity that decides which
commissions on each View B: “Only the employee(s) are entitled to
signed contract negotiated commissions paid to a commission directly as
by the salesperson: 5% the salesperson and the a result of entering into a
to the manager and 3% manager are considered contract.”
to the regional manager. incremental because the
Which commissions are other employee likely would “[I]t is possible that several
incremental costs of have had no direct contact commissions payments
obtaining a contract?” with the customer.” are incremental costs of
obtaining the same contract.
View C: “All of the However, [stakeholders are
commissions are encouraged] to ensure that
incremental because the each of the commissions
commissions would not are incremental costs of
have been incurred if the obtaining a contract with
contract had not been a customer, rather than
obtained.” variable compensation (for
example, a bonus)” that
would not be incremental
because it also relies on
factors other than sales.

86
 Chapter 5 — Costs of Obtaining a Contract

(Table continued)

View Selected by FASB

Topic Example/Question Views Discussed Staff

Commission “Example 5: An entity has View A: “No amounts View B. Both the 2
payments subject a commission program that should be capitalized percent commission and
to a threshold increases the amount of because the commission is the 5 percent commission
commission a salesperson not directly attributable to a are incremental costs of
receives based on how specific contract.” obtaining a contract. “The
many contracts the entity would apply other
salesperson has obtained View B: “The costs are GAAP to determine whether
during an annual period. incremental costs of a liability for the commission
The breakdown is as obtaining a contract with a payments should be
follows: customer and, therefore, recognized. When a liability is
the costs should be recognized, the entity would
• 0–9 contracts . . . capitalized.” recognize a corresponding
0% commission
asset for the commissions.
• 10–19 contracts . . . This is because the
2% of value of commissions are incremental
contracts 1–19 costs of obtaining a contract
• 20+ contracts . . . 5% with a customer. The entity
of value of contracts has an obligation to pay
1–20+ commissions as a direct
result of entering into
Which commissions are contracts with customers.
incremental costs of The fact that the entity’s
obtaining a contract?” program is based on a
pool of contracts (versus a
program in which the entity
pays 3% for all contracts)
does not change the fact
that the commissions would
not have been incurred if
the entity did not obtain
the contracts with those
customers.”

5.2 Using the Portfolio Approach for Contract Costs

The guidance in ASC 340-40 was developed contemporaneously with that in ASC 606. ASC 340-40-05-1
expressly indicates that ASC 340-40 is aligned with ASC 606, stating that “[t]his Subtopic provides
accounting guidance for the following costs related to a contract with a customer within the scope of
Topic 606 on revenue from contracts with customers.”

ASC 606 is applied at the individual contract level (or to a combination of contracts accounted for under
ASC 606-10-25-9). In addition, ASC 606-10-10-4 allows an entity to apply, as a practical expedient, the
revenue recognition guidance to a portfolio of contracts rather than an individual contract. The practical
expedient can only be used “if the entity reasonably expects that the effects on the financial statements
of applying [the revenue recognition guidance] to the portfolio would not differ materially from applying
[the revenue recognition guidance] to the individual contracts (or performance obligations) within
that portfolio.” In addition, ASC 606-10-10-3 states that an “entity shall apply this guidance, including
the use of any practical expedients, consistently to contracts with similar characteristics and in similar
circumstances.”

87
Deloitte | Health Tech Industry Accounting Guide (2023)

If an entity reasonably expects that contract costs recorded under a portfolio approach would not
differ materially from contract costs that would be recorded individually, an entity may apply a portfolio
approach to account for the costs. The entity would use judgment in determining the characteristics of
the portfolio in a manner similar to its assessment of whether a portfolio satisfies the requirements in
ASC 606-10-10-4.

In applying the portfolio approach, an entity should consider paragraph BC69 of ASU 2014-09, which
states that the FASB and IASB “did not intend for an entity to quantitatively evaluate each outcome
and, instead, the entity should be able to take a reasonable approach to determine the portfolios that
would be appropriate for its types of contracts.” In determining the characteristics and composition
of the portfolio, an entity should consider the nature and timing of costs incurred and the pattern of
transferring control of the related good or service to the customer (e.g., amortization of the capitalized
costs).

An entity may have a policy of matching 401(k) contributions on the basis of salaries paid to sales
representatives, including sales commissions. These sales commissions may be determined to meet
the definition of incremental costs of obtaining contracts with customers in ASC 340-40-25-2 and would
therefore be capitalized in accordance with ASC 340-40-25-1.

ASC 340-40-25-1 requires an entity to “recognize as an asset the incremental costs of obtaining a
contract with a customer if the entity expects to recover those costs.” The incremental costs of obtaining
a contract are defined in ASC 340-40-25-2 as “those costs that an entity incurs to obtain a contract with
a customer that it would not have incurred if the contract had not been obtained (for example, a sales
commission).”

When 401(k) match contributions (along with other fringe benefits) are attributed directly to sales
commissions that are determined to be incremental costs of obtaining contracts with customers, the
401(k) match contributions also qualify as incremental costs of obtaining the contracts since such costs
would not have been incurred if the contracts had not been obtained. However, incremental costs of
obtaining contracts with customers would not include fringe benefits constituting an allocation of costs
that would have been incurred regardless of whether a contract with a customer had been obtained.

Arrangements for the payment of some incremental costs of obtaining a contract may be complex.
For example, payment of a sales commission may be (1) contingent on a future event, (2) subject to
clawback, or (3) based on achieving cumulative targets.

The new revenue standard does not address when to recognize the incremental costs of obtaining a
contract. Other Codification topics (e.g., ASC 275, ASC 710, ASC 712, ASC 715, and ASC 718) specify when
a liability for costs should be recognized and how that liability should be measured.

If an entity concludes that a liability for incremental costs of obtaining a contract should be recognized
under the relevant Codification topic, the guidance in ASC 340-40-25-1 should be applied to determine
whether those recognized costs should be capitalized as an asset or recognized immediately as an
expense.

88
 Chapter 5 — Costs of Obtaining a Contract

Connecting the Dots

Considering Whether Costs Should Be Capitalized as Costs of Obtaining a Contract
ASC 340-40-25-2 states that the “incremental costs of obtaining a contract are those costs
that an entity incurs to obtain a contract with a customer that it would not have incurred if the
contract had not been obtained (for example, a sales commission).” Application of this guidance
requires an entity to identify those costs that are incurred (i.e., accrued) as a direct result of
obtaining a contract with a customer. An entity should apply existing guidance outside of the
new revenue standard to determine whether a liability should be recognized as a result of
obtaining a contract with a customer. Upon determining that a liability needs to be recorded, the
entity should determine whether the related costs were incurred because, and only because, a
contract with a customer was obtained.

In many circumstances, it may be clear whether particular costs are costs that an entity incurs
to obtain a contract. For example, if an entity incurs a commission liability solely as a result of
obtaining a contract with a customer, the commission would be an incremental cost incurred
to obtain such a contract. However, in other circumstances, an entity may need to exercise
judgment and consider existing accounting policies for liability accruals when determining
whether a cost is incurred in connection with obtaining a contract with a customer. As also
noted in TRG Agenda Paper 57, when the determination of whether a cost has been incurred
is affected by other factors (i.e., factors in addition to obtaining a contract with a customer), an
entity will need to take additional considerations into account when assessing whether a cost is
an incremental cost associated with obtaining a contract with a customer.

For example, some commission plans include substantive service conditions that need to be
met before a commission associated with a contract (or group of contracts) is actually earned
by the salesperson. In such cases, some or all of the sales commission may not be incremental
costs incurred to obtain a contract with the customer since the costs were not actually incurred
solely as a result of obtaining a contract with a customer. Rather, the costs were incurred as a
result of obtaining a contract with a customer and the salesperson’s providing ongoing services
to the entity for a substantive period.

Some commission structures could have a service condition that is determined to be

nonsubstantive. In such cases, the commission is likely to be an incremental cost incurred to
obtain a contract with a customer. In other cases, a commission plan could include a service
condition, but the reporting entity determines on the basis of the amount and structure of the
commission payments that part of the entity’s commission obligation is an incremental cost
incurred to obtain a contract with a customer (because it is not tied to a substantive service
condition) while the rest of the commission is associated with ongoing services provided by the
salesperson.

Sometimes, there may be other factors that affect the commission obligation but the ultimate
costs are still incremental costs incurred to obtain the contract. For example, a commission
may be payable to a salesperson if a customer’s total purchases exceed a certain threshold
regardless of whether the salesperson is employed when the threshold is met (i.e., there is no
service condition). In these cases, although no liability may be recorded when the contract with
the customer is obtained (because of the entity’s assessment of the customer’s likely purchases),
if the customer’s purchases ultimately exceed the threshold and the commission is paid, the
commission is an incremental cost of obtaining the contract. That is, the commission is a cost
that the entity would not have incurred if the contract had not been obtained. This situation
is economically similar to one involving a paid commission that is subject to clawback if the
customer does not purchase a minimum quantity of goods or services.

89
Deloitte | Health Tech Industry Accounting Guide (2023)

Entities will need to carefully evaluate the facts and circumstances when factors other than just
obtaining a contract with a customer affect the amount of a commission or other incurred costs.
Entities should consider their existing policies on accruing costs when determining which costs
are incremental costs incurred to obtain a contract with a customer.

Example 5-1

Entity A’s internal salespeople earn a commission based on a fixed percentage (4 percent) of sales invoiced to
a customer. Half of the commission is paid when a contract with a customer is signed; the other half is paid
after 12 months but only if the salesperson is still employed by A. Entity A concludes that a substantive service
period is associated with the second commission payment, and A’s accounting policy is to accrue the remaining
commission obligation ratably as the salesperson provides ongoing services to A.

Entity A enters into a three-year noncancelable service contract with a customer on January 1, 20X7. The total
transaction price of $3 million is invoiced on January 1, 20X7. The salesperson receives a commission payment
of 2 percent of the invoice amount ($60,000) when the contract is signed; the other half of the 4 percent
commission will be paid after 12 months if the salesperson continues to be employed by A at that time. That
is, if the salesperson is not employed by A on January 1, 20X8, the second commission payment will not be
made. Entity A records a commission liability of $60,000 on January 1, 20X7, and accrues the second $60,000
commission obligation ratably over the 12-month period from January 1, 20X7, through December 31, 20X7.

Entity A concludes that only the first $60,000 is an incremental cost incurred to obtain a contract with a
customer. Because there is a substantive service condition associated with the second $60,000 commission,
A concludes that the additional cost is a compensation cost incurred in connection with the salesperson’s
ongoing service to A. That is, the second $60,000 commission obligation was not incurred solely to obtain a
contract with a customer but was incurred in connection with ongoing services provided by the salesperson.

If the salesperson would be paid the commission even if no longer employed, or if A otherwise concluded
that the service condition was not substantive, the entire $120,000 would be an incremental cost incurred to
obtain a contract and would be capitalized in accordance with ASC 340-40-25-1. Entities will need to exercise
professional judgment when determining whether a service condition is substantive.

Because commission and compensation structures can vary significantly between entities, an entity
should evaluate its specific facts and circumstances when determining which costs are incremental
costs incurred to obtain a contract with a customer. It is important for entities to consider whether an
obligation to make a payment is solely a result of obtaining a contract with a customer. Further, entities
will need to refer to U.S. GAAP outside of the new revenue standard to determine when a liability has
been incurred. Upon recognizing a liability, an entity needs to consider whether the corresponding
amount should be recognized as an asset in accordance with ASC 340-40-25-1.

90
 Chapter 5 — Costs of Obtaining a Contract

5.3 Disclosure Requirements
ASC 340-40-50 provides the disclosure requirements for costs of obtaining contracts with customers.
The table below summarizes these disclosure requirements, including both the disclosures that a
nonpublic entity may elect not to apply and required interim disclosures.

Election Available to Interim Requirement

Category Disclosure Requirements Nonpublic Entities (ASC 270)

Contract costs Qualitative information about:

• Judgments the entity used in Yes No

determining the amount of
the costs incurred to obtain
or fulfill a contract.

• The method the entity Yes No

uses to determine the
amortization for each
reporting period.

Quantitative information about:

• The closing balances of Yes No

assets recognized from the
costs incurred to obtain or
fulfill a contract, by main
category of asset.

• The amount of amortization Yes No

and any impairment losses
recognized in the reporting
period.

Entities must also disclose significant judgments related to contract costs to help financial statement
users understand the types of costs that the entity has recognized as assets and how those assets are
subsequently amortized or impaired.

ASC 340-40

50-1 Consistent with the overall disclosure objective in paragraph 606-10-50-1 and the guidance in paragraphs
606-10-50-2 through 50-3, an entity shall provide the following disclosures of assets recognized from the costs
to obtain or fulfill a contract with a customer in accordance with paragraphs 340-40-25-1 or 340-40-25-5.

50-2 An entity shall describe both of the following:

a. The judgments made in determining the amount of the costs incurred to obtain or fulfill a contract with
a customer (in accordance with paragraph 340-40-25-1 or 340-40-25-5)
b. The method it uses to determine the amortization for each reporting period.

50-3 An entity shall disclose all of the following:

a. The closing balances of assets recognized from the costs incurred to obtain or fulfill a contract with a
customer (in accordance with paragraph 340-40-25-1 or 340-40-25-5), by main category of asset (for
example, costs to obtain contracts with customers, precontract costs, and setup costs)
b. The amount of amortization and any impairment losses recognized in the reporting period.

91
Deloitte | Health Tech Industry Accounting Guide (2023)

ASC 340-40 (continued)

50-4 An entity, except for a public business entity, a not-for-profit entity that has issued, or is a conduit bond
obligor for, securities that are traded, listed, or quoted on an exchange or an over-the-counter market, or
an employee benefit plan that files or furnishes financial statements with or to the Securities and Exchange
Commission, may elect not to provide the disclosures in paragraphs 340-40-50-2 through 50-3.

The illustrative disclosure below shows how an entity may disclose the qualitative and quantitative
information required under ASC 340-40-50-1 through 50-4.

Illustrative Disclosure — Qualitative and Quantitative Information About Contract Costs

Assets Recognized From Costs of Obtaining or Fulfilling a Contract With a Customer

For the business units C and D, the Company determines that the incentive portions of its sales commission
plans qualify for capitalization since these payments are directly related to sales achieved during a time period.
Domestically, the amortization period for the capitalized asset is the original contract term. Most international
contracts are multiyear renewals and thus have amortization periods longer than a year. The commissions
related to these contracts are capitalized and amortized. For the sales commissions that are capitalized (i.e.,
contracts with multiyear maintenance), the Company determines that an amortization method that allocates
the capitalized costs on a relative basis to the products and services sold is a reasonable and systematic basis.
When the Company recognizes revenue related to goods and services over time by using the time-elapsed
output method, the costs related to those goods and services are amortized over the same period. The
capitalized costs of the remaining goods and services for which revenue is recognized over time are amortized
in the periods in which the goods and services are invoiced.

For business unit A, the Company determines that the incentive portions of its sales commission plans qualify
for capitalization. These commissions are earned on the basis of the total purchase order value of new
bookings, which does not include sales related to renewals. Since there are not commensurate commissions
earned on renewal of the Type B services, the Company concludes that the capitalized asset is related to Type
B services provided under both the initial contract and renewal periods. Therefore, the amortization period
for the asset is the customer life, which is determined to be five years. Since the asset is related to services
that are transferred over the customer’s life, the Company amortizes the asset on a straight-line basis over the
customer life of five years.

The Company concludes that none of its costs incurred meet the capitalization criteria for costs to fulfill a
contract.

92
Appendix A — Titles of Standards and
Other Literature

FASB Literature
ASC Topics
ASC 250, Accounting Changes and Error Corrections

ASC 270, Interim Reporting

ASC 275, Risks and Uncertainties

ASC 310, Receivables

ASC 340, Other Assets and Deferred Costs

ASC 350, Intangibles — Goodwill and Other

ASC 360, Property, Plant, and Equipment

ASC 605, Revenue Recognition

ASC 606, Revenue From Contracts With Customers

ASC 610, Other Income

ASC 710, Compensation — General

ASC 712, Compensation — Nonretirement Postemployment Benefits

ASC 715, Compensation — Retirement Benefits

ASC 718, Compensation — Stock Compensation

ASC 720, Other Expenses

ASC 730, Research and Development

ASC 740, Income Taxes

ASC 805, Business Combinations

ASC 835, Financial Instruments

ASC 842, Leases

ASC 928, Entertainment — Music

ASC 985, Software

93
Deloitte | Health Tech Industry Accounting Guide (2023)

ASUs
ASU 2014-09, Revenue From Contracts With Customers (Topic 606)

ASU 2016-08, Revenue From Contracts With Customers (Topic 606): Principal Versus Agent Considerations
(Reporting Revenue Gross Versus Net)

ASU 2016-10, Revenue From Contracts With Customers (Topic 606): Identifying Performance Obligations And
Licensing

ASU 2018-15, Intangibles — Goodwill and Other — Internal-Use Software (Subtopic 350-40): Customer’s
Accounting for Implementation Costs Incurred in a Cloud Computing Arrangement That Is a Service Contract —
a consensus of the FASB Emerging Issues Task Force

SEC Literature
Interpretive Release
No. 33-9106, Commission Guidance Regarding Disclosure Related to Climate Change

Proposed Rule Release

No. 33-11042, The Enhancement and Standardization of Climate-Related Disclosures for Investors

TRG Agenda Papers

TRG Agenda Paper 57, Capitalization and Amortization of Incremental Costs of Obtaining a Contract

TRG Agenda Paper 60, November 2016 Meeting — Summary of Issues Discussed and Next Steps

Superseded Literature
AICPA Statements of Position
SOP 93-7, Reporting on Advertising Costs

SOP 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use

FASB Statement
No. 91, Accounting for Nonrefundable Fees and Costs Associated With Originating or Acquiring Loans and
Initial Direct Costs of Leases — an amendment of FASB Statements No. 13, 60, and 65 and a rescission of
FASB Statement No. 17

94
Appendix B — Abbreviations
Abbreviation Description Abbreviation Description

AcSEC Accounting Standards Executive IASB International Accounting Standards

Committee Board

AI artificial intelligence IFRS International Financial Reporting

Standard
AICPA American Institute of Certified
Public Accountants IP intangible property

ASC FASB Accounting Standards IT information technology

Codification
MD&A Management’s Discussion and
ASU FASB Accounting Standards Update Analysis

BC Basis for Conclusions OCA SEC’s Office of the Chief

Accountant
CAQ Center for Audit Quality
PCAOB Public Company Accounting
CCA cloud computing arrangement Oversight Board
CIMA Chartered Institute of Management PCS postcontract customer support
Accountants
Q&A question and answer
CSRD Corporate Sustainability Reporting
Directive R&D research and development

DCP disclosure control and procedure SaaS software as a service

ERP enterprise resource planning SEC U.S. Securities and Exchange

Commission
ESG environmental, social, and
governance SOP AICPA Statement of Position

FASB Financial Accounting Standards SSP stand-alone selling price

Board
TRG transition resource group
FDII foreign-derived intangible income
USD U.S. dollars
GAAP generally accepted accounting
principles

95
This publication contains general information only and Deloitte is not, by means of
this publication, rendering accounting, business, financial, investment, legal, tax, or
other professional advice or services. This publication is not a substitute for such
professional advice or services, nor should it be used as a basis for any decision or
action that may affect your business. Before making any decision or taking any action
that may affect your business, you should consult a qualified professional advisor.
Deloitte shall not be responsible for any loss sustained by any person who relies on
this publication.

The services described herein are illustrative in nature and are intended to
demonstrate our experience and capabilities in these areas; however, due to
independence restrictions that may apply to audit clients (including affiliates) of
Deloitte & Touche LLP, we may be unable to provide certain services based on
individual facts and circumstances.

The FASB Accounting Standards Codification® material is copyrighted by the Financial

Accounting Foundation, 401 Merritt 7, PO Box 5116, Norwalk, CT 06856-5116, and is
reproduced with permission.

Copyright © 2023 Deloitte Development LLC. All rights reserved.