AICPA TPA 5290: Accounting for Internal-Use Software
Understand the framework for capitalizing versus expensing software development costs, from on-premise systems to modern cloud computing service contracts.
Understand the framework for capitalizing versus expensing software development costs, from on-premise systems to modern cloud computing service contracts.
The primary guidance for accounting for costs associated with internal-use software in the United States is found in the Financial Accounting Standards Board’s (FASB) Accounting Standards Codification (ASC) 350-40. This standard provides the authoritative U.S. Generally Accepted Accounting Principles (GAAP) on the topic. The American Institute of Certified Public Accountants (AICPA) also offers non-authoritative, interpretive assistance to help financial professionals apply these rules.
This guidance helps a company determine the correct accounting treatment for expenses incurred when developing or acquiring software. It provides a framework for distinguishing between costs that should be immediately expensed and those that should be capitalized. Capitalizing a cost means recording it as a long-term asset on the balance sheet, which is then gradually expensed over its useful life.
The guidance in ASC 350-40 applies to “internal-use software,” defined as software acquired, developed, or modified solely to meet an entity’s internal needs. A condition is that during the software’s development, there is no substantive plan to market it to outside parties. Examples include internal payroll systems, customer relationship management (CRM) platforms, or proprietary production-line software.
The accounting treatment for these costs depends on the nature of the activities when the cost is incurred. The guidance historically established a stage-based model that divides a software project into three distinct stages. The accounting rules differ for each stage.
The accounting for internal-use software costs is dictated by a development lifecycle broken into three stages. Each stage has its own rules for whether costs are expensed immediately or capitalized as an asset.
During the preliminary project stage, all internal and external costs are expensed as incurred. This phase involves the conceptual formulation of the project and the exploration of alternatives. Activities common to this stage include:
The application development stage begins once the preliminary stage is complete and management commits to funding the project. Internal and external costs incurred during this stage are capitalized as an intangible asset. Capitalizable costs include:
After the software is substantially complete and ready for its intended use, it enters the post-implementation-operation stage. Costs incurred during this phase, which relate to ongoing use and maintenance, are expensed as incurred. Common examples include employee training, application maintenance, and customer support. Data conversion costs are also expensed in this stage, unless the activities are necessary to get the software operational during the application development stage.
In 2025, the FASB issued an Accounting Standards Update (ASU) that modernizes the rules for internal-use software. A significant change is the elimination of the three-stage project model to better align the accounting with modern, iterative software development methods like Agile.
Under the new standard, capitalization of software costs begins when management commits to funding the project and it is probable that the project will be completed and used for its intended function. This approach removes the need to map development activities to the previous three-stage model.
The new rules are effective for fiscal years beginning after December 15, 2027, with early adoption permitted. Until a company adopts the new standard, it must continue to follow the three-stage model.
Once software is placed in service and costs have been capitalized, the accounting process shifts to managing the new asset through amortization and impairment testing. These activities are not expected to change significantly under the new ASU.
Capitalized software costs must be amortized, which is the systematic process of expensing the asset’s cost over its estimated useful life. Amortization begins when the software is ready for its intended use. The straight-line method is the most common approach for spreading the cost evenly over each period. Determining the useful life requires judgment and consideration of factors like technological obsolescence and future business plans.
The capitalized software asset must also be reviewed for impairment when events suggest its carrying amount may not be recoverable. For example, if a company decides to replace the software, the unamortized cost may be impaired. If impairment is identified, the company must write down the asset’s value to its fair value and recognize a loss.
The original guidance was developed before cloud computing arrangements like Software-as-a-Service (SaaS) were widespread. These are service contracts where the customer does not own the software. To address this, the FASB issued ASU 2018-15, which covers a customer’s accounting for implementation costs in a cloud computing arrangement.
This guidance requires companies to apply the same capitalization model from ASC 350-40 to determine which implementation costs for a cloud service should be capitalized. Although a company does not own the underlying software, certain costs to implement the service are treated as an asset.
This means that costs for activities like configuring and customizing the cloud software can be capitalized, following either the three-stage model or the new “probable-to-complete” threshold once adopted. The capitalized costs are recorded as a prepaid asset and amortized over the term of the hosting arrangement. Costs for training and data migration related to the cloud service are expensed as incurred.