ASC 350-40 is the FASB standard that tells companies how to account for internal-use software: costs incurred during preliminary planning and after launch are expensed as they occur, while costs incurred during the actual build are capitalized as an intangible asset and amortized over the software’s useful life. That basic split governs financial reporting today, though the FASB has issued ASU 2025-06, which replaces the current stage-based framework for annual periods beginning after December 15, 2027, with early adoption already permitted.1Financial Accounting Standards Board. FASB Accounting Standards Update Effective Dates
What Software the Standard Covers
ASC 350-40 applies when two conditions hold: the company acquired or developed the software for its own operations, and there is no substantive plan to sell or license it externally. Payroll systems, general ledger platforms, internal communication tools, and HR applications are typical examples. If the company later decides to market the software, the accounting shifts to ASC 985-20, which uses a different cost model for software intended for sale or lease.
Judgment calls arise at the edges. A company might build a scheduling tool for internal dispatchers and later discover outside firms would pay for it. As long as no concrete plan to sell existed during development, ASC 350-40 still governs the costs already incurred. When software serves both internal operations and paying customers, the costs may need to be allocated between the two standards based on the software’s primary purpose.
Website development costs currently live under a separate standard, ASC 350-50. ASU 2025-06 folds that guidance into ASC 350-40, so companies developing customer-facing websites or internal portals will eventually apply a single capitalization framework.
The Current Three-Stage Model
Under the rules in effect for most companies through annual periods ending in 2028, a software project has three sequential phases, and each has its own rule about whether costs are expensed or capitalized.
Preliminary Project Stage
This is the evaluation phase. The team debates build versus buy, reviews vendor proposals, compares architectural approaches, and assesses feasibility. All costs during this period are expensed immediately, whether they come from external consultants or internal employee time. At this point the company hasn’t committed to building anything, so there is no asset to record. The preliminary stage ends when management formally selects a technology path and authorizes the project to proceed.
Application Development Stage
Capitalization begins once the organization commits to the project and it is probable the software will be completed and used as intended. This is the actual build: coding, configuration, hardware installation, and integration testing. Eligible costs include:
- External direct costs, such as fees paid to software engineering firms, third-party license purchases needed for the build, and specialized development tools or compilers.
- Internal payroll costs for employees working directly on development. A developer earning $130,000 who spends half their time coding the new system contributes roughly $65,000 in compensation, plus a proportional share of benefits, to the capitalized balance.
- Testing costs, including quality assurance work, stress testing, security audits, and verification against functional requirements.
- Data conversion tools built solely to migrate data into the new system during implementation.
- Interest costs incurred during development, capitalized under ASC 835-20.
General administrative overhead stays on the income statement even if the administrator supports the project team. When employees split time between the software project and other duties, only the hours directly tied to development qualify. Capitalized amounts accumulate as an intangible asset on the balance sheet and get spread across the periods the software will generate value.
Post-Implementation Stage
Once the software is substantially complete and ready for its intended use, capitalization stops and the asset begins amortizing. Spending from that point forward is expensed as incurred, including user training (which improves staff proficiency rather than the software itself), routine maintenance and bug fixes, and ongoing vendor support fees.
The transition is not always a single moment. Large implementations roll out in modules, and each module can reach the ready-for-intended-use threshold at a different time. A company might still be capitalizing costs on Module 3 while expensing maintenance on Module 1, which requires granular project accounting rather than a single bucket for the whole initiative.
Amortization and Useful Life
Capitalized software is amortized over its estimated useful life, generally on a straight-line basis unless another method better represents how the benefit is consumed. ASC 350-40 does not prescribe a default useful life. The company picks a period based on its own assessment of how long the software will remain in productive service.
The pace of technological change keeps useful lives relatively short for most business software. Factors that inform the estimate include expected obsolescence, the rate of change in the relevant technology, competitive pressures, and any management plan to replace the system within a defined horizon. Amortization begins when the software (or a discrete module) is ready for its intended use.
Residual value is almost always zero. Proprietary software built for a specific company’s workflows has no secondary market, so the full capitalized cost amortizes down to nothing.
Upgrades Versus Maintenance After Launch
Not every post-launch dollar is automatically expensed. When a modification adds significant new functionality the software did not previously have, those costs follow the same capitalization rules as the original build. The test is whether the work produces additional capability rather than maintaining or restoring existing performance.
Replacing a report generator with one that handles real-time analytics is an enhancement. Fixing a bug that causes the existing report generator to crash is maintenance. The line gets blurry when a release bundles new features with stability improvements, and the default treatment for any ambiguous cost is expensing unless work orders separate enhancement hours from maintenance hours.
Impairment and Abandonment
Capitalized software on the balance sheet is subject to impairment testing under the long-lived asset model in ASC 360-10 whenever events suggest the carrying amount may not be recoverable. Software-specific triggers include:
- The software is no longer expected to provide meaningful service.
- A significant change occurs in how the software is used or expected to be used.
- Major modifications are planned that will fundamentally alter its function.
- Development costs substantially exceed the original budget, raising questions about viability.
If undiscounted future cash flows or cost savings fall below carrying amount, the company writes the asset down to fair value and recognizes the difference as a loss.
Outright abandonment is simpler but more painful. When a project is killed before completion, all previously capitalized costs are written off in the period of abandonment. Common reasons include unresolvable technical problems, a decision that off-the-shelf software would be cheaper than finishing the custom build, a competing technology that makes the project obsolete, or dissolution of the business unit the software was designed to serve. The write-off appears as a loss on disposal, visible to investors as a distinct event.
Cloud Hosting Arrangements
Many companies now use hosted software rather than installing applications on their own servers. When a cloud arrangement is a service contract, meaning the vendor hosts the software and the customer accesses it remotely without taking possession of the code, the customer does not own an intangible asset. The costs of getting that cloud environment configured and ready for use still follow the ASC 350-40 framework under ASU 2018-15.2Financial Accounting Standards Board. ASU 2018-15 Customers Accounting for Implementation Costs in Cloud Computing Arrangements
Implementation costs such as configuration, customization, coding of interfaces, and data migration are capitalized the same way they would be for on-premise software. They sit on the balance sheet alongside any prepaid hosting fees and amortize on a straight-line basis over the term of the hosting arrangement, starting when each module or component is ready for its intended use.2Financial Accounting Standards Board. ASU 2018-15 Customers Accounting for Implementation Costs in Cloud Computing Arrangements
The term of the hosting arrangement is not simply what the initial contract says. It includes the fixed noncancellable period, plus renewal periods the company is reasonably certain to exercise, minus termination options the company is reasonably certain to use. Periods where the vendor controls the extension decision also count.2Financial Accounting Standards Board. ASU 2018-15 Customers Accounting for Implementation Costs in Cloud Computing Arrangements
What Changes Under ASU 2025-06
The three-stage model works reasonably well for waterfall development, where planning, building, and maintaining happen in sequence. It works less well for iterative approaches like agile, where teams cycle through design, coding, and testing continuously. ASU 2025-06 eliminates all references to prescriptive project stages from ASC 350-40.3Financial Accounting Standards Board. ASU 2025-06 Targeted Improvements to the Accounting for Internal-Use Software
Under the new framework, capitalization begins when two conditions are met: someone with the relevant authority has committed to funding the project, and it is probable the project will be completed and the software will perform as intended.
The second condition introduces a guardrail called significant development uncertainty. If the software involves unproven technology whose feasibility has not been demonstrated through coding and testing, or if significant performance requirements have not been identified or keep changing substantially, the probable-to-complete threshold is not met and costs must be expensed. Once the uncertainty resolves, capitalization begins.3Financial Accounting Standards Board. ASU 2025-06 Targeted Improvements to the Accounting for Internal-Use Software
The update also absorbs website development guidance from ASC 350-50 into ASC 350-40 and aligns disclosure requirements with ASC 360-10, so capitalized software must be presented with the same transparency as property and equipment.3Financial Accounting Standards Board. ASU 2025-06 Targeted Improvements to the Accounting for Internal-Use Software
Tax Treatment Differs From GAAP
Everything above governs financial reporting. Tax treatment is a separate question. Software development costs are classified as research and experimental expenditures under Section 174(c)(3).4Office of the Law Revision Counsel. 26 USC 174 Amortization of Research and Experimental Expenditures
From 2022 through 2024, the Tax Cuts and Jobs Act required all domestic software development costs to be capitalized and amortized over five years, creating a painful mismatch with GAAP. The One, Big, Beautiful Bill Act of 2025 added Section 174A to the code, allowing taxpayers to fully deduct domestic software development costs in the year paid or incurred for tax years beginning after December 31, 2024.5Office of the Law Revision Counsel. 26 USC 174A Domestic Research or Experimental Expenditures
A taxpayer can instead elect to capitalize domestic software development costs and amortize them over a period of at least 60 months, beginning with the month the taxpayer first realizes benefits. Once made, the election applies to the current year and all subsequent years unless the IRS approves a change.5Office of the Law Revision Counsel. 26 USC 174A Domestic Research or Experimental Expenditures
Foreign software development costs did not get the same relief. Expenditures attributable to foreign research must still be capitalized and amortized over 15 years, starting at the midpoint of the tax year in which they are incurred.4Office of the Law Revision Counsel. 26 USC 174 Amortization of Research and Experimental Expenditures
The practical result: a company building internal-use software domestically can expense the full cost for tax purposes while capitalizing and amortizing it for GAAP, producing a temporary difference that flows through deferred tax accounts. Companies with offshore development teams face split treatment, expensing the domestic portion and amortizing the foreign portion over 15 years, which makes geographic allocation of development costs a necessary part of the compliance process.