A software upgrade or enhancement can be capitalized under the rules for internal-use software when the work gives the software a capability it did not have before. Bug fixes, security patches, and routine maintenance stay on the income statement as period expenses. The line between capitalizing and expensing comes down to a single question about each piece of work: did it build new functionality, or did it keep existing functionality running?
The Functionality Test
Under ASC 350-40, the GAAP framework for internal-use software, a modification qualifies for capitalization only if it enables the software to perform tasks it could not perform before. Adding a predictive analytics module to an ERP system meets the test because the software gains something new. Patching a vulnerability or fixing a crash does not, because the software is only being restored to its intended operation.
Some upgrades sit in between. Work that dramatically speeds up processing without adding any new task is a common gray area. The practical rule is unforgiving: if you cannot separate the cost of minor enhancements from routine maintenance on a cost-effective basis, the entire blended cost has to be expensed as incurred. That situation shows up constantly on teams that mix bug fixes and feature work in the same sprint. Documenting the specific new functions an upgrade delivers is what supports capitalization when an auditor asks how the cost ended up on the balance sheet.
Which Costs Qualify
Once a project clears the functionality test and enters the capitalization window, several categories of cost can be added to the asset’s value:
- External development costs, including payments to consultants, contractors, and third-party developers who write code, design configurations, or perform testing.
- Internal labor for employees directly working on coding, testing, and installation, along with their fringe benefits and payroll taxes. Time-tracking records showing actual hours on the project are required.
- Software written to access or convert data from a legacy system into the new platform.
Other costs are excluded even when the project cannot happen without them:
- General and administrative overhead not tied to specific project activities.
- Training on the new software, always expensed, even when training is a major budget line.
- Manual data conversion labor. Building software to convert data is capitalizable; the hands-on work of cleaning and migrating the data is not.
- Preliminary costs of evaluating alternatives, selecting vendors, and running feasibility analyses before management commits.
A short example: if a company pays $50,000 to external developers for new module code and tracks $20,000 in internal labor for testing and configuration, the capitalized amount is $70,000, assuming none of those dollars went to training, administrative support, or manual data migration.
When Capitalization Starts and Stops
The current ASC 350-40 framework splits internal-use software work into three stages, and only the middle one supports capitalization.
- Preliminary project stage. Evaluating alternatives, selecting vendors, and determining feasibility. All costs are expensed.
- Application development stage. Designing, coding, testing, and installing. This is the capitalization window. It opens once management authorizes the project, commits funding, and completion of the project for its intended use is probable.
- Post-implementation stage. Training, ongoing maintenance, and minor tweaks after the software is substantially complete. Costs return to being expensed.
The window closes when the software is substantially complete and ready for its intended use, even if it has not yet been rolled out to every user. For a phased rollout, each module or component can have its own timeline. Anything spent after the software starts doing the job it was built for belongs on the income statement.
Software Built to Sell Follows a Different Standard
ASC 350-40 covers software a company builds or buys for its own use. Software developed to sell, lease, or market to customers falls under ASC 985-20 instead, and the capitalization trigger there is more demanding. All costs incurred before establishing technological feasibility must be expensed as research and development. Technological feasibility requires a completed detailed program design or a working model that has been tested against product specifications. In practice this means a smaller portion of total costs ends up capitalized for external-use software than for internal-use software, because months of early development are expensed before the threshold is reached.
Cloud and SaaS Implementation Costs
Most cloud subscriptions do not give the customer a software license they own or control. If the hosting arrangement does not include the contractual right to take possession of the software and run it on your own infrastructure or through an unrelated third party, the arrangement is a service contract, not an intangible asset. The subscription fees are period expenses.
Implementation work on a service-contract cloud arrangement still qualifies for capitalization under ASC 350-40, using the same activity-based analysis as internal-use software. Coding, configuration, and testing costs during the implementation are capitalized as a prepaid asset and then amortized on a straight-line basis over the hosting term, including any renewal periods the customer is reasonably certain to exercise. Amortization begins for each module or component when it is ready for use, even if the full rollout is phased. Training costs and manual data migration labor are expensed, as they would be for on-premises software.
Amortization and Impairment After the Upgrade Goes Live
Once an upgrade is substantially complete and placed into service, the capitalized amount is amortized over the software’s estimated useful life. Most companies use straight-line. Capitalize $100,000 with a five-year useful life and the annual amortization expense is $20,000. For software licenses, the useful life cannot exceed the license term.
No standard prescribes a specific number of years. The estimate depends on how long the software is expected to contribute to operations, the pace of technological change in the industry, contractual or licensing constraints, competition, and the maintenance spending needed to keep the asset productive. A heavy maintenance burden relative to the carrying value can signal a short useful life. Companies should reassess the estimate at least annually and adjust amortization prospectively if circumstances change.
Capitalized software also has to be tested for impairment whenever something suggests its value has dropped: a technology shift that makes the platform obsolete, a strategic decision to move to a different system, or a sharp decline in expected benefits. The test compares the carrying amount to the undiscounted future cash flows the asset is expected to generate. If the carrying amount is higher, the asset is written down to fair value, with the loss recorded in the period the impairment is identified.
What Changes Under ASU 2025-06
The FASB issued ASU 2025-06 in 2025. It is effective for annual reporting periods beginning after December 15, 2027, with early adoption permitted for any period whose financial statements have not yet been issued.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles, Goodwill and Other, Internal-Use Software (Subtopic 350-40) Companies considering early adoption in 2026 should understand three changes.
First, the three-stage model is gone. ASU 2025-06 removes all references to preliminary, application development, and post-implementation stages. In its place are two criteria for the start of capitalization: management has authorized and committed to funding the project, and it is probable the project will be completed and the software will be used as intended.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles, Goodwill and Other, Internal-Use Software (Subtopic 350-40)
Second, a significant development uncertainty test can delay capitalization even after management commits. Significant development uncertainty exists when the software involves technological innovations or novel features whose feasibility has not yet been confirmed through coding and testing, or when significant performance requirements have not been identified or are still being substantially revised. If either condition applies, the probable-to-complete threshold is not met and costs continue to be expensed.2Deloitte. FASB Amends Guidance on the Accounting for and Disclosure of Software Costs A standard business application with well-understood requirements will typically clear the threshold early. A project experimenting with novel AI capabilities where the technical approach is still uncertain may need to expense costs longer.
Third, the standard is intended to fit Agile development. Because design, coding, and testing happen iteratively rather than in sequence, the old stage-based rules were difficult to apply. Focusing on the nature of the activity rather than the phase of the project eliminates the need to force non-linear work into a linear framework.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles, Goodwill and Other, Internal-Use Software (Subtopic 350-40) Companies still on the old rules can apply the same practical approach under the current guidance: coding and testing activities are capitalizable regardless of which sprint they fall in; strategic planning and requirements gathering are expensed; and blended maintenance-plus-enhancement work that cannot be separated is expensed in full.
Federal Tax Treatment for 2026
The tax rules for software development costs are separate from the GAAP rules and produce a different answer. The One Big Beautiful Bill Act, signed on July 4, 2025, created Section 174A of the Internal Revenue Code, which permanently restores full expensing of domestic research and experimental expenditures for tax years beginning after December 31, 2024. Software development is explicitly a research or experimental expenditure under both Section 174 and Section 174A.3Office of the Law Revision Counsel. 26 USC 174 – Amortization of Research and Experimental Expenditures For 2026, domestic software development costs can be deducted in full in the year paid or incurred, ending the five-year amortization requirement that applied from 2022 through 2024.
Foreign research is treated differently. Research and experimental expenditures attributable to foreign research must still be capitalized and amortized ratably over 15 years, beginning at the midpoint of the taxable year in which the expenditures are paid or incurred.4Internal Revenue Service. Notice 2023-63 – Guidance on Amortization of Specified Research or Experimental Expenditures Under Section 174 Companies with offshore development teams should track domestic and foreign costs separately.
The IRS definition of software development activities covers planning, designing, building a model, writing source code, and testing, up through the point the software is placed in service for internal use. Employee training, maintenance that does not result in an upgrade or enhancement, manual data conversion, and installation work fall outside the definition. Upgrades and enhancements are defined for tax purposes as modifications that add functionality the software previously lacked or that materially increase its speed or efficiency.4Internal Revenue Service. Notice 2023-63 – Guidance on Amortization of Specified Research or Experimental Expenditures Under Section 174
Setting a Capitalization Threshold
No accounting standard requires a specific dollar cutoff, but most organizations set one. Below the threshold, all software spending is expensed regardless of whether the work would otherwise qualify for capitalization. The right number depends on the size of the organization and the risk that expensing everything below it would distort asset values or period costs. A company with a $50,000 threshold would expense a $30,000 enhancement even if it added genuine new functionality, because the administrative cost of tracking and amortizing small assets outweighs the benefit.
Whatever threshold a company selects, the policy also needs to address bulk purchases of the same software across departments and how individual modules of a larger system are treated. If expensing many small components would collectively understate the asset base, the policy should provide for aggregating and capitalizing those costs together. Auditors look for consistent application across similar projects, so uniform treatment matters as much as the number itself.