How to Capitalize Internal-Use Software Development Costs Under ASC 350-40

If your team is deciding which software development costs hit the balance sheet and which hit the P&L, you're navigating one of the most judgment-intensive areas in US GAAP. The rules under ASC 350-40 are at a genuine inflection point: the legacy three-stage model remains operative through at least fiscal year 2027 for most entities, while ASU 2025-06, issued by FASB on September 18, 2025, replaces it with a principles-based framework. You need to apply the current rules correctly right now and prepare for what replaces them.

This walkthrough covers both, with concrete examples, the agile capitalization problem, and a decision framework for the transition.

Key takeaway: The legacy three-stage model and ASU 2025-06 can produce materially different outcomes for the same project. FASB explicitly expects more costs to be expensed under the new model, not less.

Step 1: Confirm ASC 350-40 Applies to Your Software

ASC 350-40 applies when software is developed or obtained solely for internal use. That covers ERP systems, internal analytics platforms, proprietary workflow tools, and software a company uses to deliver a service to customers (including SaaS providers operating software on behalf of customers). It does not cover software developed to be sold, leased, or marketed externally, which falls under ASC 985-20.

A quick scope check:

• Will the software be used internally or to deliver a service? ASC 350-40 applies.
• Can the customer take possession of the software and run it independently, or contract a third party to host it? If yes to both, ASC 985-20 likely applies instead.
• Is this a cloud computing arrangement (SaaS subscription) where your entity is the customer, not the provider? ASU 2018-15 governs which implementation costs you can capitalize, using the same stage-based logic as ASC 350-40. That layer of guidance remains operative and is not superseded by ASU 2025-06.

Step 2: Apply the Current (Legacy) Three-Stage Model

Under the legacy ASC 350-40 model, whether a cost is capitalizable depends entirely on which project stage it falls into. This model was designed for waterfall development, which is why it creates friction for agile teams. It remains the operative standard for fiscal years beginning on or before December 15, 2027 (unless you early adopt ASU 2025-06).

Stage 1: Preliminary Project Stage (Expense Everything)

All costs in this stage must be expensed as incurred. No exceptions. Activities in this stage include:

• Conceptual formulation of alternatives
• Evaluation of alternative solutions
• Determining whether the needed technology exists
• Final selection of alternatives

The practical test: if the team is still deciding whether to build and what to build at a high level, you are in the preliminary project stage. Costs here look like research, and they are treated like research.

Stage 2: Application Development Stage (Capitalize Qualifying Costs)

Capitalization begins when the preliminary project stage is complete and management has authorized and committed to funding the project. Capitalizable costs include:

• External direct costs of materials and services consumed in developing or obtaining the software (e.g., third-party developer fees, licensed code)
• Payroll and payroll-related costs (including benefits, but generally not overhead or G&A) for employees directly associated with and devoting time to the project
• Interest costs incurred during the development period

Costs that are always expensed, regardless of stage:

• Training costs
• Data conversion costs (except software that enables access to or conversion of old data)
• General and administrative costs
• Overhead not directly attributable to the project

A note on stock-based compensation and contractor costs: Payroll-related costs for internal developers are capitalizable, and this extends to the fair value of stock-based compensation for employees directly working on the project. Third-party contractor costs are capitalizable as external direct costs. What is not capitalizable is overhead allocated to the project or management time spent supervising rather than directly developing.

Stage 3: Post-Implementation/Operation Stage (Expense Everything Again)

Once the software is substantially complete and ready for its intended use, you are in the post-implementation stage. All costs here are expensed, including:

• Application maintenance
• Bug fixes that do not add new functionality
• Training
• Data migration not captured in Stage 2

Step 3: Handle Agile Development Under the Current Rules

This is where most teams run into trouble. As BDO notes, "ASC 350-40 requires an entity to consider project stages in determining whether a software development cost for internal-use software is capitalized or expensed. That accounting model aligns with linear, stage-based software development methods like the waterfall approach. However, most entities now use agile or iterative software development methods, which causes challenges in applying the existing accounting model."

In an agile environment, design, coding, and testing happen simultaneously within each sprint. There is no clean handoff from preliminary to application development. Here is how practitioners navigate this under the current rules:

Approach 1: Project-level determination. Treat the entire product or module as the unit of account. Once management formally authorizes the project and commits funding (sprint planning for the first development sprint, not the discovery phase), declare the preliminary stage complete and begin capitalizing eligible costs. This requires a documented management authorization event.

Approach 2: Sprint-by-sprint assessment. Evaluate each sprint. If a sprint is primarily exploratory (proof-of-concept, technology evaluation), expense it. If a sprint is primarily building defined functionality, capitalize eligible costs. This is more granular and more defensible but requires robust time-tracking.

Approach 3: Hybrid allocation. For sprints that genuinely mix preliminary and development activities, allocate costs based on time-tracking data. Auditors will scrutinize this, so documentation must be specific.

The critical documentation requirement under any approach: a written management authorization memo that identifies the project, confirms the technology exists, and commits funding. Without this, you cannot support the transition from Stage 1 to Stage 2.

Upgrades and enhancements: Costs to upgrade or enhance existing internal-use software are capitalizable if the upgrade adds new functionality. Costs that merely maintain existing functionality are expensed. This distinction requires the same stage-based analysis applied to new development.

Step 4: Understand the ASU 2025-06 Framework (Effective FY2028, Early Adoption Permitted)

ASU 2025-06, effective for annual periods beginning after December 15, 2027, replaces the three-stage model with two conditions that must both be met before capitalization begins. Calendar-year entities will first apply it in fiscal year 2028 unless they early adopt. The FASB project page states the new standard requires capitalization when:

1. Management has authorized and committed to funding the software project.
2. It is probable that the project will be completed and the software will be used to perform the function intended (the "probable-to-complete recognition threshold").

The stage references are gone entirely. The guidance is now methodology-neutral, designed to work for waterfall, agile, and development approaches that do not yet exist.

What Is "Significant Development Uncertainty" and When Does It Block Capitalization?

This is the concept that most current coverage underexplains, and it is the one most likely to change your capitalization outcomes.

Significant development uncertainty exists when either of the following is present:

• The software has novel, unique, or unproven technology, functions, or features, and the uncertainty related to those innovations has not been resolved through coding and testing.
• The significant performance requirements of the software have not been identified, or the identified requirements continue to be substantially revised.

When significant development uncertainty exists, the probable-to-complete threshold is not met, and capitalization cannot begin even if management has authorized and funded the project.

Concrete examples of what this means in practice:

• Blocks capitalization: Your team is building a generative AI feature that has never been implemented at your scale. The technical approach is unproven, and you are still running experiments to determine whether it is feasible. Significant development uncertainty exists; expense these costs.
• Does not block capitalization: You are building a new reporting module using established database and API technologies your team has used before. The performance requirements are defined. No significant development uncertainty; capitalize eligible costs once management commits.
• Blocks capitalization: Product management continues to substantially revise the feature set for a new customer portal every two weeks. The significant performance requirements are not stable. Expense until requirements are locked.
• Does not block capitalization: Minor scope changes within a defined feature set. The significant performance requirements are clear and stable.

Key takeaway: The "significant development uncertainty" concept will push more costs into expense for entities building AI-native software, novel features, or anything with genuinely unproven technology. FASB said explicitly it expects more costs to be expensed under ASU 2025-06 than under the current model.

Defining the "Software Project" Under ASU 2025-06

This is a new judgment area that did not exist in the same form under the stage-based model. As BDO flags, entities must determine whether a "software project" is a new product, a distinct module, or a major feature or function to an existing product. The answer drives when the two conditions are evaluated and when capitalization begins.

A practical starting point: define the unit of account at the level where management authorization and funding decisions are made. If your company approves a new analytics module as a discrete project with its own budget and timeline, that is the software project. If individual features are approved and funded separately, each feature may be its own project.

Step 5: Compare the Two Models on the Same Project

Consider a mid-size financial services company building a new internal risk-scoring engine using established machine learning libraries (no novel technology). The project runs from January through September.

For this project, the outcomes are similar because the technology is proven and requirements are stable. The divergence appears when the technology is novel or requirements are in flux: the legacy model might permit capitalization once management commits in March, while ASU 2025-06 would block it until significant development uncertainty resolves.

Step 6: Handle Cloud Computing and SaaS Arrangements

If your entity is the customer in a SaaS arrangement (not the provider), ASU 2018-15 governs which implementation costs you can capitalize. That standard, issued in August 2018, aligned the capitalization requirements for cloud computing implementation costs with the existing ASC 350-40 stage-based model. It remains operative.

The key distinction:

• If the cloud arrangement includes a software license your entity can take possession of and run independently: the license and related implementation costs may be capitalized under ASC 350-40.
• If the arrangement is a pure service contract (typical SaaS): only certain implementation costs are capitalizable, mapped to the application development stage equivalent.

ASU 2025-06 does not supersede ASU 2018-15. FASB noted in the ASU's basis for conclusions that for software provided via cloud computing arrangements, the new guidance could result in a decrease in software capitalization, because the significant development uncertainty concept may block capitalization of implementation costs that previously would have been capitalized under the stage-based model.

For a deeper comparison of how ASC 350-40 interacts with ASC 985-20 for external-use software, see ASC 350-40 vs ASC 985-20: Which Standard Governs Your Software Project?

Step 7: Choose Your ASU 2025-06 Transition Approach

Three transition methods are available. The choice has real P&L, balance sheet, and disclosure consequences.

Decision criteria for choosing:

1. How large is your capitalized software balance? Entities with material balances that might not qualify under the significant development uncertainty concept face potential write-downs under modified prospective or retrospective. Model the impact before choosing.
2. Do your investors or lenders care about trend comparability? If yes, retrospective gives cleaner comparatives but at the highest cost.
3. How much in-process work do you have at adoption date? Heavy in-process pipelines make modified prospective more consequential.
4. What is your audit committee's appetite for a retained earnings adjustment? Modified prospective and retrospective both produce cumulative-effect adjustments that require disclosure under ASC 250.

Under the prospective approach, you must still disclose the nature and reason for the change in accounting principle in both interim and annual periods, as required by ASC 250.

Step 8: Update Disclosures Under Both Models

Under the legacy model, capitalized internal-use software is typically disclosed as an intangible asset under ASC 350-30, with useful life and amortization disclosures.

ASU 2025-06 changes this. Under the new model, entities must apply the disclosure requirements in ASC 360-10 (Property, Plant, and Equipment) to all capitalized internal-use software costs and related amortization, regardless of how those costs are presented on the balance sheet. Entities no longer need to provide intangible asset disclosures under ASC 350-30 for internal-use software.

In practice, this means your footnote on capitalized software shifts from the intangibles note to the PP&E note (or a combined note). The substantive disclosures, including gross carrying amount, accumulated amortization, and amortization expense, remain. Check your footnote template now if you are planning early adoption.

Amortization: Under both models, amortization begins when the software is ready for its intended use, not when it goes live for all users. Useful life is determined based on the expected period of benefit, considering obsolescence, technology changes, and contractual terms. There is no prescribed useful life in the standard.

Step 9: Build the Internal Controls and Documentation Infrastructure

The shift from stage-based to principles-based capitalization under ASU 2025-06 requires different documentation than most entities currently maintain. Under the legacy model, the key control is identifying the stage transition. Under the new model, the key controls are:

• Management authorization evidence: A formal memo or approval record showing the project was authorized and funded, with the date. This is the trigger for evaluating the probable-to-complete threshold.
• Significant development uncertainty assessment: A documented evaluation, updated at each reporting period, of whether novel technology or unstable performance requirements block capitalization. This is new and requires input from engineering and product teams.
• Project definition documentation: A written definition of what constitutes the "software project" for capitalization purposes (product, module, or feature level).
• Time-tracking data: Granular records of which employees spent time on which projects, at what stage, and in what capacity. This supports both the capitalization calculation and the audit.

Under the legacy model, time-tracking by stage is the core requirement. Under ASU 2025-06, time-tracking by project (with supporting documentation of the authorization date and uncertainty assessment) is what auditors will look for.

For a broader view of the capitalize-vs-expense decision framework and how AI development costs fit in, see ASC 350-40 Capitalize vs. Expense Software Costs: A 2026 Practitioner Walkthrough.

FAQ

Can I capitalize internal software development costs under current GAAP? Yes, but only for costs incurred during the application development stage under the legacy ASC 350-40 three-stage model. Costs in the preliminary project stage and post-implementation stage must be expensed. Capitalizable application development costs include direct developer payroll, contractor fees, and materials consumed in development.

What GAAP rules govern capitalizing software development costs? For internal-use software, ASC 350-40 is the governing standard. ASU 2025-06, issued September 18, 2025, replaces the three-stage model with a principles-based two-condition framework effective for fiscal years beginning after December 15, 2027. ASU 2018-15 governs implementation costs in cloud computing service arrangements.

Can development costs be capitalized under ASC 350-40? Yes, specifically costs incurred during the application development stage (legacy model) or after both conditions are met under ASU 2025-06 (management authorization plus probable-to-complete, with no significant development uncertainty). Training, data conversion, and G&A costs are always expensed.

How do I handle agile/scrum projects under the current three-stage model? The standard does not address agile directly. Most practitioners either (1) treat the entire project as the unit of account and begin capitalizing when management formally authorizes and funds the first development sprint, or (2) assess each sprint individually and allocate costs between preliminary and development activities based on time-tracking. Either approach requires a documented management authorization event and robust time records.

Should we early adopt ASU 2025-06? It depends on your capitalized software balance and development profile. Entities building novel or AI-driven software may face more expensing under the new model and should model the P&L impact before adopting early. Entities with mature, well-defined software projects using proven technology may see little change. The prospective transition method minimizes disruption; modified prospective and retrospective both require cumulative-effect adjustments.

What disclosures are required for capitalized internal-use software? Under the legacy model, disclosures follow ASC 350-30 (intangible assets). Under ASU 2025-06, entities apply ASC 360-10 (PP&E) disclosure requirements to all capitalized software costs, regardless of balance sheet presentation. Both models require disclosure of gross carrying amount, accumulated amortization, and amortization expense for the period.