U.S. GAAP meets generative AI:
A practical guide for finance leaders navigating new ground.
AI spending is no longer speculative. Companies across every industry are committing real capital to build, fine-tune, and deploy AI tools. Some are developing their own foundation models. Others are layering generative AI on top of existing platforms, licensing third-party large language models, or building custom applications to drive internal productivity. The range of approaches is wide, and so is the range of costs involved.
That spending has to land somewhere on the financial statements, and figuring out exactly where is not always straightforward. The existing U.S. GAAP framework for software costs was built for a different era, and the iterative, data-intensive nature of AI development does not map cleanly to traditional accounting models. FASB issued ASU 2025-06 in September 2025, representing the most significant update to internal-use software accounting guidance in years. Finance leaders have a lot to work through.
For CFOs, controllers, and finance leaders navigating AI investment decisions, understanding the accounting treatment is not a back-office exercise. It shapes the income statement, the balance sheet, and how your board and investors see your AI strategy.
|
Table of Contents |
Step one: which framework applies today? |
Selecting the right standard
Before any AI-related cost can be capitalized or expensed, you need to know which accounting framework governs the project. For most AI expenditures, that determination hinges on how the software will be used.
Internal-use software: ASC 350-40
Software developed or acquired for internal use, or hosted and delivered to customers as a service, falls under ASC 350-40. This covers the majority of AI tools and applications that finance teams encounter today: internal productivity platforms, AI-powered analytics, hosted generative AI applications, and cloud-based deployments. Some popular generative AI applications qualify as internal-use software specifically because customers access them exclusively on a hosted basis.
Externally marketed software: ASC 985-20
Software developed with the intent to sell or license it externally falls under ASC 985-20. The threshold for capitalization is materially higher: all development costs are expensed as R&D until technological feasibility is established. Under the standard, technological feasibility is achieved when the entity has completed all planning, designing, coding, and testing necessary to establish that the product can be produced to meet its design specifications. This occurs through completion of either a detailed program design (reviewed for high-risk development issues with all uncertainties resolved) or a working model. In practice many software companies define feasibility as the creation of a working model, which typically occurs very late in the development cycle, meaning most costs end up expensed. ASC 985-20 is not affected by ASU 2025-06.
R&D software: ASC 730
Costs incurred to develop AI for research and development purposes are governed by ASC 730 and are expensed as incurred. No capitalization pathway exists for R&D-purposed development, regardless of the magnitude of the investment.
Data, hardware, and cloud: other standards apply
Data acquisition costs may qualify as intangible assets under ASC 350-30. Hardware and GPU infrastructure is capitalized as property and equipment under ASC 360. Cloud service arrangements require analysis for embedded leases under ASC 842. Most AI initiatives involve a mix of cost types, each subject to different rules, which is one of the key complexity drivers.
Applying ASC 350-40 to AI development (current guidance) |
The capitalization window under current guidance
For internal-use AI projects, the current ASC 350-40 framework organizes costs around three development stages. The stage a project is in at the time costs are incurred determines whether those costs are capitalized or expensed.
Preliminary project stage: expense as incurred
This stage covers conceptualization, technology evaluation, and architectural design. For AI projects it often includes deciding whether to build a proprietary model versus fine-tuning an existing foundation model, defining the model purpose and use cases, and assessing data requirements. All costs in this stage are expensed. The preliminary stage for AI projects frequently runs longer than for traditional software given the exploratory nature of early model experimentation.
Application development stage: capitalize eligible direct costs
Once management has committed to a specific design and allocated resources to see the project through, the application development stage begins. This is the capitalization window. Eligible costs include direct labor for data scientists and AI engineers, incremental training compute costs directly tied to development, external developer costs, and licensed data with no alternative future use incurred within the window.
Indirect costs are never capitalizable: facilities allocations, depreciation on shared servers, and IaaS fees for compute not exclusively tied to the specific development effort. The direct vs. indirect distinction requires careful documentation, particularly for AI projects where infrastructure often serves multiple purposes simultaneously.
Post-implementation stage: expense as incurred
Once the software is substantially complete and ready for its intended use, capitalization ceases and amortization begins. Capitalized costs are amortized over the software's estimated useful life using a method that reflects how the entity consumes the benefit, and the asset is subject to impairment assessment under ASC 350. If a project is abandoned, the capitalized asset is written off immediately. Ongoing maintenance, retraining that merely keeps the model current without adding new functionality, and user training are all expensed as incurred in this stage. Note also that data conversion costs are always expensed as incurred, even during the capitalization window. The line between capitalizable enhancements and maintenance is a recurring judgment call for AI systems that are continuously retrained.
|
Training costs and the coding analogy
LLM training is often described as the AI analog to coding. Traditional software development relies on developers explicitly specifying behavior; AI model behavior emerges from training on data. This distinction affects how costs are allocated and tracked. Finance teams need technical input to understand when activities cross from exploratory into committed development, and that input needs to be documented. |
The data cost question: a layer of complexity all its own |
Accounting for AI data costs
Data is not an afterthought in AI development. It is often the most significant cost driver, and it does not fit neatly into the software cost framework. U.S. GAAP does not contain specific guidance on accounting for data, which means entities must apply general intangible asset principles under ASC 350-30 alongside the software guidance.
Licensed data vs. internally generated data
For the most part, companies acquire data through licensing agreements rather than purchasing it outright. This distinction is significant: internally generated data costs are generally expensed as incurred, while licensed data is capitalizable under ASC 350-30 because it arises from identifiable contractual-legal rights. The asset is recognized at cost and amortized over its useful life with regular impairment assessments.
Does the data have alternative future use?
The single most important judgment for data cost accounting is whether the licensed data has alternative future use. For internal-use AI software, data with other uses to the entity is capitalized under ASC 350-30 and amortized over its useful life. Typically none of that amortization flows into the software asset itself (treated as an indirect cost). Data with no other uses follows the software development timeline.
For external-use software under ASC 985-20, licensed data with no alternative future use is expensed until technological feasibility is established, after which it may qualify as a capitalizable production cost. Once the software is available for general release, capitalization ceases and amortization begins using the greater of the straight-line method or the ratio of current revenue to total expected revenue. Licensed data with alternative future use is capitalized under ASC 350-30 with amortization allocated across projects and uses.Retraining costs: enhancement or maintenance?
Continuous retraining is a core feature of how AI systems operate, and the accounting for that ongoing investment depends on what the retraining actually accomplishes. Retraining that adds new capabilities is an upgrade or enhancement and costs may be capitalized. Retraining that simply keeps the model current without expanding functionality is maintenance, and those costs are expensed as incurred.
|
Data licensing: timing creates complexity
Data licensing agreements often span multiple years with new data delivered throughout the license period. Costs under a single arrangement may be treated differently depending on where the software project is in its development lifecycle when those costs are incurred. Tracking that allocation requires systems designed for it, not retrofitted after the fact. |
What changes under ASU 2025-06 |
The new principles-based model
Issued in September 2025 and effective for fiscal years beginning after December 15, 2027 (early adoption permitted), ASU 2025-06 is the FASB response to a straightforward problem: the three-stage model was built for waterfall development, and most companies no longer build software that way. The new guidance replaces the stage-based model with a principles-based framework better aligned with how software, including AI software, is actually built today.
The two new capitalization conditions
Under ASU 2025-06, capitalization begins when both of the following conditions are met: management has authorized and committed to funding the software project, and it is probable the project will be completed and the software will be used to perform the function intended. The stage-based model is eliminated entirely.
Significant development uncertainty: the new gating concept
The most important addition in ASU 2025-06 is the explicit introduction of significant development uncertainty as a barrier to the probable-to-complete threshold. If significant uncertainty exists, capitalization cannot begin until that uncertainty is resolved, even if management has authorized and funded the project.
The standard identifies two situations where significant uncertainty typically exists: the software includes novel, unique, or unproven functions or features whose related uncertainty has not yet been resolved through coding and testing; or significant performance requirements are unstable or have not been agreed upon. For AI projects, novel architectures, experimental training approaches, and shifting performance requirements are common early-stage characteristics.
What does not change
ASU 2025-06 does not change what types of costs are eligible for capitalization. Training costs, data conversion, and maintenance continue to be expensed. The capitalization period still ends when the software is substantially complete. And ASC 985-20 is not affected.
Transition options
Three approaches are available: prospective, modified prospective, or retrospective. Companies with substantial AI investment activity should start their transition analysis well ahead of the mandatory effective date.
| Practical judgments and governance |
Where the work actually happens
The shift to a principles-based framework does not reduce the amount of judgment required. It changes where that judgment is applied. The critical questions are not primarily technical accounting questions; they are questions about what the organization is doing, at what level of commitment, and with what degree of confidence in the outcome.
Management authorization: what counts?
Authorization must reflect a genuine commitment to funding the project through completion. Examples include board or executive approval of development expenditures, execution of a contract with a third party, or approval of a project budget with identifiable milestone commitments. Finance teams should work with legal, IT, and business counterparts to ensure authorization events are documented in a way that supports the accounting conclusion.
Resolving significant development uncertainty for AI projects
For AI projects, the question of when significant development uncertainty has been resolved is particularly nuanced. The technical team view of when uncertainties are substantively resolved is central to the accounting determination. A practical approach is to build formal checkpoints into the development governance process where technical leads assess and document the status of significant uncertainties.
Direct vs. indirect costs: the infrastructure challenge
AI development frequently involves infrastructure, compute, and data resources that serve multiple purposes simultaneously. A GPU cluster used both for a specific training run and for ongoing production inference is not cleanly allocated as a direct cost of the development project. Allocating direct compute costs to specific projects requires either dedicated infrastructure or robust tagging and allocation methodologies. Building that capability before the next large AI initiative significantly reduces audit friction.
Documentation and internal controls
The principles-based framework in ASU 2025-06 places a premium on documentation. Authorization events, funding commitments, uncertainty assessments, direct cost allocations, and the engineering basis for enhancement vs. maintenance determinations all need to be captured contemporaneously. External auditors are increasingly attentive to documentation supporting AI cost capitalization.
|
Key governance actions
Update software capitalization policies to reflect current ASC 350-40 and the ASU 2025-06 framework for when you adopt. Establish cross-functional protocols between finance, engineering, and IT for project authorization, uncertainty assessments, and enhancement vs. maintenance determinations. Design cost-tracking systems to capture direct development costs at the project level. Engage your external auditors early on AI-specific accounting positions.
|
Beyond the accounting: what this means for corporate finance and FP&A |
The corporate finance implications
The accounting framework for AI costs is not just a reporting question. The choices finance teams make about how to categorize, capitalize, and track AI spending have direct implications for budgeting, forecasting, performance measurement, and strategic planning.
Capitalization vs. expensing: the P&L and balance sheet trade-off
Capitalizing AI development costs defers income statement impact, improving near-term reported earnings and EBITDA. The offset: capitalized costs create ongoing amortization that must be forecast, and write-offs hit the income statement if a project is abandoned or technology becomes obsolete ahead of schedule. In a fast-moving AI landscape, useful life assumptions made today may require revisiting sooner than expected.
Budgeting for AI: building the right cost architecture
FP&A processes built for traditional software budgets are not equipped for AI cost structures. Structure AI project budgets with cost categories that correspond to accounting treatment: direct development labor, licensed data by use, dedicated infrastructure, general infrastructure, and post-deployment maintenance. This granularity makes the accounting cleaner and gives FP&A a more accurate model of true economics.Useful life assumptions: a strategic input
How quickly does AI capability evolve in your domain? When will the model be replaced? These answers drive amortization schedules, balance sheet carrying values, and the cost basis against which the investment is measured. Technology leadership should be part of this conversation, and assumptions should be revisited as the landscape shifts.
Build vs. buy vs. license: accounting is part of the analysis
Building proprietary AI under ASC 350-40 creates a capitalizable asset. Licensing API access to a foundation model is typically a period cost. Buying a platform may be a capitalized intangible, a SaaS expense, or a hybrid, depending on delivery model. Finance leaders who understand these implications can structure agreements to optimize both operational and accounting outcomes.
Investor communication and disclosure
Under ASU 2025-06, disclosure requirements are expanded. Beyond the minimums, proactive disclosure about the economics and expected returns of significant AI investments strengthens investor confidence and reduces friction at earnings calls.
What to do now |
The combination of accelerating AI investment and changing accounting standards creates a window where organizations that act proactively will be better positioned. ASU 2025-06 is effective for calendar year-end companies in 2028, but the transition analysis, policy updates, and system changes take time. Companies making significant AI investments today need to apply current guidance correctly and build the infrastructure to support that accounting.
- Inventory current AI investments and map them to applicable accounting frameworks to identify gaps in current treatment
- Assess whether existing cost-tracking systems can capture direct vs. indirect development costs at the project level
- Establish cross-functional governance protocols bringing finance, engineering, and IT together on authorization, uncertainty assessments, and enhancement vs. maintenance determinations
- Document current accounting policies for software and AI costs, including the basis for capitalization decisions and useful life assumptions
- Begin a readiness assessment for ASU 2025-06, including identifying in-process projects affected, evaluating transition approach options, and assessing disclosure impacts
- Engage your external auditors on AI-specific accounting positions, particularly for novel or high-value development projects where judgment is significant
|
How Embark can help
Embark's technical accounting team works with companies at every stage of AI investment, from early-stage planning through post-deployment accounting and disclosure. We help finance leaders apply the right framework to AI-related costs, build the governance infrastructure to support consistent accounting, and prepare for the transition to ASU 2025-06. Reach out to our team. |
