If you are responsible for finance, there are two questions worth putting to engineering this quarter: what proportion of capitalised development was produced with generative tooling, and does the useful-life assumption still reflect how that software will be maintained or replaced? Many finance functions do not yet have those answers. Establishing an initial position now is considerably easier than reconstructing one after an auditor or audit committee asks.
What changed
In September 2025, the Financial Accounting Standards Board issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software. The amendments remove the old references to sequential project stages. Capitalization begins when management has authorised and committed funding and it is probable that the project will be completed and used as intended. The amendments are effective for annual periods beginning after December 15, 2027, with early adoption permitted.
That change modernises when costs begin to be capitalised. It arrives while a material share of development work is becoming generatively produced. Two shifts are interacting: a new recognition model and a different composition of development work.
The resulting balance-sheet position is defensible when the organisation can explain what it capitalised, how the work was controlled and why the useful-life estimate still reflects the economics.
Question one: what can you evidence?
The practical questions are specific: what was generated, by which tool and model version, under what internal policy, and whether the stated controls operated when the code entered the codebase. Provenance tooling is beginning to provide the equivalent of an AI bill of materials alongside the software bill of materials used by security teams.
The timing matters. Instrumenting this prospectively is inexpensive. Reconstructing it retrospectively across a year of commits is not. Where the record cannot be reconstructed, the distance between what an AI policy asserts and what the organisation can demonstrate becomes an assurance issue rather than an internal documentation gap.
What to establish: whether the development process currently records the tool, model and policy under which generated code entered the codebase. If not, treat that as a configuration change to make this quarter, not a future programme.
Question two: what is the useful life?
The appropriate useful life depends on the software and the organisation's maintenance strategy. Finance therefore needs a documented judgement that distinguishes at least two materially different populations in the development portfolio.
Software inside long-lived products and platforms sits inside equipment, devices or core systems carrying support obligations measured in years or decades. The code or its function is expected to persist, even if components beneath it require replacement.
Software regenerated at the pace of the tooling may be economically replaced well inside a conventional useful-life assumption because the practical cost of rewriting has fallen.
These populations can be amortised identically only if finance has concluded that one useful-life estimate remains appropriate. Otherwise the convention can be aggressive for the fast-moving population, conservative for the durable one and unexamined for both.
What to establish: the approximate split between those populations and whether the useful-life memorandum reflects it.
Why this is happening
The underlying cause is a mismatch that appears first in engineering and later in finance. Every component of an AI system—the model, runtime, libraries and hardware—has a supported life. A share of capitalised development now sits inside products or platforms with obligations that may outlive those components.
Ownership does not remove the issue. Owning weights eliminates one withdrawal risk and relocates obsolescence to the serving stack and hardware. Finance cares because that determines whether the “durable” population can actually be maintained and reproduced for the period assumed.
Four things to do this quarter
Get the split. Ask engineering for an estimate of what proportion of capitalised development in the last twelve months was generatively produced and how it distributes across long-lived and fast-moving software. Precision is less important than establishing the order of magnitude.
Write the useful-life memo before it is requested. Cover expected refresh cycle, product roadmap, support obligation and obsolescence risk. State explicitly whether one estimate covers the portfolio or why it should not.
Check what can be evidenced. Determine whether tool, model and policy are recorded when generated code enters the codebase. If not, fix it forward. Retrospective reconstruction is the expensive path.
Confirm the replacement accountability. For any AI component inside a product or platform supported for years, ask engineering who owns the replacement path, whether it has been tested and what exercising it would cost. Those answers inform whether the assumed support life is credible.
The immediate requirement is proportionate: obtain the two estimates, document the useful-life judgement and establish a process for recording provenance as generated work enters the codebase. Finance owns the accounting judgement; engineering provides the lifecycle and development evidence. Making those accountabilities explicit now reduces the cost of responding to a later challenge.
The technical argument behind this brief is developed in The Model Will Be Gone Before the Product Is. The full business-case implications are developed in The Three Clocks Behind the AI Business Case.