FASB just did something that a lot of finance teams have quietly wanted for years: it took the old stage-based software cost model, rolled it into a ball, and threw out the parts that no longer matched how software is actually built. On September 18, 2025, FASB issued ASU 2025-06 (final standard; Chair report), “Targeted Improvements to the Accounting for Internal-Use Software.” If your teams build in sprints, standups, and overlapping design-test-release cycles, that matters.
The headline is simple: the stage-based capitalization model for internal-use software is gone. No more pretending that software development cleanly breaks into neat little boxes called preliminary project stage, application development stage, and post-implementation stage. That world never really existed outside a textbook, a control matrix, and a hopeful memo.
What Changed
Under ASU 2025-06, FASB removes the project-stage references from Subtopic 350-40 and replaces them with a single recognition framework. The question is no longer, “Which stage are we in?” The question is, “Has management authorized and committed to funding the project, and is it probable that the project will be completed and the software will be used for its intended function?”
That sounds more like how software gets built in 2025, because it is.
Teams do not march in formation from planning to build to launch. They iterate. They pivot. They discover that the “simple” internal dashboard now needs role-based permissions, an audit trail, API integrations, and one more round of testing because the model output gets weird when legal opens the file. Stage gates were always a rough proxy. In agile environments, they were often fiction with a PowerPoint cover.
FASB also clarifies that if there is significant development uncertainty, the probable-to-complete threshold is not met until that uncertainty is resolved. So this is not a free pass to capitalize everything with a GitHub repo and a dream. It is still a judgment framework, just one that is less tied to calendar theater.
And yes, the update also folds in the website guidance that used to live in Subtopic 350-50. Websites no longer get their own little accounting island. They are now part of the same broader internal-use software framework. Which, frankly, is long overdue.
Why FASB Moved
The Board is not pretending this change is just a tidy cleanup. The basis for conclusions makes the problem plain: there has been real diversity in practice, and the old model does not map cleanly to how software projects actually operate.
That shows up everywhere:
- ERP implementations where configuration, testing, and user acceptance overlap
- Internal tools that start as a lightweight workflow app and end up as a mini-platform
- Hybrid arrangements where on-premises software and cloud services are glued together with custom code and prayers
- AI-enabled internal applications where model integration, data pipelines, and interface work are all happening at once
The old model encouraged people to spend time proving they had crossed a stage boundary when the real issue was whether the project had moved from speculative idea to probable completion. FASB is pushing the analysis back toward substance. A rare event. Almost refreshing.
The Board also seems comfortable leaving room for judgment. That is a recurring theme in the final standard. In plain English: management is still expected to think, document, and defend its conclusions. Accounting is not becoming automatic. It is becoming more honest.
What CFOs Should Do Now
If you are a CFO, controller, FP&A lead, or valuation analyst, this is not something to file under “interesting but not urgent.” It affects policy, close process, audit support, and transaction work.
Start with the obvious: inventory your software portfolio. That includes internal ERP modules, data platforms, customer portals, operational tooling, and in-house applications that support revenue, compliance, or administration. Then separate the projects that are truly in process from the ones that are already in service but still getting “enhancements” every other Friday.
Next, update the policy memo. If your capitalization policy still reads like a waterfall model from 2008, it needs a rewrite. The policy should now track:
- management authorization and funding commitment
- the probable-to-complete threshold
- significant development uncertainty
- the specific nature of eligible costs
- the treatment of ongoing maintenance, support, and training
That last part is where teams get lazy. They capitalize because a project exists, then expense because a category sounds boring. The standard does not care about the mood of the month. It cares about the nature of the cost.
You should also revisit controls around time capture, project coding, and approval workflows. If your software teams are still booking labor against broad buckets like “Product Dev Misc,” this change will not magically fix the mess. It just makes the mess easier to see.
And if you are in a technology due diligence or 409A process, this is exactly the sort of accounting change that can affect how you read the balance sheet. Software capitalization policy can move operating expense, intangible asset balances, amortization, and normalized EBITDA. That means it can influence valuation conclusions, purchase price negotiations, and how much confidence anyone has in the numbers. In diligence, “we think we’ve always done it this way” is not a control. It is a liability with a smile.
Timing Matters
The effective date is not immediate, but it is real: the new guidance applies for annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods. Early adoption is permitted.
That gives companies time, but not much room for complacency. If you are already in the middle of a financing, audit cycle, or acquisition process, you should not wait until the adoption date to understand how the new model changes your project accounting. The worst time to discover a software capitalization issue is when the diligence room is already full and someone is asking why your “temporary workaround” has been in place for three years.
The transition options also matter. FASB permits prospective adoption, a modified transition approach, or retrospective application. For some companies, especially private businesses with significant in-process development, the modified approach may be the least painful route. For others, prospective adoption will be cleaner. The right answer depends on the mix of projects, the volume of historical capitalization, and how much you enjoy reconstructing old project files at midnight.
The Bottom Line
ASU 2025-06 is not just a technical cleanup. It is a recognition that software development no longer behaves like the accounting model built around it.
The practical effect is straightforward: stop treating stage labels as the source of truth. Start treating funding authorization, completion probability, and development uncertainty as the real gatekeepers. That shift should improve consistency, reduce arbitrary line-drawing, and make capitalization decisions easier to defend when auditors, investors, or buyers start asking uncomfortable questions.
Which they will. They always do.
If you are refreshing your accounting policy, preparing for a diligence sprint, or pressure-testing a software-heavy 409A analysis under the updated standard, this is the time to tighten the documentation and make sure your capitalization logic actually matches how the product is built. Because software may be eating the world, but that does not mean your accounting policy should be eaten by it.
Related posts
Anthropic at $380B: What a 6x Valuation Jump in 12 Months Tells Us About AI Markets
Anthropic’s move to a $380 billion valuation is more than a headline-grabbing fundraise; it is a useful stress test for how AI markets are pricing growth, scarcity, and risk.
Read moreMeta's $14B Scale AI Deal: The Biggest AI Acqui-Hire in History
Meta’s $14.3 billion Scale AI transaction is a minority-stake deal that looks a lot like an acqui-hire, with major implications for AI valuation and control.
Read moreGoogle Buys Wiz for $32B: The Largest Cybersecurity Acquisition in History
Google’s $32 billion agreement to acquire Wiz is a landmark cybersecurity deal, and it says plenty about cloud security, antitrust risk, and valuation discipline.
Read more