Technology Spotlight — Scoping Considerations Related to Accounting for Software and Software-Related Costs (June 2020)

Scoping Considerations Related to Accounting for Software and Software-Related Costs

The Bottom Line

An increasing number of business processes are automated and therefore involve some software or software-related costs. Such costs can include those to develop solutions internally or through contracted third-party developers, or to procure on-premise or cloud-based software from a vendor.
These software costs will primarily be subject to the guidance under ASC 985-201 or ASC 350-40. The application of the incorrect guidance could materially affect the accounting for these costs because each standard has different capitalization requirements for costs incurred in different stages of software development.
Software offerings continue to evolve rapidly, resulting in complex fact patterns that will require judgment. Entities will need to regularly reassess the nature of the costs being incurred and the ways in which they use software solutions or market software offerings to their customers to ensure the application of the correct accounting guidance.

Beyond the Bottom Line

This Technology Spotlight discusses scoping considerations for entities determining whether software and software-related costs incurred should be accounted for under ASC 985-20, ASC 350-40, or other U.S. GAAP. This is the first publication in a series that will further examine the application of the relevant guidance, including common issues and complexities.

Background

As technology evolves, entities typically incur myriad costs related to software. For example, cloud-based arrangements have revolutionized the business and technology landscape, offering more flexible and often lower-cost IT solutions that allow businesses to outsource their traditional enterprise resource planning (ERP) systems or any other on-site application to an off-site, on-demand solution. In addition, an increasing number of processes are managed by using automated solutions, such as customer relationship management (CRM), human resources, payroll, finance, and collaboration and communication tools. This has resulted in entities’ incurring increasing amounts of software-related costs as they either purchase licenses to on-premise software products or contract with vendors to access and use software solutions over the Internet (e.g., cloud computing or software as a service (SaaS)). Entities also frequently use hybrid deployments, in which they purchase or develop on-premise software (some of which may be deployed in a private cloud environment) and use that software in conjunction with another cloud-based third-party platform (i.e., a public cloud). Further, entities may incur costs to develop software for their own internal use as well as for external sales to customers. Entities incurring such costs will need to determine whether they represent assets that can be capitalized under the applicable accounting standards. Different accounting guidance exists for costs related to software that is (1) sold, leased, or marketed; (2) obtained or developed for internal use; and (3) accessed in a cloud-based (or hosting) arrangement that is a service contract.

It is important to determine whether software costs incurred are within the scope of ASC 985-20 or ASC 350-40 because the requirements for capitalization vary significantly between the two standards. For example, ASC 985-20-25-1 states that “[a]ll costs incurred to establish the technological feasibility of a computer software product to be sold, leased, or otherwise marketed are research and development costs.” Once technological feasibility is established, the costs of producing product masters, including coding and testing, are generally capitalized until the product is available for general use.2 Because technological feasibility is often established shortly before the software product reaches the GA (general availability) stage, many software entities do not have material costs capitalized under ASC 985-20.

By contrast, ASC 350-40 does not require the establishment of technological feasibility for capitalization but does have other requirements for capitalization depending on the stage of development. Generally, development costs incurred during the application development stage are capitalized, while costs incurred during the preliminary-project and post-implementation-operation stages are expensed as incurred. Costs incurred for internal-use software will typically meet the capitalization requirements earlier in the development cycle than costs incurred for software licensed externally. As a result, more costs typically qualify for capitalization when software is obtained or developed for internal use than those for software that is licensed externally. Further, ASC 350-40 also applies to implementation costs incurred for cloud-based (or hosting) arrangements that are service contracts. Generally, implementation costs incurred for such arrangements during the application development stage are deferred, while other costs (e.g., cloud computing and hosting costs) are expensed as incurred (unless they are related to other capitalizable assets such as hardware and on-premise software). Within ASC 350-40, guidance differs for cloud-based (or hosting) arrangements versus internal-use software (e.g., only implementation costs for cloud-based [or hosting] arrangements are eligible for deferral, and there are different presentation requirements).

Because of the above differences in capitalization requirements, the application of the incorrect guidance could have material accounting implications. In addition, complexities may arise when entities evaluate the appropriate scoping as technology evolves and business models shift. For example, entities may transition from using software solutions internally to selling and marketing them. Similarly, entities may shift their business model from selling on-premise licensed solutions to SaaS arrangements. It is therefore important to understand the scoping guidance and regularly reassess previous scoping conclusions in a dynamic environment.

This publication is written on the assumption that an entity has adopted ASU 2018-15.3 For public business entities, the ASU is effective for annual periods, including interim periods within those annual periods, beginning after December 15, 2019. For all other entities, the ASU is effective for annual periods beginning after December 15, 2020, and interim periods in annual periods beginning after December 15, 2021. Early adoption is permitted.

Determining the Appropriate Guidance

On-Premise Licensed Software

ASC 985-20-15-2 states that ASC 985-20 applies to the costs of “computer software to be sold, leased, or otherwise marketed as a separate product or as part of a product or process, whether internally developed and produced or purchased.” Typically, software within the scope of ASC 985-20 is licensed on a nonexclusive on-premise basis, either as a perpetual or term-based (i.e., subscription-based) license, with the sale of such software accounted for under ASC 606.

In assessing how software development costs should be accounted for, entities must determine whether there is a substantive plan to market the software externally or whether one will be created during the software’s development period. If either is the case, the software development costs will be subject to ASC 985-20. See No Substantive Plan to Market the Software Externally below.

Connecting the Dots

Some on-premise software applications, such as mobile applications (apps), may not be licensed for consideration. In those circumstances, an entity must carefully evaluate whether the software is considered “sold, leased, or otherwise marketed as a separate product or as part of a product or process” under ASC 985-20. For example, an entity may sell gaming apps for consideration, and such apps would therefore be within the scope of ASC 985-20. However, gaming apps may also be offered on a “freemium” basis, with in-app sales (e.g., consideration paid to play a game without viewing ads or for virtual items that enhance the gaming experience). Even though a gaming app itself is free for download, we believe that it would still be considered “marketed as a separate product,” particularly since there could be in-app sales for consideration. Further, apps may be sold as part of a product or process (see Software That Is Part of a Product or Process below). For example, a thin-client app may be sold as part of a cloud-based service, but if its sole function is to enable connection to the cloud-based service, it may not be substantive enough to be considered “sold, leased, or otherwise marketed.” Therefore, an entity may need to use judgment to determine whether apps that are free for download or part of a product or process are within the scope of ASC 985-20. If they are not within the scope of ASC 985-20, they could be within the scope of ASC 350-40 (see Internal-Use Software below).

Software Product

A software product is defined by ASC 985-20-55-1 as having the following qualities:

“As a product, it is complete and has exchange value.”
“As software, it is a set of programs that interact with each other. A program is further defined as a series of instructions or statements that cause a computer to do work.”

A software product is a set of programs (e.g., software code) that has been packaged in such a way that it can be marketed to third parties. The software product may be sold to either end users or distributors. A software product also consists of the appropriate documentation and training materials. Determining whether a set of programs consists of a single software product or multiple software products requires judgment since ASC 985-20 does not provide specific guidance on the unit of accounting.

When determining separate software products, an entity should consider how programs are marketed. A set of programs that is separately priced and marketed would most likely be treated as a separate software product. For example, programs may be packaged and priced differently depending on the market (e.g., different geographic areas or industries). In that circumstance, each set of packaged programs may be a separate software product, with costs identified and allocated through the use of a reasonable method.

An entity could also consider the functionality and interdependence of its programs. For example, two sets of technically independent programs, for which costs can be separately identified and a basis for allocating revenue can be established, may be two separate software products. A set of programs is technically independent if other programs are not essential to the set’s functionality. Therefore, the entity might be able to market that set as a separate software product because customers will be able to effectively use it without any other programs. By contrast, sets of programs that are technically interdependent may not be marketed separately. For example, if a set of programs has been developed but has no stand-alone functionality without the development of additional programs, it most likely would not be a separate software product.

A newly developed set of programs could be combined with an existing separate software product if it is integrated with and intended to replace that product. In addition, modules or add-ons with different features and functions can be developed for an existing separate software product. If a set of programs associated with a module or add-on is separately priced, it may be treated as its own separate software product. However, if that set of programs is not priced separately and revenue cannot be reasonably allocated to it, it should be treated as part of the existing software product.

A software product can either be developed by an entity’s own employees or by third parties. A developer also can acquire an existing software product from a third party. Because there is no specific ownership requirement in ASC 985-20, an entity may obtain the marketing rights to licensed software (e.g., as a reseller or distributor), and the amount paid to obtain those rights would be a cost of a separate software product (or part of another software product) as though the entity had acquired or developed the program itself (i.e., as though it owned the intellectual property outright).

Software That Is Part of a Product or Process

While software often is sold as a product that has stand-alone functionality (e.g., software used to process tax returns), software may also be embedded as part of another product that is sold, such as firmware that is embedded in smart devices (e.g., smartphones, tablets, gaming consoles, and other devices associated with the IoT (Internet of Things)).

Further, software could be sold as part of a process. While not specifically defined in ASC 985-20, a process is described in ASC 730-10-15-3 as “a system whose output is to be sold, leased, or otherwise marketed to others. A process also may be used internally as a part of a manufacturing activity or a service activity where the service itself is marketed.” Therefore, if on-premise software is sold as part of a service, it would be subject to ASC 985-20. For example, an entity could sell a customer on-premise payroll software that enables the entity to provide payroll and tax services to that customer (i.e., the customer uses the on-premise software in connection with the payroll and tax services it receives from the entity).

Connecting the Dots

Determining whether software is sold as part of a product or process could require judgment. If software is used in the design, development, or manufacturing of a separate product or service, the software would not be within the scope of ASC 985-20 unless that software is included in the product or service sold. For example, if software is used to produce an architectural blueprint but only the output associated with the blueprint is sold to a customer, that software would not be within the scope of ASC 985-20. On the other hand, if the software is also provided with the architectural blueprint sold to the customer so that the customer can modify the architectural blueprint, that software would be within the scope of ASC 985-20.

Software Sold as Part of a Hosting Arrangement

Sometimes, software may be sold as part of a hosting arrangement,4 such as SaaS that is accessed via an online portal. If so, the software is subject to ASC 985-20 only if both of the following criteria in ASC 985-20-15-5 are met:

The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
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.

Connecting the Dots

Some may question whether “at any time” during the hosting period means at every point of time during the hosting period. We do not believe that to be the case. For example, an entity’s arrangements may specify that the customer will automatically obtain the software at the end of the hosting period. As long as the customer can take possession of the software at that point without significant penalty and it is feasible for the customer to run the software (either on its own or with a third-party vendor), we believe that the software license is a separate promise in the hosting arrangement and would therefore be subject to ASC 985-20.

If the above criteria are met, an entity (i.e., the vendor) would account for only the software costs under ASC 985-20. It would account for costs associated with hosting the software separately under other U.S. GAAP. For example, if the entity purchases servers to provide the hosting service, it would account for those servers as long-lived assets under ASC 360.

ASC 985-20-15-6 states that in determining whether the customer has the contractual right to take possession of the software without significant penalty, the entity must evaluate whether the customer is able to (1) “take delivery of the software without incurring significant cost” and (2) “use the software separately without a significant diminution in utility or value.” This analysis depends on the facts and circumstances of the arrangement and requires judgment. The entity may consider the following factors (not all-inclusive) in making this assessment:

Contractual cancellation fees associated with the hosting arrangement.
Other contractual penalties for taking possession of the software (e.g., the requirement that the customer continue to pay the hosting fees for the remainder of the hosting term even though hosting services are terminated).
Costs to transition the software to the customer (to be used on the customer’s own servers) or to the customer’s third-party vendor (to be hosted by that vendor).
Whether the utility and value of the software can be maintained upon transition (e.g., whether the customer will continue to receive updates, upgrades, and enhancements).
Whether the software (1) has stand-alone functionality (on its own or with readily available resources) or (2) is significantly tied to other products or services that can be provided only by the entity and will no longer be provided if the customer takes possession of the software.

Determining whether a penalty or diminution in utility or value is “significant” also depends on the facts and circumstances of the arrangement and requires judgment. Significance can be evaluated both quantitatively and qualitatively. The accounting literature does not contain specific guidance on (1) which elements of the contract should be included in the measurement of the amount of the penalty or (2) the benchmark against which the entity should measure the amount of the penalty when determining whether the penalty is quantitatively significant. An entity may have an established policy for determining whether the penalty is significant. For example, in a manner consistent with other Codification subtopics, the entity may reasonably conclude that amounts above 10 percent of a given benchmark are significant. Establishing a method of determining both the elements of the contract to include in the measurement of the penalty and the benchmark against which to measure the penalty is an accounting policy decision that the entity should apply consistently.

If the criteria in ASC 985-20-15-5 are not met (i.e., the customer does not receive on-premise software), the entity accounts for the software costs under ASC 350-40 as internal-use software. However, the entity must evaluate all its arrangements. If it has other substantive arrangements in which the same software is sold, leased, or marketed (i.e., sold as on-premise software), the entity must account for the software costs under ASC 985-20 (see Transition Between Internal-Use Software and On-Premise Licensed Software below).

Internal-Use Software

ASC 350-40-15-2A describes internal-use software as having both of the following characteristics:

The software is acquired, internally developed, or modified solely to meet the entity’s internal needs.
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 contain the following examples of fact patterns in which software is for internal use or not for internal use:

55-1 The following is a list of examples illustrating when computer software is for internal use:

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.
An entity develops software that helps it improve its cash management, which may allow the entity to earn more revenue.
An entity purchases or develops software to process payroll, accounts payable, and accounts receivable.
An entity purchases software related to the installation of an online system used to keep membership data.
A travel agency purchases a software system to price vacation packages and obtain airfares.
A bank develops software that allows a customer to withdraw cash, inquire about balances, make loan payments, and execute wire transfers.
A mortgage loan servicing entity develops or purchases computer software to enhance the speed of services provided to customers.
A telecommunications entity develops software to run its switches that are necessary for various telephone services such as voice mail and call forwarding.
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.
A broker-dealer entity develops a software database and charges for financial information distributed through the database.
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.
An entity purchases software to computerize a manual catalog and then sells the manual catalog to the public.
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.

55-2 The following list provides examples of computer software that is not for internal use:

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.
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.
A semiconductor entity develops software embedded in a microcomputer chip used in automobile electronic systems.
An entity purchases software to computerize a manual catalog and then sells the computer version and the related software to the public.
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.
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.
A telecommunications entity purchases computer software to be used in research and development activities.
An entity incurs costs to develop computer software for another entity under a contract with that other entity.

In many cases, it will be obvious that software is obtained or developed solely to meet an entity’s internal needs (e.g., 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 the manner in which 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.

Connecting the Dots

ASC 350-40-15-2 provides an example of an accounting software system that contains separate components or modules, including a general ledger, an accounts payable subledger, and an accounts receivable subledger. Determining the appropriate components or modules is important because the assessment of amortization and impairment for abandonments is performed at the component or module level. In addition, components or modules of a particular software system may be at different stages of development, and costs would need to be separately tracked, particularly in agile development environments.

Software Is Purchased for Internal Use as Part of a Hosting Arrangement

An entity may obtain internal-use software as part of a hosting arrangement with a vendor. If so, ASC 350-40-15-4A states that the software costs are subject to ASC 350-40 if both of the following criteria are met:

The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
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 criteria above are the same as those in ASC 985-20-15-5 (see Software Sold as Part of a Hosting Arrangement above). If the criteria are met, the costs associated with the purchase or license of the software are subject to ASC 350-40. If the criteria are not met, the arrangement is a service contract (see Cloud-Based (or Hosting) Service Arrangements below).

Connecting the Dots

It is common for software to be hosted on a third-party platform or infrastructure (i.e., not the vendor’s or customer’s on-site platform or infrastructure). In these circumstances, it is important to determine who has the contract with that third party (i.e., whether it is the vendor’s or customer’s cloud instance of the third-party platform or infrastructure). If the software is hosted on an entity’s (i.e., a customer’s) cloud instance, the entity has possession of the software, and the costs associated with it are subject to ASC 350-40. By contrast, if the software is hosted on the vendor’s cloud instance and the entity (i.e., the customer) cannot otherwise obtain possession of the software without significant penalty, the costs associated with that software are accounted for as a service arrangement and only the implementation costs are subject to ASC 350-40.

No Substantive Plan to Market the Software Externally

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. The software must be intended solely for internal use to be subject to ASC 350-40.

To be considered “substantive,” a marketing plan needs to be sufficiently detailed, and its implementation should be reasonably possible.5 ASC 350-40-15-2B states that a substantive plan “could include the selection of a marketing channel or channels with identified promotional, delivery, billing, and support activities.” It also states that “routine market feasibility studies are not substantive plans to market software.”

Connecting the Dots

When an entity is determining whether it has a substantive plan to market software externally, it must under ASC 350-40 evaluate its past practices and patterns. For example, if the entity has a past practice or pattern of both using software internally and selling that same software externally (or deciding to market internal-use software externally during development), a rebuttable presumption is created that any software developed by the entity is intended for sale, lease, or marketing (i.e., the software costs are subject to ASC 985-20).6

Example 1

Company A, a recording and music distribution company, is developing software that would enable users to listen to, edit, and record music files. Company A plans to use the software to create music albums that it will then sell to customers. Company A is also negotiating with four software resellers to sell them the new product. Company A’s marketing department is compiling a detailed plan and designing promotional material for the new product, and implementation of the marketing plan is considered at least reasonably possible. Therefore, A has a substantive marketing plan and should account for the costs of the new software product under ASC 985-20.

Example 2

Company B is developing software that would enable it to better manage its advertising campaigns. Company B has engaged a market research firm to conduct a market survey to determine whether a market for the new software product exists. The market survey conducted by the market research firm is a routine market feasibility study and not a substantive plan to market the product. Therefore, unless and until there is a substantive plan being developed to market the software to others, B should account for the costs of the software product under ASC 350-40.

Example 3

Company C is developing a data management software platform that will be sold only as a cloud-based arrangement (i.e., as internal-use software; see Software Is Marketed or Sold Only as a Cloud-Based (or Hosting) Arrangement below). It does not have a marketing plan or intent to sell the software on an on-premise basis (i.e., customers will not have the contractual ability to take possession of the software). However, C has a past practice of selling other software products to customers on both a hosted basis and on an on-premise basis, depending on the customer’s request. Therefore, while C has neither a marketing plan nor the intent to sell the data management software on an on-premise basis, its past practice creates a rebuttable presumption that the data management software is intended for sale, lease, or marketing.

Company C considers that recently, it has either transitioned or is in the process of transitioning its customers to using all of its software products on a hosted basis. In addition, for any new or modified arrangements, customers will no longer have the contractual ability to take possession of any of C’s software products. Therefore, C concludes that it can overcome the rebuttable presumption that the data management software is intended for sale, lease, or marketing and the data management software is therefore subject to ASC 350-40.

Software Is Marketed or Sold Only as a Cloud-Based (or Hosting) Arrangement

If software is being marketed or sold only as a cloud-based (or hosting) arrangement, that software would be considered internal-use software. To determine whether the product is considered software to be sold, leased, or marketed, and therefore accounted for under ASC 985-20, see On-Premise Licensed Software above.

Many cloud-based or hosting arrangements include a “license” to software but allow the customer to use the software only in an entity’s hosted environment (because of contractual or practical limitations, or both, to taking possession of the software). The entity’s hosted environment could include its cloud instance on a third party’s platform or infrastructure (i.e., the entity has a contract with a third party to host its software). Although these arrangements may include a contractual license, if the customer is unable to take possession of the software subject to the license without significant penalty, the software is for the entity’s internal use in providing a service to its customers. These transactions are accounted for as service arrangements (rather than licensing arrangements) since the entity is providing the functionality of the software through a hosting arrangement (service) rather than through an actual on-premise software license that is controlled by the customer. Therefore, the costs to develop or acquire such software should be accounted for under ASC 350-40.

Connecting the Dots

ASC 350-40-15-5 specifies that software is for internal use (vs. sold as on-premise software) if it is used to develop a product or provide a service sold to a customer but the customer does not actually acquire the software or a future right to use it.

Example 4

Company D offers its office productivity software solution as a SaaS whereby its customers access the solution through an online portal and store data on D’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 D’s cloud-based service, D concludes that the costs associated with its office productivity software should be accounted for under ASC 350-40.

Example 5

Company E is developing a CRM software solution to be marketed and sold to customers. Company E also intends to use the software internally to manage its communications and relationships with customers and potential customers.

A detailed marketing plan has already been developed for the software. The software will be provided to customers on a hosted basis (i.e., the software will be accessed by using an Internet connection) and will connect to E’s proprietary data analytics platform, which has already been developed and is housed on E’s own servers (i.e., it is a SaaS solution that is accessed only online). Company E’s data analytics platform will be a significant part of the overall solution sold to its customers and will be significantly integrated with the CRM software solution being developed. Company E plans to provide its customers with the contractual ability to take possession of the CRM software on an on-premise basis, when requested at any point during the hosting period, without paying E a penalty or cancellation fee. However, customers will not have the contractual ability to take possession of E’s data analytics platform. In addition, cancellation of the hosting service for the CRM software will also result in the cancellation of the SaaS for E’s data analytics platform, which cannot be easily replicated by the customer or third-party vendors. Further, customers would incur significant costs to integrate the CRM software with other third-party data analytics platforms.

While a customer will have the “contractual right to take possession of the software at any time during the hosting period” without paying E a penalty or cancellation fee, it cannot do so without incurring a significant penalty (i.e., significant diminution in utility or value of the CRM software without E’s data analytics platform). Therefore, E concludes that the software costs incurred to develop the CRM software should be accounted for under ASC 350-40.

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

Transition to Licensing Software Externally

After the development of internal-use software, an entity 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 (inclusive of 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).7 Any subsequent software development costs for that software product are then subject to ASC 985-20.

If the decision to market the software externally happens 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.8

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, questions on scoping have arisen in situations in which an entity predominantly sells and provides a software solution through cloud-based arrangements. As long as there continue to be substantive external sales of on-premise software, we believe that the software costs should still be subject to ASC 985-20. If, instead, an entity no longer has substantive external sales of on-premise software, neither ASC 985-20 nor ASC 350-40 provides transition guidance. In that circumstance, we believe that it is reasonable to account for any future software development costs 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 an entity may apply judgment in determining whether there are any substantive external sales of on-premise software.

Hybrid Cloud-Based Software Solutions

Many entities 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.

In these situations, an entity 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.

Example 6

Company F has a database management system, which is software that it uses in delivering its information services to customers through an online portal. The system collects data from real-time feeds, news sources, and contributed data sources. Company F also sells an on-premise license to its data analytics and machine learning software product, which includes an interface to F’s database management system and is downloaded on a customer’s servers.

The costs incurred in connection with the database management system are within the scope of ASC 350-40. However, the costs of the data analytics and machine learning software product, which resides on a customer’s servers, are accounted for under ASC 985-20. Therefore, F should separately track its software costs for each software solution.

Cloud-Based (or Hosting) Service Arrangements

An entity may enter into a cloud-based (or hosting) arrangement with a vendor (typically for internal use). In determining whether it has purchased a software license or a service arrangement, the entity must evaluate the same considerations as described in Software Is Purchased for Internal Use as Part of a Hosting Arrangement above. If the entity (1) 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,” the entity has entered into a service contract.9 In this circumstance, only implementation costs incurred would be subject to ASC 350-40. An entity 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.”

Connecting the Dots

When an entity incurs implementation costs for a cloud-based (or hosting) service arrangement, it may also purchase or develop internal-use software as part of that implementation. In that circumstance, the entity should separately account for the costs incurred for that internal-use software under ASC 350-40.

Multiple-Element Arrangements

Entities 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, cloud-based services, and professional services). ASC 350-40-30-4 requires entities to allocate the cost to all individual elements on the basis of their stand-alone prices.10

Example 7

Company G purchases a three-year noncancelable software subscription from Vendor H that enables G to manage its data center (e.g., manage various IT workloads). The software can operate (1) on different types of commodity hardware that G can purchase and use on its own premises or (2) through cloud computing arrangements (both the hardware and cloud computing services can be purchased from various third-party vendors and are not part of the arrangement between G and H). The subscription arrangement includes a three-year term-based license that is delivered digitally (it can be downloaded on G’s own servers or third-party servers if G chooses to access it through its vendor’s cloud computing platform), as well as support and maintenance over the three-year term. Company G also purchases professional services, including training and business process reengineering services, from H in the same subscription arrangement. Company G determines that there are three elements in the arrangement and allocates the total consideration payable to H to those elements on the basis of their relative stand-alone prices. The three elements are accounted for as follows:

Because G takes possession of the on-premise term-based software license, the amount allocated to it is capitalized as internal-use software under ASC 350-40. The capitalized software cost is then amortized on a straight-line basis over the three-year term and is subject to the impairment guidance in ASC 360.
The amount allocated to the support and maintenance is expensed over the three-year term. If G prepays for the support and maintenance, it is initially recognized as a prepaid expense.
The amount allocated to the professional services is expensed as incurred. If G prepays for the professional services, it is initially recognized as a prepaid expense.

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.

Web Site Development Costs

Web site development costs 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.

Software Used for Research and Development Activities

If software is used in research and development activities and does not have alternative future uses, it is subject to ASC 730-10. In addition, the following software costs are accounted for as research and development costs:

For software subject to ASC 985-20, all costs incurred before the establishment of technological feasibility.11
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”).12
For software subject to ASC 350-40, all costs associated with a particular research and development project, “regardless of whether the software has alternative future uses.”13

Example 8

Company J is trying to implement a supply management system by using blockchain technology but is not certain that the supply management system can be designed to meet J’s internal requirements. Company J has decided to implement its system at one of its smaller facilities for 90 days to determine whether the system will function as intended.

A project of this nature would be considered a pilot project and accounted for as research and development because J is implementing a software system, intended for company-wide implementation, on a small scale. Often these pilot projects are implemented at locations at which the risk of loss is very low or the cost to run parallel systems is not significant.

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

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.

Business Process Reengineering Activities

An entity 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.

Importance of Ongoing Reassessment of Software Costs

As described above, there are various ways in which an entity’s evolving business models may affect which guidance applies when accounting for costs to develop or acquire software. These include changes in the manner in which entities 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 an entity 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.

Appendix — Flowchart for Determining the Appropriate Guidance

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

Contacts

If you have questions about this publication, please contact the following Deloitte industry professionals:

Sandie Kim Audit & Assurance Partner National Office Accounting and Reporting Services U.S. Technology Deputy Industry Professional Practice Director Deloitte & Touche LLP sandkim@deloitte.com	Kaetlin Liverman Audit & Assurance Senior Manager National Office Accounting and Reporting Services Deloitte & Touche LLP kliverman@deloitte.com
Michael Wraith Audit & Assurance Partner U.S. Technology Industry Professional Practice Director Deloitte & Touche LLP mwraith@deloitte.com	Mohana Dissanayake Audit & Assurance Partner U.S. Technology, Media & Telecommunications Industry Leader Deloitte & Touche LLP mdissanayake@deloitte.com
Previn Waas Audit & Assurance Partner U.S. Software Industry Leader Deloitte & Touche LLP pwaas@deloitte.com

Footnotes

For titles of FASB Accounting Standards Codification (ASC) references, see Deloitte’s “Titles of Topics and Subtopics in the FASB Accounting Standards Codification.”

Production costs for software that is to be used as an integral part of a product or process cannot be capitalized until both (1) technological feasibility has been established and (2) all research and development activities for the other components of the product or process have been completed.

FASB Accounting Standards Update (ASU) No. 2018-15, Customer’s Accounting for Implementation Costs Incurred in a Cloud Computing Arrangement That Is a Service Contract.

A hosting arrangement is defined in the ASC master glossary as being “[i]n connection with accessing and using software products, an arrangement in which the customer of the software does not currently have possession of the software; rather, the customer accesses and uses the software on an as-needed basis.”

The ASC master glossary defines reasonably possible as “[t]he chance of the future event or events occurring is more than remote but less than likely.”

See ASC 350-40-15-2C and ASC 350-40-35-10.

See ASC 350-40-35-7 and 35-8.

See ASC 350-40-35-9.

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

A stand-alone price is defined in ASC 350-40-20 as the “price at which a customer would purchase a component of a contract separately.”

See ASC 985-20-25-1.

See ASC 350-40-15-7(b)(1) and ASC 730-10-55-1(h).

See ASC 350-40-15-7(b)(2).