Do your products fall under software
revenue recognition guidance?
Insights for technology companies June 2011
Applying the amended provisions of ASC 985-605
Ralph Nefdt, Partner and National Software Sector
Leader, and Ryan Dillard, Senior Manager, Technology
Industry
Introduction
AICPA Statement of Position (SOP)
97-2, Software Revenue Recognition,
was issued during an era when software
was not embedded in as many products
as it is currently. Today, many products
— including toys, aircraft, cellphones,
Internet routers, copiers, medical devices,
all-in-one printers and other products —
incorporate software. As the prevalence
of products with embedded software
has grown, questions have arisen more
frequently about whether vendors of these
products should be accounting for them
as sales of software or sales of tangible
products.
Before the issuance of Accounting
Standards Update (ASU) 2009-14,
Certain Revenue Arrangements That
Include Software Elements, the scope of
Accounting Standards Codification (ASC)
985-605 (formerly SOP 97-2) included
products or services that contain software
that is more than incidental to the product
or service as a whole. Since SOP 97-2
was issued, many technological advances
have been made, and many products
now contain embedded software that
is more than incidental to the product.
Consequently, sales of many softwareenabled devices previously fell within
the scope of ASC 985-605. This is a
very important distinction, because the
accounting rules concerning software
revenue recognition are often much more
restrictive than those concerning the sale
of a tangible product.
Today, many products — including toys, aircraft,
cellphones, Internet routers, copiers, medical devices, allin-one printers and other products — incorporate software.
Do our products fall under software revenue recognition guidance?
For example, an entity must have
vendor specific objective evidence (VSOE)
of fair value to separate deliverables in
a multiple-element arrangement that is
accounted for under the provisions of
ASC 985-605. However, arrangements
with software-enabled devices often
include undelivered elements for which
VSOE does not exist, which can result
in revenue not always being recognized
in a pattern that is consistent with the
economic substance of the arrangement.
The undelivered elements may be in the
form of software, postcontract customer
support (PCS) or future upgrades.
As a result of these practice issues,
and as a result of deliberations during the
development of ASU 2009-13, MultipleDeliverable Revenue Arrangements,
the Emerging Issues Task Force (EITF)
added an item to its agenda to amend the
scope of ASC 985-605, which resulted in
the issuance of ASU 2009-14. ASU 200914 amended ASC 985-605 to exclude
from its scope certain tangible products
containing software that functions
together with nonsoftware deliverables
to deliver the tangible product’s essential
functionality. If the software contained
in the tangible product is essential to
the tangible product’s functionality, the
software is excluded from the scope of the
software revenue guidance. This exclusion
covers essential software that is sold with
or embedded within the product, along
with undelivered software elements that
relate to that tangible product’s essential
software. ASU 2009-14 does not create
any new methods of revenue recognition,
but its amendment to the scope of existing
guidance can significantly affect an
entity’s revenue recognition process.
Example 1
Entity A sells a PC with an operating system that, along with the hardware, provides the PC’s essential
functionality. Entity A never sells the PC and the operating system separately. Also included in the
arrangement is a specified upgrade right for the next version of the operating system and postcontract
customer support (PCS), including a right to when-and-if-available upgrades of the operating system.
Since the hardware (nonsoftware component) and operating system (software component) function together
to deliver the tangible product’s essential functionality, these components are excluded from the scope of
ASC 985-605.
In addition, because the PCS and the specified upgrade right relate to the software that is essential to the
PC’s functionality, they are also excluded from the scope of ASC 985-605.
The entire arrangement is assessed for separation, measurement and allocation in accordance with the
amended guidance in ASC 605-25.
Example 2
Entity A sells a PC with an operating system that, along with the hardware, provides the PC’s essential
functionality. Entity A also sells customized productivity software with and separately from the PC. Entity A
provides PCS that covers both the operating system and the productivity software.
Because the hardware (nonsoftware component) and operating system (software component) function
together to deliver the PC’s essential functionality, these components are excluded from the scope of ASC
985-605.
The productivity software is a software deliverable that is not considered essential to the PC’s functionality
and therefore is within the scope of ASC 985-605.
Since the PCS relates to components both within (productivity software) and outside (operating system) the
scope of ASC 985-605, it must be bifurcated into a software component and a nonsoftware component
using the amended measurement and allocation guidance in ASC 605-25.
Included above are examples illustrating
the amended provisions of ASC 985-605.
The amendments set forth in ASU
2009-14 are effective prospectively for
revenue arrangements entered into
or materially modified in fiscal years
beginning on or after June 15, 2010. An
entity may elect, but is not required, to
adopt the amendments set forth in ASU
2009-14 retrospectively for prior periods.
An entity must adopt the amendments
set forth in ASU 2009-14, in the same
period that it adopts the amendments set
forth in ASU 2009-13 and must use the
same transition method.
2
Do our products fall under software revenue recognition guidance?
How do we determine whether the
software guidance in ASC 985-605
applies?
Many high-tech companies struggle
with determining whether their tangible
products should be accounted for as a
basic multiple-element arrangement as
opposed to being accounted for under the
software revenue recognition rules. The
amendments in ASU 2009-14 simplify
the process of making that determination.
ASU 2009-14 amends the scope of
the software guidance to exclude the
following:
(a) Nonsoftware components of tangible
products
(b) Software components of tangible
products that are sold, licensed
or leased with tangible products
when the software components and
nonsoftware components of the
tangible products function together to
deliver the tangible product’s essential
functionality
(c) Undelivered elements that relate
to software that is essential to the
tangible product’s functionality, as
described in (b)
When we are analyzing the sale
of a tangible product with a software
component, the first question entities
must ask is how they determine
whether the software is essential to the
functionality of the tangible product. The
amended guidance requires entities to
consider the following factors in making
that determination.
• If the entity infrequently sells
the tangible product without the
software components, there is a
rebuttable presumption that software
components are essential to the
functionality of the tangible product.
• Nonsoftware components must
substantively contribute to the
tangible product’s essential
functionality (in other words, the
tangible product cannot just be a
delivery mechanism for the software).
• If an entity sells tangible products
with similar functionality, such
as different models, and the only
substantive difference between the
products is that one product includes
software that the other product does
not, the products are considered
the same product for purposes of
evaluating the factor in the first bullet.
Determining whether software in
a tangible product is essential to its
functionality requires management
to exercise judgment. If software in
a tangible product is essential to its
functionality, the entire product,
including the software, is outside the
scope of ASC 985-605 and is instead
within the scope of ASC 605-25. Each
software deliverable in an arrangement
must be evaluated to determine whether
it is essential to the functionality of the
product. Some arrangements include
software deliverables that are essential to
the product’s functionality that are within
the scope of ASC 605-25, along with
nonessential software deliverables that are
within the scope of ASC 985-605.
The following examples illustrate the
determination of whether the software
component is essential to the functionality
of the tangible product (Example 3).
• If an entity sells a tangible product
with software but also sells the
software on a stand-alone basis, the
separate sale of the software does
not affect the evaluation of whether
the software is essential to the
functionality of the tangible product.
• Software elements are not required to
be embedded within a product to be
considered essential to the product’s
functionality.
Example 3
Entity A sells a medical device with diagnostic software. The diagnostic software, along with the device, provides
the device’s essential functionality. The entity does not sell the device without the diagnostic software.
Entity A concludes that the medical device and diagnostic software function together to deliver the tangible
product’s functionality. Both elements would be outside the scope of ASC 985-605.
3
Do our products fall under software revenue recognition guidance?
Example 4
Using the facts from the example above, assume that Entity A sells the diagnostic software separately but does
not sell the medical device without the diagnostic software.
Entity A concludes that the diagnostic software is essential to delivering the functionality of the medical device
and that the medical device with the embedded diagnostic software is outside the scope of ASC 985-605.
However, an arrangement to sell the diagnostic software without the medical device would be within the scope of
ASC 985-605 because the amendments to ASC 985-605 provide a scope exception only for software sold with
a tangible product.
Example 51
Entity A sells a personal digital assistant (PDA). The PDA provides several functions — such as a phone, a
camera, and computing functionality — that allow the user to access and use various software programs such
as a music player and games. The PDA contains an operating system that allows the customer to access the
functionality of the device, which includes the ability to use software that is necessary to provide the phone, the
camera and other functionality. The phone and camera software are frequently included on the PDA, but the
music player and game software are excluded more than infrequently. The phone, the camera and the music
player software are not sold separately, but the game software is sold separately.
The PDA hardware, operating system, phone, and camera software are essential to the functionality of the PDA
and would be considered one deliverable that is outside the scope of ASC 985-605. The music player and game
software would be considered software deliverables within the scope of ASC 985-605 because these products
are also sold more than infrequently without the PDA. Whether the software is sold separately does not affect the
conclusion in this example.
Determination of whether the
revenue transaction is within the scope
of ASC 985-605 can become even more
complicated when there are additional
software components included with the
tangible product (Example 5).
The software component need not be
preloaded or embedded in the tangible
product in order to qualify for the scope
exception created by ASU 2009-14
(Example 6).
Given the growing prevalence
of software in high-tech products,
determining the proper revenue
recognition guidance to follow is
becoming increasingly important. The
issuance of ASU 2009-14 should cause
companies to revisit the portfolio of
products they offer and what role, if any,
software plays in the functionality of
those products. An upfront investment
in a detailed analysis of transactions and
which revenue recognition guidance to
apply, will most likely save a lot of effort
down the road. •
Example 62
Entity A sells networking equipment that provides energy companies with the ability to remotely monitor and
manage their customers’ energy use. Entity A sells an integrated package of equipment and software that
consists of a monitoring device that is placed at the energy company’s customer location to collect data that
it then relays back to the energy company’s remote location and software that allows the energy company
to analyze the data and interface with its billing system. The software is installed on the energy company’s
computer system, which is not purchased from Entity A. The equipment does not have functionality without the
software; conversely, the software does not have functionality without the equipment. The vendor’s customers
will initially purchase all of these components together; however, they can also purchase replacement or
expansion equipment or updated versions of the software separately at a subsequent time.
The equipment and software would all be considered nonsoftware elements that are outside the scope of ASC
985-605. The monitoring and relay equipment work together with the software (though not as a physically
combined unit) to deliver the product’s essential functionality and allow the energy company to access and
analyze the data pertaining to its customers’ energy use. Entity A cannot access the functionality of the
equipment without the software. Entity A separately sells the equipment without the software, however, it only
does so in a replacement situation or as the customer base of the energy company expands. The customer
would have needed to acquire the software previously in order for the replacement equipment to function.
Content in this publication is not intended to answer specific
questions or suggest suitability of action in a particular case.
For additional information on the issues discussed, consult a
Grant Thornton client service partner.
www.GrantThornton.com
1
2
TM
This example is drawn from FASB Accounting Standards Codification
Software: Revenue Recognition.
This example is drawn from ASC 985-605-55-230 through 55-231.
(ASC) 985-605-55-220 through 55-221,
© Grant Thornton LLP
All rights reserved
U.S. member firm of Grant Thornton International Ltd
4