FASB makes development uncertainty a software-cost evidence question

Define the accounting unit before applying the AI label

The direct CFO decision is not whether the initiative is called AI, a model, an agent, a data product, or a transformation program. It is which internal-use software component or module is being developed, what function it is intended to perform, and which costs belong to that unit. A single initiative may contain purchased services, internal code, configuration, data preparation, training, content, maintenance, and operating work that do not share one accounting conclusion.

Finance should require a versioned project boundary that identifies the legal entity, component, intended users, deployment purpose, hosting arrangement, development owner, funding authority, work breakdown, and cost-capture method. The record should separate accounting scope from the broader investment case: a project can meet a recognition threshold without proving return, and an economically valuable experiment can still contain costs that are expensed.

Build a dated probable-to-complete record

Funding authorization is necessary but not sufficient. The amended guidance also requires a conclusion that completion and intended use are probable. For a conventional configuration, that assessment may be straightforward. For an AI system whose significant behavior, integration, evaluation threshold, or operating requirement remains unsettled, the CFO should ask what evidence shows that the intended function is defined and the development path is no longer materially uncertain.

The file should preserve the date of the conclusion, named approver, significant performance requirements, unresolved functions, coding and test results, dependency assumptions, completion plan, intended-use evidence, and contrary facts. Product confidence, a prototype demonstration, vendor assurances, or a planned launch date should not be converted into accounting evidence without showing how they resolve the relevant uncertainty.

Separate development from training, data, and maintenance

AI projects often bundle work that finance must classify separately. Employee training is not software development. Data cleansing, reconciliation, creation, and conversion generally do not become capitalizable merely because a model needs them. Maintenance and unspecified enhancements have their own treatment, while software that enables access to or conversion of old data can fall within a different category. Contract labels and one blended implementation fee do not resolve those distinctions.

Require time, invoice, milestone, and acceptance evidence at the level needed to distinguish direct development from research, data operations, content, training, maintenance, hosting, support, and general administration. Where the evidence cannot support a reliable separation, keep the uncertainty visible and obtain qualified accounting review rather than allocating costs to reach a target margin or project narrative.

Reopen the conclusion when development facts change

An AI project can cross the threshold and later encounter a materially revised requirement, an unproven function, failed testing, a model or provider change, a suspended development plan, or evidence that completion is no longer probable. Capitalization should therefore be controlled by change events, not treated as a permanent status granted at project kickoff. The CFO needs a practical signal from engineering and product governance when the facts behind the conclusion move.

The review should record what changed, whether new uncertainty is significant, which costs and dates are affected, whether capitalization should cease, and whether existing balances require impairment consideration. ASU 2025-06 supplies accounting requirements; it does not determine the correct conclusion for a particular AI project. Current project evidence, the Codification, transition requirements, materiality, and qualified accounting and audit judgment control.

Turn this source into a reviewable decision

For AI for CFOs, use this briefing as a dated decision record rather than a substitute for the source. Preserve Financial Accounting Standards Board, the exact URL, the August 9, 2026 review date, the supported facts above, the editorial interpretation, the limitations, and any buyer-specific evidence. Link that record to the decisions most directly affected: Internal control and audit evidence; Management reporting and external disclosure support; Spend intelligence and procurement challenge; Planning and scenario analysis. State whether the source changes the scope, evidence requirement, control, sequence, or only the language used to describe the decision.

Before action, name the accountable owner, affected population and workflow, exact offering or configuration, source data and rights, human decision point, exception and appeal path, complete cost, expected benefit, failure and stop conditions, retained evidence, and next review date. Keep official facts, provider statements, buyer observations, representative tests, measured outcomes, editorial inferences, and unknowns visibly separate. Reopen the record when the source, offer, model, integration, data, policy, population, responsible person, or measured result changes.

Limitations and unknowns

ASU 2025-06 addresses internal-use software accounting and does not establish that every AI initiative is within its scope, determine the unit of account, classify a specific cost, prove technological feasibility, validate management estimates, or establish return. The amendments are effective for annual and interim periods beginning after December 15, 2027 unless an entity elects permitted early adoption at the beginning of an annual period. The Accounting Standards Codification is authoritative; transition, entity facts, materiality, contracts, project evidence, and qualified accounting and audit review control.