When the FASB modernized its software guidance, it reshaped how every company that builds internal software must approach the internal control assessment over capitalized costs. ASU 2025-06, issued in September 2025, retires the long-standing project-stage model in Subtopic 350-40 and replaces it with a probable-to-complete capitalization threshold. The shift moves judgment out of a rigid timeline and into the hands of management, which means your controls, documentation, and audit trail all need to change with it.
Quick answer: ASU 2025-06 eliminates the three-stage model for internal-use software and requires entities to capitalize development costs once two conditions are met: management with the relevant authority has authorized and committed to funding the project, and it is probable the software will be completed and used to perform the function intended. The standard is effective for annual reporting periods beginning after December 15, 2027, including interim periods within those years, with early adoption permitted.
What Changed Under ASU 2025-06
For decades, Subtopic 350-40 told companies to capitalize software costs based on which of three stages a project occupied: the preliminary project stage, the application development stage, and the post-implementation or operation stage. Costs in the preliminary and post-implementation stages were expensed, while qualifying costs in the application development stage were capitalized. The model worked when software followed a predictable waterfall path with a clear design phase before coding began.
Agile, iterative, and continuous-delivery development broke that assumption. Teams now plan, build, test, and release in overlapping sprints, so the boundaries between “preliminary” and “application development” became artificial and difficult to track. The FASB heard consistent stakeholder feedback that the stage-based rules were hard to apply and produced inconsistent results across companies running similar projects. Modernizing this guidance was a top priority identified by stakeholders during the Board’s last agenda consultation.
ASU 2025-06 removes all references to project stages from Subtopic 350-40. In their place sits a single principles-based recognition threshold that does not depend on the development method an entity uses. The Board designed the new guidance to stay neutral across waterfall, agile, and whatever methodologies emerge later, according to the FASB’s announcement covered by the Journal of Accountancy.
That neutrality is the point. Rather than forcing modern development into stage labels that no longer fit how engineering teams work, the standard asks a question that applies regardless of method: has the entity committed to the project, and is it probable the project gets finished. The guidance is meant to produce more consistent results across companies pursuing similar work.
The Probable-to-Complete Capitalization Threshold
Under the new rules, capitalization of internal-use software costs begins only when both of the following conditions are satisfied. First, management with the relevant authority has authorized and committed to funding the software project. Second, it is probable that the project will be completed and the software will be used to perform the function intended. The FASB labels the second condition the “probable-to-complete recognition threshold.” The term “probable” carries its Master Glossary meaning, that the future event or events are likely to occur.
The probable-to-complete assessment is not a one-time checkbox. Entities must evaluate whether significant uncertainty exists in the software’s development activities, and if it does, capitalization is delayed until that uncertainty is resolved. The standard identifies signals of significant development uncertainty, such as building technological innovations or novel, unique, or unproven functions where the related uncertainty has not been resolved through coding and testing. It also points to whether the entity has determined what it needs the software to do, including whether significant performance requirements are still being identified or substantially revised.
This is the heart of the change for finance teams. Instead of asking “what stage is this project in,” your controllers and engineering leads now ask “have we committed funding, and is it probable this gets finished and used?” The answer requires ongoing judgment supported by evidence, which is exactly why the standard reshapes the underlying control environment rather than just the journal entries.
The amendments also supersede the website development cost guidance that previously lived in a separate subtopic, Subtopic 350-50, and relocate it into the broader internal-use software framework in Subtopic 350-40. That consolidation applies the same probable-to-complete logic to website projects and adds an example illustrating how the guidance applies to website development. Companies that maintained distinct policies for website costs can simplify to one capitalization policy.
It is worth being precise about scope. The amendments apply to all entities subject to the internal-use software guidance in Subtopic 350-40, including the website development costs now folded into it. They do not affect software costs subject to Subtopic 985-20, which covers software to be sold, leased, or otherwise marketed.
Why This Reshapes Your Internal Control Assessment
A capitalization policy is only as reliable as the controls behind it, and ASU 2025-06 raises the stakes on management judgment. Because the trigger for capitalization is now “authorized and committed funding” plus “probable to complete,” someone has to own that determination, document it, and revisit it as facts change. Auditors will expect contemporaneous evidence rather than a stage label applied after the fact.
A defensible internal control assessment under the new model should address several control points. Management needs a documented funding authorization process that ties to specific projects and dollar amounts. Teams need a repeatable method for evaluating and concluding on significant development uncertainty, with sign-off from people who understand the technical work. Finance needs controls that stop capitalization promptly when a project loses funding, stalls, or is abandoned, so amounts are not carried on the balance sheet improperly.
These judgments cut directly across financial reporting risk, which is why companies should coordinate their software accounting policy with their broader audit and assurance services well before the effective date arrives. A control that exists on paper but produces no documentation will not survive testing. The earlier you build the evidence trail, the cleaner the first reporting period under the new standard becomes.
The judgment is also continuous rather than fixed at a single point. A project that clears the probable-to-complete threshold can later encounter new uncertainty, and a project mired in uncertainty can resolve it and qualify for capitalization. Your controls need to capture both directions, which means the people making the call have to reassess on a defined cadence and record what changed.
Smaller and privately held companies should not assume this is a large-company problem. Any entity that develops software for internal use, including custom enterprise systems, customer-facing portals, and internal automation tools, falls within Subtopic 350-40. The reduction in bright-line rules means more reliance on judgment, and more reliance on judgment means more reliance on well-designed controls.
Effective Date and Transition
ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027, including interim periods within those annual reporting periods. A calendar-year company therefore adopts the standard beginning January 1, 2028. The FASB permits early adoption in an interim or annual reporting period for which financial statements have not yet been issued or made available for issuance.
Entities can adopt the amendments using one of several transition approaches the Board provided: a prospective approach applied to costs incurred going forward, a modified transition based on the status of each software project, or a full retrospective approach that restates prior periods presented. Each method carries different disclosure and recordkeeping implications, so the choice should be made deliberately rather than by default. Confirm the specific transition options against the official standard before finalizing your plan, available directly from the FASB.
The runway is shorter than it appears once you account for policy drafting, system changes, and control implementation. Engineering project tracking systems often capture data by sprint rather than by funding decision or completion probability, so the data your accountants need may not exist yet in usable form. Begin the gap analysis now.
How to Prepare Before the Effective Date
Start by inventorying current and planned internal software projects and mapping how each is tracked today. Identify where your existing stage-based capitalization decisions are documented, because that documentation will need to be reframed around funding authorization and the probable-to-complete threshold. Where data lives in engineering tools rather than finance systems, plan the integration early.
Next, rewrite your capitalization policy to reflect the principles-based model and define who makes the probable-to-complete determination, on what cadence, and with what supporting evidence. Build the control activities that produce that evidence, including funding approvals, uncertainty assessments, and triggers to halt capitalization. Document the policy so it can be tested.
Then decide on your transition method and model its effect on prior comparative periods and opening balances. Coordinate the technical accounting conclusions with your auditors so there are no surprises in the first reporting cycle. Pairing the policy work with ongoing audit and assurance support keeps the documentation aligned with what an auditor will actually request.
Treat the period before adoption as a chance to run the new process in parallel. Applying the probable-to-complete threshold to live projects now, even informally, surfaces the data gaps and judgment disagreements while they are still cheap to fix. By the time the standard is mandatory, the policy, the controls, and the evidence trail should already be working together.
Frequently Asked Questions
When does ASU 2025-06 take effect?
The standard is effective for all entities for annual reporting periods beginning after December 15, 2027, including interim periods within those annual periods. Calendar-year entities adopt it starting January 1, 2028. Early adoption is permitted.
What replaced the project-stage model?
A single probable-to-complete capitalization threshold replaced the three-stage model. Companies now capitalize internal-use software costs once management has authorized and committed funding to the project and it is probable the software will be completed and used as intended, rather than keying capitalization to a preliminary, application development, or post-implementation stage.
What is significant development uncertainty?
Significant development uncertainty exists when meaningful doubt remains about whether the software can be completed and used as intended, such as when a project involves technological innovations or novel, unique, or unproven functions that have not been resolved through coding and testing, or when the entity is still identifying or substantially revising the software’s significant performance requirements. While significant uncertainty exists, the probable-to-complete threshold is not met, so related costs are expensed until the uncertainty is resolved.
Does ASU 2025-06 affect website development costs?
Yes. The standard supersedes the website development cost guidance previously housed in Subtopic 350-50 and relocates it into the internal-use software framework in Subtopic 350-40. Website projects are now evaluated under the same probable-to-complete threshold as other internal-use software, removing the need for separate accounting policies.
