If your organization builds software the agile way — iterative sprints, continuous testing, evolving requirements — you already know that modern development rarely follows a straight line. Yet until recently, the accounting rules governing when to capitalize software costs were built for a world that no longer exists: one where development unfolded in neat, sequential stages. FASB’s newly issued ASU 2025-06 finally closes that gap, and it brings meaningful implications for how your finance team records, documents, and discloses technology investments.
Why the Old Rules No Longer Fit
Under the previous guidance in ASC 350-40, capitalizing internal-use software costs depended heavily on identifying which predefined “stage” of development a project was in — preliminary, application development, or post-implementation. That model made sense decades ago when software was built using waterfall methodologies with clearly defined phases. But for organizations using agile or iterative development — where coding, testing, and requirement-setting happen simultaneously and continuously — mapping costs to those stages was an exercise in frustration and guesswork.
“The stage-based model created real tension for technology-forward organizations,” said Jeff Parsell, Partner-in-Charge of Audit and Assurance Services at Windes. “Finance teams were trying to force modern development workflows into an outdated accounting framework, which led to inconsistency, increased audit scrutiny, and a lack of confidence in the numbers.”
ASU 2025-06 eliminates all references to development stages entirely. In their place, FASB introduces a principles-based, methodology-neutral framework built around two clear criteria: management has formally authorized and committed to funding the project, and it is probable the project will be completed and used for its intended purpose. Rather than asking “what stage are we in?”, finance teams must now ask “is this project approved, funded, and reasonably certain to succeed?” That is a more honest reflection of how software decisions are actually made.
The New Judgment Call: Significant Development Uncertainty
The heart of the new standard is the concept of “significant development uncertainty.” Capitalization must be deferred if a project involves novel or unproven technology whose key questions have not yet been resolved through coding and testing, or if the software’s core performance requirements are still undefined or in flux. Once that uncertainty is resolved — through successful testing, formal design acceptance, or documentation confirming technical feasibility — capitalization can begin.
For companies deploying software via cloud computing or SaaS arrangements, this is especially noteworthy. FASB has indicated that the new threshold could result in less capitalization for these projects, given that uncertainty in hosted environments often persists until late in the development cycle.
“The shift to a probability-based model puts more responsibility on finance and IT teams to work closely together,” said Parsell. “Documentation of when technical uncertainty is resolved is going to be critical to support capitalization decisions.”
What You Should Be Doing Right Now
ASU 2025-06 is effective for annual periods beginning after December 15, 2027, with early adoption permitted, but waiting until then to prepare is a mistake. Here is where organizations should focus their attention now:
- Revisit your capitalization policies. Update your accounting policies to reflect the new “probable-to-complete” threshold and remove any references to development stages. Make sure the criteria for management authorization and funding commitment are clearly defined and consistently applied.
- Strengthen your documentation practices. Build a documentation trail that clearly captures when management authorization occurred, when funding was committed, and when technical feasibility milestones were reached. This evidence will be essential for auditors.
- Align your IT and finance teams. The new standard requires finance professionals to understand technical development milestones, and IT teams to understand accounting triggers. Start building that cross-functional communication now.
- Evaluate your transition method. ASU 2025-06 permits prospective, modified retrospective, and full retrospective transition approaches. Each has different implications for comparability, retained earnings, and system readiness. Evaluate the tradeoffs in the context of your specific portfolio of in-progress projects.
- Review your disclosure readiness. The new standard partly aligns disclosures with ASC 360-10 (Property, Plant, and Equipment), requiring entities to present capitalized software balances, accumulated amortization, and descriptions of significant ongoing projects. Assess whether your current reporting infrastructure can support these expanded disclosures.
Let Windes Help You Get Ahead of the Change
At Windes, we understand that accounting standards do not exist in a vacuum — they have real operational, financial, and strategic consequences. Our audit, advisory, and technology professionals work collaboratively to help organizations assess the impact of new standards like ASU 2025-06, update internal controls and policies, and prepare for adoption well ahead of the deadline.
Whether you are a technology company navigating complex software capitalization decisions or a multi-industry organization managing numerous software initiatives, Windes has the expertise to help you move forward with confidence.
