Software development costs affect every company that builds, buys, or modifies software for internal use. With the release of ASU 2025-06, the GAAP rules governing how these costs are capitalized are getting a significant update. Whether you operate a SaaS platform, manage in-house development teams, or are implementing a new ERP system, understanding these changes now will save you time and reduce compliance risk when the new standard takes effect.
This article breaks down what ASU 2025-06 changes, who it impacts most, and the steps your company should take to prepare. If you want help applying the new standard, our accounting services team can review your software capitalization policies before the rules take effect.
What are software development costs under GAAP?
Software development costs include all expenditures a company incurs when acquiring, building, or modifying software that it uses internally. Under GAAP, these costs fall under ASC 350-40, the accounting standard that governs internal-use software. Internal-use software is defined as software acquired, developed, or modified solely to meet an entity’s internal needs, with no substantive plan to market it externally. The Financial Accounting Standards Board maintains the full codification through the FASB Accounting Standards Codification.
These costs can include salaries for developers, payments to third-party contractors, cloud hosting fees tied to implementation, and related overhead. GAAP requires companies to determine whether each cost should be expensed immediately or capitalized as an intangible asset and amortized over the software’s useful life. The distinction matters because capitalized costs appear on the balance sheet and are recognized gradually, while expensed costs hit the income statement right away.
Until now, the rules for making that determination have been tied to a prescriptive, stage-based model. That model is about to change.
How the old software capitalization rules worked
Under the existing ASC 350-40 framework, capitalization decisions depend on where a project sits within three defined stages of development:
- Preliminary project stage: Costs incurred during initial planning, evaluating alternatives, and determining whether the project is feasible. All costs in this stage are expensed as incurred.
- Application development stage: Costs related to designing, coding, testing, and installing the software. Costs in this stage must be capitalized.
- Post-implementation/operation stage: Costs for training, maintenance, and minor upgrades after the software goes live. These costs are expensed.
Each stage has identifiable start and stop points, and the guidance assumes a linear progression from one stage to the next. This model worked reasonably well when software development followed a traditional waterfall approach with distinct phases. Modern development practices, particularly agile, DevOps, and continuous deployment, blur the boundaries between these stages. Teams often plan, build, test, and deploy in overlapping cycles, making it difficult to pinpoint when one stage ends and another begins.
What ASU 2025-06 changes for internal use software capitalization
ASU 2025-06, titled “Intangibles, Goodwill and Other, Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software,” modernizes the accounting framework by removing the stage-based model entirely. The update was issued by FASB on September 18, 2025 and reflects feedback that the prior stage-based model no longer matched how companies build software. Instead of asking “which stage is this project in?” the new standard asks two simpler questions:
1. Has management authorized and committed to funding the project?
2. Is it probable that the software will be completed and used as intended?
Capitalization begins once both conditions are met, and it continues until the software is substantially complete and ready for its intended use. This approach eliminates the need to map individual costs to specific development stages, which is where most of the complexity and judgment calls arose under the old rules.
The new standard also requires companies to consider “significant development uncertainty” when assessing whether completion is probable. If a project faces material technical risks or unresolved feasibility questions, capitalization may need to be deferred until those uncertainties are resolved.
In practice, many companies may find that the total dollar amount of capitalized costs does not change dramatically. The real benefit is operational: the new rules align more naturally with how software is actually built today, reducing the documentation burden and subjective judgment required to classify costs by stage.
Which companies are most affected by the new software capitalization rules?
Three categories of companies are likely to feel the greatest impact from ASU 2025-06:
SaaS and cloud-service providers. Unlike traditional on-premises software licensing, SaaS and cloud-delivery arrangements typically provide customers with access to a hosted service rather than a transferable product. This means the costs to build and maintain those platforms are accounted for as internal-use software under ASC 350-40, not under the separate rules for software intended to be sold, leased, or marketed. SaaS companies often have large, ongoing development operations that will need to align with the new capitalization criteria.
Companies with in-house development teams. Organizations that build or enhance internal systems for operations, analytics, customer management, or logistics regularly incur costs that must be evaluated for capitalization. Under the old stage-based model, determining exactly when a project moved from planning into active development required significant judgment. The new two-question test simplifies that determination.
Companies implementing new ERP systems. ERP implementations involve substantial investment in both internal and third-party resources. Configuration, customization, data migration, and integration costs all must be assessed against the capitalization rules. The shift away from stage-based analysis should make it easier to apply the standard consistently across complex, multi-phase ERP rollouts.
How to prepare for ASU 2025-06 adoption
The new guidance is effective for fiscal years beginning after December 15, 2027, meaning calendar-year companies will adopt it in 2028. Early adoption is permitted. Several transition methods are available, so companies can choose the approach that best fits their circumstances.
Even though 2028 may feel distant, software development projects often span multiple years. A project that begins today may still be in progress when the new standard takes effect. Companies that wait until 2028 to evaluate the impact risk retroactive adjustments and policy gaps.
To prepare, companies should take these steps now:
- Define what constitutes a qualifying software project. Establish clear criteria for which initiatives fall under ASC 350-40 and which do not.
- Document how management authorization and funding commitment are identified. The new standard requires a demonstrable commitment, not just an informal go-ahead. Build this into your project governance process.
- Establish how probability of completion is assessed. Create a framework for evaluating development uncertainty, including who makes the assessment and what evidence is required.
- Determine when capitalization begins and ends. Map the new two-question test to your development workflow so teams know at what point costs shift from expense to capitalization.
- Review existing capitalized software assets. Evaluate whether any in-progress projects need to be reassessed under the new criteria, especially if you plan to early adopt.
Starting this work now gives your accounting and development teams time to align on policies before the standard becomes mandatory. Because capitalized software is a recurring focus during financial statement reviews, coordinating with your audit and assurance provider early can prevent surprises at year-end.
Key differences between ASU 2025-06 and the old rules at a glance
Understanding the shift from stage-based capitalization to criteria-based capitalization is easier when you compare them directly:
- Old rule: Capitalize costs only during the application development stage. New rule: Capitalize costs once management commits funding and completion is probable.
- Old rule: Three distinct stages with defined start and stop points. New rule: No stages; capitalization is driven by two conditions being met.
- Old rule: Assumes linear, sequential development. New rule: Accommodates iterative and agile development processes.
- Old rule: Requires mapping each cost to a specific stage. New rule: Requires assessing management commitment and probability of completion.
The net effect is a simpler, more principles-based standard that better reflects how companies actually develop software today.
Frequently Asked Questions
When should you capitalize software development costs?
Under ASU 2025-06, you should capitalize software development costs once management has authorized and committed to funding the project and it is probable that the software will be completed and used as intended. Capitalization continues until the software is substantially complete. This replaces the old requirement to capitalize only during the application development stage.
What is ASU 2025-06?
ASU 2025-06 is an Accounting Standards Update issued by FASB that modernizes the GAAP rules for internal-use software under ASC 350-40. It removes the traditional three-stage development model and replaces it with a simpler, criteria-based approach to determine when software development costs should be capitalized.
Should software costs be capitalized or expensed?
It depends on whether two conditions are met: management has committed funding to the project, and the software is probable to be completed and used as intended. If both are satisfied, costs should be capitalized. If either condition is not met, for example during early feasibility research or when significant development uncertainty exists, costs should be expensed.
How does ASC 350-40 apply to SaaS companies?
SaaS companies provide customers with access to hosted software rather than a transferable product. Because of this, the costs to build and maintain SaaS platforms are classified as internal-use software under ASC 350-40. SaaS providers must evaluate their development costs against the same capitalization rules that apply to any other internal-use software project.
What is the effective date for ASU 2025-06?
ASU 2025-06 is effective for fiscal years beginning after December 15, 2027. For calendar-year companies, that means adoption in 2028. Early adoption is permitted, and several transition methods are available to accommodate different business needs.
Does ASU 2025-06 change the total amount of capitalized costs?
For many companies, the total dollar amount of capitalized costs may not change significantly. The primary benefit is operational: the new rules eliminate the need to classify costs by development stage, reducing complexity and better aligning accounting with modern agile and iterative development practices.
