Accounting Standards Codification (ASC) 350-40 internal-use software guidance sits at the intersection of financial reporting, technology investment, and regulatory compliance — and getting it wrong carries real consequences for your balance sheet, income statement, and audit readiness.
Every company that builds, acquires, or implements software for its own operations must navigate the capitalization rules set forth by the Financial Accounting Standards Board (FASB). The stakes are not trivial. Incorrectly capitalizing costs that should be expensed can lead to an overstatement of current period earnings, creating a significant restatement risk. Yet under-capitalizing can misstate asset values and inflate operating expenses in ways that distort profitability metrics investors rely on.
This guide synthesizes what the top-ranking accounting resources, major CPA firms, and FASB’s own publications say about the standard — covering the foundational three-stage model, scope and definitions, cost treatment rules, cloud computing arrangements, the landmark ASU 2025-06 overhaul, disclosure obligations, and practical implementation considerations.
What Is ASC 350-40 and Why Does It Matter?
Accounting Standards Codification (ASC) 350-40 provides the guidance under U.S. Generally Accepted Accounting Principles (GAAP) for costs associated with computer software developed or acquired for a company’s own use. It dictates which costs should be treated as a long-term asset on the balance sheet through capitalization, and which should be recorded as an expense on the income statement when incurred.
The economic rationale underlying this treatment is straightforward. The primary objective of ASC 350-40 is to ensure the costs are matched to the period in which the economic benefits from the software are realized. A custom ERP system, a proprietary data analytics platform, or an internally developed compliance tool will generate value over multiple years — and accounting rules should reflect that multiyear benefit by allowing qualifying costs to be spread across the asset’s useful life rather than hitting the income statement all at once.
Capitalizing costs can defer their full impact on a company’s reported net income, while expensing them reduces profitability immediately. ASC 350-40 creates a structured approach to this decision-making process, ensuring that financial reporting for these investments is comparable across companies and industries.
Understanding and applying asc 350-40 internal-use software rules correctly is therefore not just a compliance exercise — it is a core financial reporting competency that affects how investors, lenders, and analysts perceive a company’s financial health.
Defining Internal-Use Software Under the Standard
Before any cost treatment question can be answered, an entity must determine whether its software project even falls within the scope of asc 350-40 internal-use software guidance. The definition is narrower than many practitioners assume.
ASC 350-40 governs software that is acquired, developed, or modified solely to meet an entity’s internal needs, meaning it is not intended for external marketing, selling, or leasing. The word “solely” is operative here. Management’s intent at the time of development is the defining factor.
For instance, a bank developing a new online banking platform for its customers is creating an internal-use application falling under ASC 350-40. Conversely, a technology company that builds a project management tool to sell subscriptions to the public would follow the guidance in ASC 985-20.
Two categories of software fall outside the scope of the standard:
Software to be sold, leased, or marketed externally — This type is governed by ASC 985-20, which has materially different capitalization thresholds, particularly with respect to technological feasibility. Applying the wrong standard to a product that will ultimately be licensed to customers is a common and consequential error.
Software used in research and development activities — Costs for software used in R&D efforts are governed by ASC 730. If software development is integral to R&D, teams must carefully parse which portions fall under each standard.
The critical practical implication: the same internal development team may work on multiple projects that fall under different accounting standards simultaneously. Robust time-tracking systems and clear project classification protocols are not optional — they are essential to compliance with asc 350-40 internal-use software requirements.
The Three-Stage Development Model (Pre-ASU 2025-06)
Under the traditional framework — which remains operative for most entities until December 15, 2027 — costs incurred to develop internal-use software are either capitalized or expensed depending on the nature of costs incurred and the stage of development of the internal-use software. The standard identifies three sequential stages, each with distinct accounting treatment.
The Preliminary Project Stage
The preliminary project phase is the period in which an entity determines the system requirements for the internal-use software. Activities during this phase are similar to research and development expenses, and therefore, all costs during this stage should be expensed as incurred.
Typical activities in this stage include identifying performance objectives, evaluating whether available technology can satisfy requirements, exploring vendor alternatives, and conducting feasibility analysis. None of these costs — whether incurred by internal employees or outside consultants — may be capitalized. Even if management already knows it will proceed with the project, costs incurred before the formal commitment to the application development stage must be expensed.
This treatment reflects the economic reality that planning activities have not yet produced a definable asset with measurable future economic benefit.
The Application Development Stage
An entity enters the application development phase after it makes the decision to move forward with a software project and has express approval of management. During this stage, the entity will capitalize internal and external costs to develop or purchase internal-use software.
Capitalization is generally allowed during the application development stage. This is the stage where the actual building of the software takes place. It includes activities like designing the software’s architecture, user interface, and functionality.
Capitalizable costs in this stage typically include:
- Direct labor costs (salaries and related benefits) of employees directly involved in coding, configuration, and testing
- Costs of third-party contractors engaged specifically for development activities
- Software purchased from third parties to be integrated into the final solution
- Data conversion costs directly attributable to the development project (subject to specific limitations)
Notably, training costs are always expensed, regardless of which stage they occur in. Training costs must be expensed as incurred, regardless of the stage in which they are incurred.
The Post-Implementation and Operation Stage
Once software has been placed into service and employees have been trained, the entity enters the post-implementation stage. All costs incurred from this point forward — including maintenance, minor bug fixes, and ongoing support — are expensed as incurred. Only costs that constitute a significant enhancement adding new functionality may restart the capitalization clock, and only if they meet the criteria for the application development stage.
Costs incurred to upgrade or enhance an existing internal-use software follow the same accounting guidance as discussed in the application development stage. The key test is whether the enhancement adds meaningful new capability rather than merely maintaining existing functionality.
What Costs Are Capitalized vs. Expensed: A Practical Framework
One of the most operationally important aspects of asc 350-40 internal-use software compliance is the ability to consistently distinguish between capitalizable and non-capitalizable costs in day-to-day operations. The table below summarizes the treatment of common cost types:
| Cost Type | Treatment |
|---|---|
| Employee salaries — coding/configuration during application development | Capitalize |
| Contractor fees — development work during application development | Capitalize |
| Third-party software purchased for integration | Capitalize |
| Data conversion costs (certain, directly related) | Capitalize (with limitations) |
| General and administrative overhead | Expense |
| Preliminary project planning and feasibility | Expense |
| Training costs (all stages) | Expense |
| Post-implementation maintenance | Expense |
| Minor bug fixes and upgrades | Expense |
| Significant new functionality enhancements | Capitalize (if meeting criteria) |
Generally, for internally developed software, only costs that relate to the actual development of the software are capitalizable. Capitalization of data conversion costs depends on the method in which the data is converted.
The allocation of employee time is particularly challenging. In practice, developers rarely work exclusively on one capitalizable project. Organizations must implement time-tracking systems that capture the portion of each employee’s time attributable to capitalizable versus non-capitalizable activities on a contemporaneous basis. Reconstructed allocations after the fact are generally viewed with skepticism by auditors and may not withstand scrutiny.
Cloud Computing Arrangements and ASU 2018-15
The proliferation of SaaS (Software as a Service) platforms created a significant gap in the original guidance. When a company simply purchases access to a cloud-hosted application — without obtaining any software license — the original three-stage model did not clearly apply to the implementation costs incurred.
Accounting Standards Update 2018-15 Intangibles—Goodwill and Other—Internal-Use Software amended ASC 350-40 to provide more clarity and visibility to certain fees paid for cloud computing arrangements that do not include a license for use.
The amendment resolved this gap by extending the asc 350-40 internal-use software framework to cover implementation costs incurred by customers in cloud computing arrangements that are service contracts. This means the same three-stage logic — expense in preliminary and post-implementation, capitalize in application development — applies to the setup costs a company incurs when onboarding a SaaS platform, even though the company will never own the underlying software.
However, the subscription fees themselves — the ongoing monthly or annual payments for cloud access — are treated differently. Since you’re not getting a software license, it’s treated as a service contract. The subscription fees are usually expensed when paid.
Amortization of Capitalized Cloud Implementation Costs
The amortization period for capitalized CCA implementation costs is expressly limited to the non-cancellable term of the CCA plus periods for which the entity or the cloud service provider has an option to extend. If the CCA does not include any renewal options, the amortization period for capitalized implementation costs is limited to the non-cancellable term of the CCA.
If the entity has equal access to the hosted software throughout the term of the hosting arrangement, amortization is on a straight-line basis. This applies even if the entity expects to use the hosted software on an uneven basis.
Presentation Considerations
Where capitalized CCA costs appear in financial statements has meaningful implications for key performance metrics. The presentation requirements could impact key metrics such as EBITDA because the recognition of capitalized implementation costs associated with a CCA over the contract period are considered cash operating expenses, not depreciation or amortization.
This distinction matters significantly for companies where EBITDA is a negotiated metric in debt covenants or a focal point for investor analysis. Unlike traditional capitalized software developed on-premises, amortization expense should be presented in the same income statement line as the fees for the associated hosted service.
ASU 2025-06: The Most Significant Overhaul in Over Two Decades
In September 2025, the FASB issued Accounting Standards Update 2025-06, representing what experts have called the most sweeping revision to asc 350-40 internal-use software accounting in more than twenty years. The trigger for this update was the fundamental mismatch between the original standard’s assumptions and the way modern software is actually built.
The prior accounting model aligned 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 and determining when to begin capitalizing internal-use software costs.
Agile development occurs in short cycles called sprints, with features being planned, built, tested, and sometimes discarded across multiple iterations simultaneously. Mapping this fluid process onto a rigid three-stage model that assumed sequential, linear progression created inconsistencies across companies and required significant judgment calls that had no clear authoritative guidance.
Elimination of Project Stages
The most structurally consequential change in ASU 2025-06 is the complete removal of all references to project development stages. ASU 2025-06 eliminates all references to predefined software development stages, such as the preliminary, application development, and post-implementation stages, from ASC 350-40. This change complements the principles-based capitalization criteria by removing structural constraints tied to legacy development models. The updated guidance is now methodology-neutral, supporting consistent application across traditional, agile, and iterative approaches.
The New Two-Condition Capitalization Threshold
Replacing the stage-gating model is a principles-based two-condition recognition threshold. The amendments in this Update remove all references to “project stages” from Subtopic 350-40 and require an entity to begin capitalizing software costs when both of the following occur: Management authorizes and commits to funding the software project. It is probable the software project will be completed and the software will be used to perform the function intended (referred to as the “probable-to-complete recognition threshold”).
Significant Development Uncertainty
The “probable to complete” criterion is constrained by a concept new to the standard: significant development uncertainty. ASC 350-40-25-12A(a) and (b) describe two factors that may indicate that there is significant development uncertainty. The software being developed has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those technological innovations, functions, or features has not been resolved through coding and testing. The significant performance requirements of the software have not been identified, or the identified significant performance requirements continue to be substantially revised.
This has practical implications that shift the landscape considerably. The standard is expected to shift many entities toward more expensing and later capitalization of internal-use software, particularly for innovative or SaaS platform builds.
For software companies, the recognition decision is no longer a mechanical “we entered the application development stage” moment; it becomes a documented accounting judgment about whether completion and intended use are likely, with explicit consideration of development risks.
Integration of Website Development Costs
Under the prior framework, website development costs were governed by a separate subtopic: ASC 350-50. ASU 2025-06 eliminates ASC 350-50 for website development costs and incorporates key, non-developmental stage website-specific costs guidance into ASC 350-40. This consolidation simplifies the landscape for entities that develop both traditional software and web-based platforms.
Effective Date
Annual periods beginning after December 15, 2027, including interim periods within those annual periods, for all entities. Early adoption is permitted. This gives entities time to prepare, but those using modern agile development methodologies should begin assessing the impact on their current capitalization practices well before the mandatory adoption date.
Impairment of Capitalized Internal-Use Software
Like other long-lived assets, capitalized internal-use software is subject to impairment testing. If circumstances indicate the carrying value of capitalized software may not be recoverable — for example, if a project is abandoned, if a major system replacement is announced, or if the software’s functionality becomes obsolete — an impairment review must be performed.
Under the new ASU, the interaction of impairment rules with the transition provisions adds additional complexity. The legacy capitalization would remain on the balance sheet, and entities would evaluate the capitalized costs for impairment in accordance with ASC 350-40 when transitioning under the prospective approach and ceasing further capitalization on in-progress projects that no longer meet the new criteria.
Practical triggers that commonly prompt an impairment review include:
- A decision to abandon or significantly reduce the scope of a project
- The announcement of a vendor-supplied replacement for custom-built software
- A major strategic shift that makes the software’s intended function redundant
- Significant budget overruns that call completion probability into question
Impairment losses for internal-use software are generally recognized in operating income and disclosed in accordance with the requirements applicable to other long-lived assets under ASC 360.
Disclosure Requirements Under ASC 350-40
Transparency in financial reporting is a central objective of the standard, and disclosure requirements have grown meaningfully under ASU 2025-06. Entities applying asc 350-40 internal-use software guidance must ensure their notes to financial statements meet both current and forthcoming requirements. what is print management software
Entities will be required to disclose the capitalized internal-use software balance and accumulated amortization at the balance sheet date, the amortization expense for the period, and a general description of the method used in computing amortization.
The guidance also specifies that the disclosures under ASC 360-10, Property, Plant, and Equipment — Overall, apply to capitalized software costs accounted for under ASC 350-40, regardless of how those costs are presented in the financial statements.
Additionally, the update clarifies that disclosure requirements in ASC 350-30-50-1 through 50-3 related to intangible assets are not required for software costs accounted for under Subtopic 350-40. This clarification resolves a point of confusion where entities were uncertain whether they needed to apply intangible asset disclosures on top of software-specific disclosures.
For cloud computing arrangements, disclosures required include the nature of hosting arrangements that are service contracts as well as the information required by ASC 360-10 as if the capitalized implementation costs were a separate class of long-lived assets.
Cash flows associated with the implementation costs should be included in the same statement of cash flows category as cash flows for the fees of the related hosted agreement — generally operating cash flows.
This last point underscores an important nuance. Unlike traditional software development costs, which are typically classified as investing activities in the statement of cash flows, cloud computing implementation costs follow the classification of the related service fees — generally operating. This affects reported free cash flow and operating cash flow metrics.
SaaS Companies and the Special Considerations of ASC 350-40
The relationship between SaaS companies and asc 350-40 internal-use software accounting is uniquely complex. Many technology companies deliver their products through hosted platforms — meaning the software at the core of their revenue model is, from an accounting standpoint, internal-use software because customers receive a service rather than a license.
SaaS and cloud-delivery arrangements often do not convey a software license for accounting purposes; instead, customers receive access to a hosted service. As a result, software companies historically have accounted for substantial portions of product development spend as internal-use software under ASC 350-40, even when that software is central to revenue-generating offerings.
This creates a significant strategic accounting consideration. Under the previous stage-based model, a SaaS company might capitalize a large portion of its development costs once it entered the application development stage. Under ASU 2025-06, the significant development uncertainty concept may delay or reduce capitalization — particularly for genuinely innovative platform builds where technological feasibility remains in question during early development sprints.
Using ASC 350-40 allows for earlier capitalization, bolstering balance sheets for growth-focused companies. However, this advantage is now tempered by the judgment requirements of the new framework. Finance leaders at SaaS companies must work closely with their product and engineering teams to document when development uncertainty has been resolved through coding and testing — because that documented resolution is now the trigger for capitalization to begin.
Applying ASC 350-40 in an Agile Environment
The collision between agile software development methodology and the original three-stage model has been the practical pain point driving the need for ASU 2025-06. Understanding how the new framework operates in practice is essential for finance teams embedded in technology organizations.
In a traditional waterfall development model, a project moves sequentially through requirements gathering, design, development, testing, and deployment. Mapping stages to the prior asc 350-40 internal-use software framework was relatively straightforward. In agile, these activities intermingle across short sprints. Design and coding may happen simultaneously with requirements refinement. Testing is continuous rather than a distinct phase.
The new two-condition framework offers a more natural fit. Rather than asking “what stage is this project in?” teams now ask two questions:
Question One: Has management with appropriate authority authorized and committed to funding? This is a governance and documentation question. Board minutes, approved project charters, budget approvals, and commitment letters serve as evidence of this condition being met.
Question Two: Is it probable the software will be completed and used as intended, and has significant development uncertainty been resolved? This is a technical and operational judgment requiring collaboration between finance, technology leadership, and product management. The resolution of significant development uncertainty typically occurs through coding and testing that demonstrates novel features are achievable — not through planning documents alone.
Determining when significant development uncertainty has been resolved is inherently judgmental and cross-functional. Finance will need tighter collaboration and documentation with IT/Product, including governance gates, technical feasibility sign-offs, and performance requirement definitions.
ASC 350-40 vs. ASC 985-20: Knowing the Difference
Every entity accounting for software costs must first determine which standard applies. The consequences of misclassification are material.
When accounting for software development costs, companies must first determine which U.S. GAAP standard applies: ASC 350-40 (internal-use software) or ASC 985-20 (costs of software to be sold, leased, or marketed). These two standards differ in scope, capitalization criteria, and applicability. Selecting the right one is essential for accurate reporting.
The key distinguishing factor is management’s intent. If there is no current plan to market the software to external parties — even if the software is central to delivering a service that generates revenue — the software typically falls under asc 350-40 internal-use software guidance. If there is a substantive plan to market the software itself as a product (whether through licensing, selling, or leasing), ASC 985-20 applies.
Under ASC 985-20, costs are expensed until technological feasibility is established, which is a higher bar than the preliminary project stage concept in ASC 350-40. Under ASC 350-40, capitalization begins earlier (once application development commences under the old model, or once both conditions are met under ASU 2025-06), typically resulting in a larger capitalizable asset for internal-use software compared to equivalent software developed for external sale.
No changes were made to the external-use software guidance in ASC 985-20, Software — Costs of Software to Be Sold, Leased, or Marketed, under ASU 2025-06. The reform was targeted specifically at the internal-use framework.
Internal Controls and Documentation Best Practices
Compliance with asc 350-40 internal-use software rules is not only a financial reporting matter — it is an internal controls matter. Auditors evaluate not just whether the accounting conclusions are correct but whether the processes and controls that produce those conclusions are reliable and repeatable.
Robust internal controls for software capitalization include:
Project Classification Controls. A formal process for evaluating each new software project against the scope criteria of ASC 350-40, ASC 985-20, and ASC 730 before development begins. This classification should be documented and approved by a qualified accounting professional.
Stage Gate Documentation (Pre-ASU 2025-06) / Condition Satisfaction Documentation (Post-ASU 2025-06). Contemporaneous written evidence of when each development stage begins and ends, or when both capitalization conditions are satisfied, is critical to audit defense.
Time-Tracking Systems. Automated or semi-automated systems that capture employee time attributable to capitalizable projects on a project-by-project, activity-by-activity basis. Manual allocations based on estimates are disfavored and difficult to sustain under audit scrutiny.
Enhancement vs. Maintenance Determination. A documented policy and process for evaluating whether ongoing development activities represent capitalizable enhancements (adding new functionality) or non-capitalizable maintenance (preserving existing functionality). This distinction frequently generates audit questions.
Impairment Review Triggers. A process for monitoring project health and identifying triggering events that require impairment assessment of capitalized software balances.
Practical Examples Illustrating Cost Treatment
Example 1: ERP Implementation
A manufacturing company contracts with a major ERP vendor to implement a cloud-hosted enterprise resource planning system. The vendor provides no software license — the company receives hosted access to the platform. The company incurs costs for internal project management during initial planning, third-party consultants to configure the system, internal developers to build custom integrations, and employee training.
Under asc 350-40 internal-use software guidance as amended by ASU 2018-15: planning costs are expensed; configuration and integration development costs in the application development stage are capitalized; training costs are expensed regardless of timing; the monthly hosting fees are expensed as incurred.
Example 2: Agile Product Development at a SaaS Company
A technology company develops a new AI-powered analytics module for its hosted platform. Development occurs in two-week sprints using an agile methodology. In early sprints, engineers are exploring whether a novel machine learning approach is technically feasible. Later sprints involve building and testing resolved functionality.
Under the ASU 2025-06 framework, capitalization would not begin during early sprints where significant development uncertainty exists around the novel ML approach — even if management has committed funding. Once coding and testing demonstrate the novel features are achievable, significant development uncertainty is resolved and capitalization of subsequent costs becomes appropriate.
Example 3: Enhancement vs. Maintenance
A company continues to incur ongoing software maintenance and customer support costs after go-live. After a few months, the management team allocates resources to provide an upgraded user interface with enhanced functionality. Monthly fees for the maintenance and customer support contract are expensed in the period incurred. The portion of the salaries attributable to the internal developers’ time to develop the upgraded user interface and enhanced functionality are capitalizable.
Frequently Asked Questions
What is the difference between capitalizing and expensing software costs under ASC 350-40?
Capitalizing means recording a cost as a long-lived asset on the balance sheet and recognizing its impact on the income statement gradually through amortization over the software’s useful life. Expensing means recording the cost immediately on the income statement in the period it is incurred. ASC 350-40 creates a structured approach to this decision-making process, ensuring that financial reporting for these investments is comparable across companies and industries. The stage of development and nature of the cost determine which treatment applies.
Does ASC 350-40 apply to SaaS subscriptions?
The ongoing subscription fees for a cloud-based service that does not include a software license are expensed as incurred. However, the implementation costs a company incurs to set up and configure the SaaS platform — if they occur during what would be considered the application development phase — can be capitalized under ASU 2018-15’s amendments to asc 350-40 internal-use software guidance.
When does ASU 2025-06 become effective?
ASU 2025-06 is effective for annual periods beginning after December 15, 2027, including interim periods within those annual periods, for all entities. Early adoption is permitted. Entities should assess the impact on existing capitalized balances and current practices well ahead of the mandatory effective date.
What are the two conditions required to capitalize costs under ASU 2025-06?
Under the amendments, entities are required to capitalize internal-use software costs only when both of the following conditions are met: Management has authorized and committed to funding the software project; and it is probable that the project will be completed and the software will be used to perform its intended function.
How is capitalized internal-use software amortized?
Capitalized internal-use software is generally amortized on a straight-line basis over its estimated useful life, beginning when the software is ready for its intended use. For cloud computing implementation costs, the amortization period is expressly limited to the non-cancellable term of the CCA plus periods for which the entity or the cloud service provider has an option to extend.
What disclosures are required for capitalized software costs?
Entities are required to disclose the capitalized internal-use software balance and accumulated amortization at the balance sheet date, the amortization expense for the period, and a general description of the method used in computing amortization. The disclosures required under ASC 360-10 for property, plant, and equipment also apply to capitalized software costs under the updated guidance.
What happens when a software project is abandoned?
Capitalized costs associated with an abandoned project are generally written off when the abandonment decision is made, creating a loss on abandonment recognized in the income statement. The remaining carrying value of the abandoned software must be evaluated for impairment, and if no future economic benefit is expected, the asset is written down to zero or its net realizable value.
How does ASC 350-40 treat training costs?
Training costs are always expensed as incurred, regardless of which development stage they occur in. This is true for both traditional on-premises software development and for cloud computing implementation arrangements under ASU 2018-15.
What is significant development uncertainty under ASU 2025-06?
Significant development uncertainty exists when the software involves technological innovations or novel, unproven features whose feasibility has not been confirmed through coding and testing, or when significant performance requirements have not been identified or continue to be substantially revised. The presence of significant development uncertainty prevents the “probable-to-complete” threshold from being met, delaying capitalization under asc 350-40 internal-use software rules.
Does ASU 2025-06 affect external-use software accounting?
No. No changes were made to the external-use software guidance in ASC 985-20, Software — Costs of Software to Be Sold, Leased, or Marketed. The ASU 2025-06 amendments are limited to the internal-use software framework in ASC 350-40 and the integration of website development cost guidance from ASC 350-50.
Looking Ahead: Preparing for the New Framework
The shift from a stage-based model to a principles-based two-condition framework represents more than a technical accounting change. It requires a fundamental rethinking of how finance teams collaborate with engineering, product, and IT leadership to make and document capitalization decisions.
Under the old model, the determination of development stage was largely an accounting function — auditors could review project documentation and map activities to stages. Under ASU 2025-06, asc 350-40 internal-use software compliance requires real-time collaboration between finance and technical teams to assess and document:
- When has management formally authorized and committed funding?
- What constitutes significant development uncertainty for this specific project?
- How does the company define and evidence the resolution of that uncertainty through coding and testing?
- Which costs are attributable to features that have cleared the uncertainty threshold versus those still in uncertain territory?
These are cross-functional questions that require shared governance frameworks, documented escalation procedures, and regular touchpoints between accounting and technology leadership. Companies that build these processes now — before the 2027 mandatory effective date — will be better positioned for a smooth transition and a cleaner audit.
The broader trajectory of GAAP is toward principles-based guidance that can adapt to evolving business practices without requiring a new standard every time development methodologies change. ASU 2025-06’s treatment of asc 350-40 internal-use software reflects this philosophy: by anchoring capitalization to economic substance (management commitment and probability of completion) rather than procedural stage gates, the FASB has created a framework designed to remain relevant as technology continues to evolve.
For finance professionals navigating these rules today, the imperative is clear: understand both the existing three-stage model (which remains effective for most entities through 2027) and the new principles-based framework, build strong documentation disciplines for capitalization decisions, and ensure that financial reporting accurately reflects the economic substance of your organization’s software investments.
