The new standard blocks capitalization while functionality remains "novel, unique, or unproven." That is not a description of an edge case. It is the definition of an AI project.
Accounting standards rarely change what a company does. This one might, because it changes who has to defend the spending — and inside most organizations, that is the variable that decides whether a project survives its second year.
What changed
FASB issued ASU 2025-06 in September 2025. It scraps the familiar stage-based model for internal-use software — preliminary project stage, application development stage, post-implementation — under which the middle stage was where costs became capitalizable.
In its place sits a principles test with two conditions: management has authorized and committed funding to the project, and it is probable the project will be completed and the software used as intended.
Then comes the sentence that matters. Costs cannot be capitalized while "significant development uncertainty" exists — and the standard describes that uncertainty as arising from technological innovations or novel, unique, or unproven functions, unresolved until the work is carried through coding and testing.
Separately, internal-use software moves under property, plant and equipment disclosure requirements rather than intangibles. Effective for annual periods beginning after December 15, 2027, for all entities, with early adoption permitted.
Read the uncertainty test back and ask what it excludes. Novel functionality. Unproven functionality. Technological innovation. Uncertainty that cannot be resolved until you have coded it and tested it. That is not a carve-out for exotic projects — it is a description of every machine learning initiative in the building.
Why this hits AI specifically
Conventional enterprise software development has low development uncertainty in the sense the standard means. You know a workflow application will work. The risk is schedule, scope and adoption — not whether the thing is technically achievable.
AI work inverts that. The central question is usually whether the model will perform adequately on your data, and the honest answer before building is that nobody knows. That uncertainty is not resolved by design review or by a proof of concept on a clean sample. It is resolved, if at all, by building and evaluating — which is precisely the condition the standard says blocks capitalization.
The consequence is arithmetic. Spend that would previously have been capitalized and amortized across several years now lands in the P&L in the period it is incurred. Same project, same cash, same value — different line, different year, different visibility.
Visual 1 — Where the same work now lands
Type of work | Under the stage-based model | Under ASU 2025-06 |
|---|---|---|
Configuring a purchased application | Capitalized in the development stage | Broadly unchanged — low development uncertainty |
Building a conventional internal workflow tool | Capitalized | Broadly unchanged, subject to the authorization and probable-completion test |
Applying an established ML pattern to your own data | Capitalized once development began | Contested — depends on whether performance on your data is genuinely uncertain |
Building a novel model or agentic system | Capitalized once development began | Expensed until the uncertainty is resolved through coding and testing |
Evaluation, fine-tuning and iteration cycles | Frequently capitalized as development | Hard to defend as capitalizable while performance remains unproven |
Disclosure treatment overall | Intangibles | Property, plant and equipment |
How to read it: The distinction the standard draws is between work whose outcome is knowable in advance and work whose outcome is not. Almost everything a company describes internally as "our AI investment" sits in the second category.
The consequence nobody is discussing is political
Here is the part that will matter more than the earnings effect, and it has nothing to do with accounting.
A capitalized project is an asset. It sits on the balance sheet, it amortizes on a schedule, and once approved it largely stops being re-litigated. The finance function defends it, because writing it off would be an impairment nobody wants to explain.
An expensed project is a cost. It appears in the operating budget every period, alongside headcount and travel and everything else competing for the same money. It gets re-argued at every planning cycle, by people whose own budgets would benefit from it losing.
Same initiative. Same expected value. Radically different odds of surviving to year three. Organizations that have been funding AI as capital expenditure are about to discover that the internal politics of the project were being subsidized by its accounting treatment.
And a second-order effect worth naming
Follow the incentive and it points somewhere uncomfortable. If novel and unproven work must be expensed while proven, conventional work can still be capitalized, then the accounting now favors the least differentiated version of any project.
Applying a well-established pattern to your own data is easier to defend as capitalizable than attempting something genuinely new. No standard-setter intends to shape R&D strategy, and no CFO will say the treatment drove the decision. But budgets respond to treatment, and over a few cycles that pressure is real.
The related fight over useful lives
ASU 2025-06 is not happening in isolation. The other live question in technology accounting is how long the hardware lasts.
Between 2020 and 2024, large technology companies steadily extended the assumed useful lives of servers and network equipment, which reduces annual depreciation and flatters earnings. In 2025 the consensus broke: Amazon shortened useful lives for a subset of servers while Meta extended further. Two companies buying comparable equipment for comparable workloads reached opposite conclusions about how long it lasts. Harvard Business School now teaches the Meta case.
One number to handle carefullyThe widely circulated figure of a $176 billion hit to 2026–2028 technology earnings is Michael Burry's estimate of what would follow if depreciation schedules moved from four-to-six years down to two-to-three. It is not a company disclosure, not an auditor's finding, and not a regulatory determination. We found no SEC investigation or auditor challenge on the point. It is being reprinted as though it were a fact. It is a projection premised on a change that has not occurred.
What to do before the standard bites
Inventory what you are capitalizing today and re-test it. Take the current schedule and apply the uncertainty question to each project: was the outcome knowable before we built it? The answers will sort quickly, and the total that fails the test is the number your CFO needs.
Get your auditor's reading of "significant development uncertainty" now. The phrase is principles-based, which means it will be interpreted, and interpretations harden. Establishing the position in 2026 with your own facts is a different exercise from receiving one in 2028.
Separate novel work from configuration work in your project records. If the distinction determines treatment, it has to be documentable — which means the time-tracking and project structure need to make the split visible. Retrofitting that classification later is expensive and unconvincing.
Model the P&L effect on a three-year view and show it to the board early. The transition year is where this gets misread as deteriorating performance. A margin decline caused by a change in accounting treatment looks identical to one caused by a change in the business, unless someone explains it in advance.
Decide deliberately on early adoption. Early adoption is permitted, and taking the hit while AI spend is still being framed as investment is a materially easier conversation than taking it later, when it looks like a reversal.
None of this changes whether an AI project is worth doing. It changes where the cost appears, who defends it, and how long it survives internal competition. That is a smaller thing than the earnings headline and a much larger thing than most technology leaders currently realize — and unlike almost everything else on the AI agenda, it arrives on a fixed date that is already in the calendar.
Sources and method. A BusinessInfomatics original. ASU 2025-06 was issued by the Financial Accounting Standards Board on September 18, 2025; the description of the principles test, the "significant development uncertainty" threshold, the shift to property, plant and equipment disclosure, and the effective date for annual periods beginning after December 15, 2027 with early adoption permitted, per Crowe and Deloitte. Divergence in server and network useful lives, including Amazon shortening for a subset of servers and Meta extending, per National Law Review; Harvard Business School case Meta: Accounting for AI Data Center Depreciation. The $176 billion figure is an estimate attributed to Michael Burry contingent on a change in depreciation schedules that has not occurred; it is not a company disclosure and no SEC or auditor action on the point was located. This article is journalism, not accounting advice — the application of ASU 2025-06 depends on facts and circumstances and should be determined with your auditor.
