Search within this section
Select a section below and enter your search term, or to search all click Software
Favorited Content
3.8 Impairment of capitalized internal-use software costs
Publication date: 31 Dec 2021
us Software costs
Internal-use software assets generally should be tested for impairment as part of the related asset group in accordance with the guidance in ASC 360, Property, Plant, and Equipment, related to the impairment of long-lived assets. This guidance applies to software that has been developed (or is probable of being completed). See PPE 5 for more information on long-lived asset impairments.
In order to assess long-lived assets for impairment, assets are required to be grouped at the lowest level for which there are identifiable cash flows that are largely independent of the cash flows from other groups of assets (i.e., the asset group level). Internal-use software should be assigned to the applicable asset group when the reporting entity performs its long-lived asset impairment tests. See PPE 5.2.1 for details regarding the determination of the asset group.
If a reporting entity commits to a plan to cease use of its internal-use software assets before the end of its previously estimated useful life, those assets should be accounted for in accordance with long-lived assets to be abandoned guidance in ASC 360-10-35-47 and ASC 360-10-35-48. Accordingly, even if the broader asset group does not fail the recoverability test described in ASC 360, the reporting entity should revise the estimated useful life of the internal-use software asset and related amortization in accordance with ASC 250.
Impairment testing is performed when a triggering event has been identified for the asset group or for an individual asset included in the broader asset group (if significant). ASC 360-10-35-21 provides examples of when to test long-lived assets for recoverability and impairment. For further discussion regarding long-lived asset impairment triggers, see PPE 5.2.3. ASC 350-40-35-1 includes examples of triggering events for capitalized software. When a reporting entity identifies an impairment indicator for capitalized software included in a broader asset group, the reporting entity should consider the significance of the asset in relation to the overall asset group and the facts and circumstances surrounding the impairment indicator to determine whether impairment testing at the asset group level may be required. See PPE 5.2.3.1. These impairment indicators are examples and should not be considered the only potential indicators that an asset or an asset group may not be recoverable.
Excerpt from ASC 350-40-35-1
The guidance is applicable, for example, when one of the following events or changes in circumstances occurs related to computer software being developed or currently in use indicating that the carrying amount may not be recoverable:
- Internal-use computer software is not expected to provide substantive service potential.
- A significant change occurs in the extent or manner in which the software is used or is expected to be used.
- A significant change is made or will be made to the software program.
- Costs of developing or modifying internal-use computer software significantly exceed the amount originally expected to develop or modify the software.
3.8.1 Internal-use software not probable of completion
Even when the carrying amount of an asset group containing internal-use software is deemed to be recoverable, capitalized software may need to be impaired if it is no longer probable that the software being developed will be completed. This guidance differs from the model utilized when it remains probable that the software being developed will be completed and placed into service. ASC 350-40-35-3 discusses the accounting when development of the software is no longer probable.
When 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. The rebuttable presumption is that such uncompleted software has a fair value of zero. Indications that the software may no longer be expected to be completed and placed in service include the following:
- A lack of expenditures budgeted or incurred for the project.
- Programming difficulties that cannot be resolved on a timely basis.
- Significant cost overruns.
- 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.
- 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.
- Business segment or unit to which the software relates is unprofitable or has been or will be discontinued.
As indicated in the above guidance, software being developed that is no longer probable of completion should be reported at the lower of cost or fair value less cost to sell. ASC 350-40-35-3 stipulates that there is a rebuttable presumption that uncompleted software has no value. The assessment of impairment for uncompleted software is performed at the module or component level.
PwC. All rights reserved. PwC refers to the US member firm or one of its subsidiaries or affiliates, and may sometimes refer to the PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details. This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.
Link copied
