Add to favorites
ASC 350-40 provides the guidance for software developed or obtained for internal use. The cost guidance in ASC 350-40 is similar to the cost guidance for other long-lived assets with respect to what costs are capitalized and how the costs are subsequently amortized and tested for impairment.
A software license purchased for internal use should be accounted for as an asset for the acquisition of an intangible and a liability, to the extent any or all of the software licensing fees are still outstanding on the acquisition date of the license. The intangible asset acquired should be recognized and measured in accordance with ASC 350-30, Intangibles—Goodwill and Other—General Intangibles Other than Goodwill. See BCG 8.
If a reporting entity is developing, modifying, or implementing software for internal use, the assessment of whether costs should be expensed or capitalized depends on the project stage during which the costs are incurred. The guidance describes the development of internal-use software as having three stages: 
  • Preliminary project (refer to PPE 7.4.1)
  • Application development (refer to PPE 7.4.2)
  • Post-implementation/operation (refer to PPE 7.4.3)
Only costs incurred during the application development stage are eligible for capitalization.
When the software development process does not follow the same order as outlined above, reporting entities should apply the guidance in ASC 350-40 based on the nature of the costs incurred. For example, an agile or iterative software development approach may not have the distinct project stages contemplated in ASC 350-40. In that case, the reporting entity should apply judgment to categorize costs based on the activities being performed (e.g., coding or testing). See PPE 7.4.1 through PPE 7.4.3 for a description of each project stage and examples of activities associated with each stage.
For guidance on the presentation and disclosure of software developed or obtained for internal use, see FSP 8.8.

7.4.1 Accounting for costs in the preliminary project stage

The first stage of development described in ASC 350-40-25 is the preliminary project stage.

Definition from ASC Master Glossary

Preliminary Project Stage: 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 develop a new payroll system or direct their efforts toward correcting existing problems in an operating payroll 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? Should the software run on a mainframe or a client server system?
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.

The following activities are considered to be within the preliminary project stage:
  • Conceptual formulation of ideas and alternatives
  • Evaluation of alternatives
  • Determination of existence of needed technology
  • Final selection of alternatives
These costs are generally incurred in the early stages of a project, when the reporting entity is exploring its technological needs and exploring various alternatives.
Internal and external costs incurred during the preliminary project stage should be expensed as incurred.

7.4.2 Accounting for costs in the application development stage

Once the preliminary project phase has been completed, the next stage of development described in ASC 350-40-25 is the application development stage. This stage is the period between when the preliminary project phase ends (once the specifics of the software have been decided and the software is being developed) and prior to the software being completed and ready for its intended use.
The following activities are considered to be within the application development stage:
  • Design of chosen path, including software configuration and interfaces
  • Coding
  • Installation of hardware
  • Testing, including parallel processing
During this stage, some costs should be capitalized while other costs should be expensed as incurred. ASC 350-40-30-1 specifies the types of costs that can be capitalized.

ASC 350-40-30-1

Costs of computer software developed or obtained for internal-use that shall be capitalized include only the following:
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.

The following types of costs are expensed as incurred, even during the application development stage:
  • Training costs 
  • Data conversion costs (such as employee time spent physically converting data), except for costs to develop or obtain software that allows for access or conversion of old data by new systems. The process of data conversion from an old system to a new one may include purging or cleansing existing data, reconciling the data in the old and new systems, creating new or additional data, and converting old data to the new system.
  • General and administrative costs and overhead costs
If the reporting entity suspends substantially all of the software development activities, interest capitalization should cease until activities are resumed. 
In summary, costs that are directly correlated to the actual development of the software application should be capitalized, while indirect costs related to the software development (e.g., data conversion, general and administrative, overhead) should be expensed as incurred during the application development stage.
Capitalization of qualifying costs during the application development stage should begin when both of the following occur:
  • The preliminary project phase is completed, and
  • Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a project and it is probable that the project will be completed and the software will be used to perform the function intended (e.g., execution of a contract with a third party, approval of expenditures related to internal development, or a commitment to obtain software from a third party).
Capitalization should cease no later than the point at which a software project is substantially completed and ready for its intended use. Software is ready for its intended use after all substantial testing is completed. This may occur before the software is placed in service.
If it is no longer probable that a software project will be completed and placed into service, costs should no longer be capitalized. At that point, the software should be assessed for impairment. Refer to PPE 7.4.6 for additional discussion on the impairment of capitalized internal-use software.

7.4.3 Costs incurred in the post-implementation/operation stage

The next stage of development described in ASC 350-40-25, the post-implementation/operation stage, begins when the internal-use software is ready for its intended use. During this stage, all internal and external training and routine maintenance costs should be expensed as incurred. Accounting for internal-use software upgrades and enhancements

In contrast to maintenance costs (which are expensed as incurred during the post implementation/operation stage), the accounting for specified upgrades and enhancements to internal-use software should follow the same accounting model as that used for new internal-use software (i.e., qualifying costs for the upgrade/enhancement should be capitalized during the application development stage), provided it is probable that the expenditures will result in additional functionality. Additional functionality means that the software modifications enable the software to perform tasks that it previously was not capable of performing. Software enhancement costs incurred that extend the useful life of the software product may qualify for capitalization. ASC 350-40-25-10 indicates that if reporting entities cannot separate costs on a reasonable basis between maintenance and relatively minor upgrades and enhancements, the costs should be expensed as incurred.

7.4.4 Costs incurred for multi-element software arrangements

A reporting entity may enter into a contract with a third party that includes multiple elements, such as a software license, implementation services, hosting services, and training. The consideration paid to the third party should be allocated to each element based on its relative standalone price. After allocation, the accounting for each element (e.g., whether the costs should be capitalized or expensed) will depend on the nature of the cost incurred.
ASC 350-40-30-4 provides guidance on allocating costs to multiple elements in an arrangement. 

ASC 350-40-30-4

Entities may purchase internal-use computer software from a third party or may enter into a hosting arrangement. In some cases, the price includes multiple elements, such as the license or hosting, 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. Entities shall allocate the cost among all individual elements. The allocation shall be based on the relative standalone price of the elements in the contract, not necessarily separate prices stated within the contract for each element. Those elements included in the scope of this Subtopic shall be accounted for in accordance with the provisions of this Subtopic.

The concept of “relative standalone price” is similar to the concept of “relative standalone selling price” described in ASC 606 (see RR 5.2 and RR 5.3). It represents the price at which a reporting entity would purchase an element of a contract separately. Determining the relative standalone price of the various elements in the contract may require the use of estimates. Management should consider all relevant information, such as information from the negotiation process with the vendor, in estimating the standalone price. A reporting entity should not assume that the price stated within the contract represents the standalone price.
In some arrangements, a reporting entity may pay a third party one monthly payment for services received under a cloud computing arrangement (see PPE 7.5). A reporting entity should consider whether the monthly fee includes payment for upfront services, such as implementation services, and allocate the consideration accordingly.
Example PPE 7-4 illustrates the accounting for the different elements within a multi-element software arrangement. 
Accounting for the elements within a multi-element software arrangement
Data Analytics Co enters into an agreement with Software Co to license on-premise data analytics software. The contract also includes routine maintenance of the software and training for employees of Data Analytics Co. Additionally, Data Analytics Co engages the same vendor to perform data migration and configuration services as part of implementing the new software. The total contract price is $101,000. 
Software Co offers the software and maintenance services separately for $84,000 and $10,500, respectively. Software Co does not offer the training, data conversion, and configuration services separately; however, Data Analytics Co obtained information about pricing from other vendors in the vendor selection process. Data Analytics Co uses this information to estimate standalone prices for the training, data conversion, and configuration of $8,000, $10,000, and $4,500, respectively. 
What is the appropriate accounting for each element in the agreement by Data Analytics Co?
Data Analytics Co should allocate the contract price of $101,000 to each of the elements in the contract based on their relative standalone price. 
Software license:
$72,513    ($101,000 x ($84,000 / $117,000))
$9,064    ($101,000 x ($10,500 / $117,000))
$6,906    ($101,000 x ($8,000 / $117,000))
Data conversion:
$8,632   ($101,000 x ($10,000 / $117,000))
$3,885   ($101,000 x ($4,500 / $117,000))
The amounts allocated to the on-premise software license, as well as the configuration services, should be capitalized in accordance with internal-use software guidance. The amount allocated to maintenance, training, and data conversion services should be expensed as incurred. If Data Analytics Co prepays for these services, they should be initially recognized as a prepaid expense.

7.4.5 Amortization of capitalized internal-use software

Capitalized internal-use software costs should be amortized over the estimated useful life of the software, generally on a straight-line basis, unless another systematic and rational basis is more representative of the software’s use. ASC 350-40-35-5 provides the factors to consider in determining the appropriate life.

ASC 350-40-35-5

In determining and periodically reassessing the estimated useful life over which the costs incurred for internal-use computer software will be amortized, entities shall consider the effects of all of the following:
a. Obsolescence
b. Technology
c. Competition
d. Other economic factors
e. Rapid changes that may be occurring in the development of software products, software operating systems, or computer hardware and whether management intends to replace any technologically inferior software or hardware.
Given the history of rapid changes in technology, software often has had a relatively short useful life.

Amortization of internal-use software should begin when the software is ready for its intended use, regardless of whether the software has actually been placed in service. As discussed in PPE 7.4.2, software is ready for its intended use after all substantial testing is completed.
Commencement of amortization should be assessed at the module or component level. ASC 350-40-15-2 provides an example of an accounting software system that contains separate modules, including a general ledger, an accounts payable subledger, and an accounts receivable subledger. In this example, each element might be viewed as a module of the entire accounting software system.
When the functionality of a software module is entirely dependent on the completion of other modules (that are not yet designed, but for which completion is probable), amortization should not begin until all of the modules on which functionality is dependent are ready for their intended use.
Question PPE 7-4 addresses when amortization should begin on a developed software module that is not dependent on the completion of other modules.
Question PPE 7-4

Company A begins to use software that it developed and is functional on a standalone basis. Company A plans to develop four additional modules that will provide additional functionality to the software. When should amortization begin on the developed software module?
PwC response
Because the initial software module has standalone functionality that is not dependent on the completion of the other modules, amortization should begin when the initial software module is completed and ready for its intended use. 

7.4.6 Impairment of capitalized internal-use software

Internal-use software assets generally should be tested for impairment in accordance with the guidance in ASC 360-10-35 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.
Impairment testing is performed when a triggering event has been identified. 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 additional triggering event considerations for capitalized software.

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:
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. Internal-use software not probable of completion

Even when an asset group containing internal-use software is 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.

ASC 350-40-35-3

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

As indicated in the guidance, software being developed that is no longer probable of development should be reported at the lower of cost or fair value less cost to sell. There is a rebuttable presumption that uncompleted software has no value.
Similar to the assessment of amortization commencement, the assessment of impairment for uncompleted software is performed at the module or component level.

7.4.7 Licensing internal-use software to customers

As discussed at PPE 7.2.2, if a reporting entity has a substantive plan to market internal-use software to customers, the software costs are in the scope of ASC 985-20 (refer to PPE 7.3). In some circumstances, a reporting entity that previously had no plan to license internal-use software to other parties will make a subsequent decision to license or sell that software. If a reporting entity licenses the internal-use software to another party, the proceeds received from the license of the software, net of direct incremental costs of marketing (e.g., commissions, software reproduction costs, warranty and service obligations, installation costs) should be applied first against the book value of the capitalized internal-use software costs. No profit should be recognized until aggregate proceeds from the licenses and amortization have reduced the carrying amount of the software to zero. Subsequent proceeds should be recognized as earned.
If during the development of internal-use software, a reporting entity decides to market the software to others, the software industry guidance in ASC 985-20 should be followed on a prospective basis. As discussed in PPE 7.2.2, if the decision to market internal-use software becomes a pattern, it may be difficult to assert that the reporting entity does not intend to sell, lease, or otherwise market future software development projects. Refer to PPE 7.3 for additional information on software to be sold, leased, or otherwise marketed.
Example PPE 7-5 illustrates the accounting for the subsequent license of internal-use software to other parties.
Accounting for the license of internal-use software to other parties
Retail Co is a national retail enterprise that has agreed to sell its stores located in the northeast region to a third-party purchaser. As part of this sale, the purchaser will license a software package that Retail Co had previously developed for its internal use. Retail Co had never intended to market/license the software externally; therefore, the software development costs were capitalized based on the guidance for internal-use software. To facilitate the transfer of the purchased operations, Retail Co has agreed to license the software to the purchaser for one year at a market rate of $100,000. The book value of the internally developed software is $5,000.
What is the appropriate accounting for the licensing of Retail Co's internal-use software?
In accordance with ASC 350-40-35-7, the $100,000 received from the license of the software should be applied first against the book value of the capitalized internal-use software development costs ($5,000). The remaining $95,000 should be recognized in revenue as earned.


Welcome to Viewpoint, the new platform that replaces Inform. Once you have viewed this piece of content, to ensure you can access the content most relevant to you, please confirm your territory.

Your session has expired

Please use the button below to sign in again.
If this problem persists please contact support.

signin option menu option suggested option contentmouse option displaycontent option contentpage option relatedlink option prevandafter option trending option searchicon option search option feedback option end slide