Most finance functions do not currently know what proportion of their capitalised development cost was produced with generative tooling, or whether their stated useful life still describes what engineering is doing.
Both questions are answerable in weeks. Both are easier to answer before they arrive from an auditor or audit committee.
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?
There is no universal answer. That is why the organisation needs a documented position rather than an inherited convention.
A development portfolio now contains two materially different populations.
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.
Ask one question outside finance. For any AI component inside a product or platform supported for years, ask who owns its replacement path and what exercising that path would cost. That number is rarely calculated, and it determines whether the durable population is genuinely durable.
None of this requires a transformation programme. It requires two estimates, one memorandum and a configuration change—and it is considerably cheaper to do before the question arrives.
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.