What the New Software Accounting Rules Mean for Tech CFOs

Written by Larry Pirkle on January 30, 2026

Software Accounting Image

Technology companies rarely develop software in neat, sequential phases. Teams continuously deploy code, refine features through iterative sprints and evolve platforms long after the initial launch.

For years, accounting guidance for internal-use software lagged behind reality, forcing finance teams to fit agile development into linear accounting frameworks.

Then, in September 2025, the Financial Accounting Standards Board (FASB) issued Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, to modernize accounting for internal-use software.

The update simplifies the guidance and removes concepts that no longer reflect how software is actually built, creating a clear break from the framework finance teams have been navigating for years.

How the Old Software Accounting Rules Worked

Under previous guidance, organizations capitalized or expensed internal-use software costs based on predefined development stages:

  • Preliminary project planning
  • Application development
  • Post-launch

The rules permitted capitalization only during the application development stage, and companies generally expensed costs incurred before or after that window.

Previous Software Accounting Stages Image

These stage-based distinctions created confusion for companies operating with continuous development cycles. Teams struggled to determine when a project formally moved out of planning or when post-implementation truly began. As a result, similar initiatives were sometimes treated differently from an accounting perspective, even when operationally they were managed in the same way.

Over time, capitalization outcomes drifted away from how the organization actually made and governed software investment decisions.

Changes Under ASU 2025-06

ASU 2025-06 eliminates references to development stages and applies a single model across agile, iterative, waterfall and hybrid approaches. This framework aligns accounting treatment with how the organization approves and executes projects.

Capitalization is now triggered only when two conditions are met:

  1. Leadership has approved the project and committed funding
  2. It is probable that the software will be completed and used for its intended purpose

This replaces the stage-based approach with a principle-based model focused on commitment and feasibility.

The ASU also clarifies how to evaluate whether completion is “probable.” Finance teams must consider whether meaningful uncertainty remains around technical execution, funding or resourcing. Capitalization begins once a project moves beyond the exploratory or experimental work and there is a realistic path to completion.

For example, consider a technology company developing an internal analytics platform. During early sprints, engineers test multiple architectures without a formal budget. Under the new guidance, the company would expense these costs. Capitalization begins once leadership approves a defined roadmap, allocates funding and commits resources to deliver the platform for internal use.

Another major change is the consolidation of guidance for website and platform development. ASU 2025-06 eliminates separate accounting rules for website development. Internal portals, dashboards, platforms and tools are now all evaluated under the same internal-use software model.

ASU 2025-06 also updated disclosure requirements. Capitalized internal-use software costs now follow long-lived asset disclosure requirements, regardless of where they are presented on the balance sheet. Companies may need to expand disclosures to comply with the new standard even if the presentation does not change.

Software Accounting Capitalization Conditions Image

What Did Not Change

The update does not change which types of costs qualify for capitalization. Development-related labor, including coding, configuration and testing, may still be capitalized if it meets the capitalization threshold. Certain directly attributable hosting costs may also qualify.

Organizations should continue to expense costs related to data conversion, training, maintenance and ongoing support. Capitalization still stops when the software is ready for its intended use, even if enhancements or minor updates continue thereafter.

The guidance does not affect accounting for software developed for sale, licensing or marketing, and existing revenue recognition and external-use software rules remain intact.

Timing, Adoption and Transfer Considerations

The new guidance applies to fiscal years beginning after December 15, 2027, including interim periods within those years. Calendar-year private companies will adopt in 2028. Early adoption is permitted at the start of any annual reporting period, which may be attractive to organizations that already operate with formal approval and funding controls.

Companies can choose from several transition methods, including prospective adoption for new projects, modified retrospective adoption for active projects or full retrospective application.

This choice can affect trend data, internal performance metrics and how software investment appears over time. CFOs should evaluate transition options from a compliance perspective as well as for internal reporting, comparability and stakeholder communication.

How Technology CFOs Can Prepare for ASU 2025-06

The new guidance removes the need to force modern development practices into outdated accounting labels. Finance teams can focus on approval milestones, readiness and feasibility rather than debating whether work fits within a particular stage definition.

This alignment reduces pressure to capitalize costs simply because development has started and supports a more consistent application across projects.

It will be easier for technology organizations building interconnected platforms, portals and internal tools to apply and govern a unified accounting model. However, the change places greater emphasis on documentation of approvals, funding commitments and feasibility assessments. Companies should develop strong preventive controls for project governance, budgeting and decision-making to support capitalization decisions.

Ultimately, the ASU is an opportunity for CFOs to better align financial reporting with how the company plans, approves and executes software investments.

If you would like guidance on how the new internal-use software accounting rules affect your organization, reach out to a Warren Averett advisor to start the conversation.

Subscribe to the Newletter

Back to Resources
Top