How To Account for AI Spend Under U.S. GAAP

Learn how to account for AI subscriptions, development, data, and product costs under U.S. GAAP.

Enterprise AI spending has grown significantly for many organizations over the past year. Multiyear platform agreements commonly run $1 million or more annually, with AI-embedded product development efforts adding to the total. Yet no AI-specific accounting standard exists within U.S. GAAP. Controllers, CFOs, and accounting policy specialists must navigate existing guidance, much of which was written long before generative AI existed. 

The frameworks that govern AI spend – Accounting Standards Codification (ASC) 350-40 (“Internal-Use Software”), ASC 730 (“Research and Development”), ASC 350-30 (“General Intangibles Other Than Goodwill”), ASC 985-20 (“Costs of Software To Be Sold, Leased, or Marketed”), and ASC 606 (“Revenue From Contracts With Customers”) – were not designed for AI, but they still apply. The following table shows four of the AI spend scenarios practitioners encounter most frequently and the frameworks that apply. 

Implications of ASU 2025-06: In September 2025, the Financial Accounting Standards Board (FASB) issued Accounting Standards Update (ASU) 2025-06, “Intangibles – Goodwill and Other – Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software,” which removes the three-stage model from ASC 350-40 and replaces it with a principles-based framework built around a “probable-to-complete recognition threshold” and a new concept of “significant development uncertainty.” The ASU is effective for annual periods beginning after Dec. 15, 2027, with early adoption permitted. Its implications are addressed for each of the four scenarios that follow.

For more information, see the Crowe article “FASB Revises Internal-Use Software Cost Guidance.”

Common AI spend scenarios

The central challenge in accounting for AI spend is that the facts can be novel, and existing GAAP does not always cleanly align with common AI development processes. Furthermore, a single AI development program can simultaneously touch several frameworks at once. Early-stage experimentation might meet the definition of research and development (R&D), bringing those costs within ASC 730. A committed application-development effort that follows falls under ASC 350-40. Data acquired from a third party falls under ASC 350-30. And revenue from selling the resulting capability to customers falls under ASC 606.

Before determining the appropriate accounting model(s), companies must correctly identify the nature of each arrangement and each element involved. The scenarios that follow work through four of the most common fact patterns.

Scenario 1: Enterprise AI platform subscription

This scenario applies to cloud-hosted AI platform agreements.

License or service: The threshold determination

Under ASC 350-40-15, a cloud computing arrangement (CCA) contains a software license only if the following two conditions are both met:

• The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
• It is feasible for the customer to run the software on its own or third-party infrastructure.

For most enterprise AI platforms, the customer receives access to the AI service, not the AI model itself. The vendor maintains control of the model, the customer does not have the right to take possession of it, and most companies cannot realistically run the model on their own systems. As a result, these arrangements often are accounted for as service contracts, not software licenses.

The accounting consequence is that the recurring subscription fee is recorded as a period expense. Unless prepaid and recorded as a prepaid asset, no basis exists to capitalize the subscription fee itself.

Implementation costs: Legacy GAAP framework

While the subscription fee often will not qualify for capitalization, entities must separately assess related implementation costs for capitalization under ASC 350-40. Until an entity adopts ASU 2025-06, ASC 350-40-25-18 requires the entity to evaluate implementation costs for possible capitalization as though the costs are part of an internal-use software project. The three-stage analysis applies:

1. Preliminary project stage (expense as incurred): Evaluating AI platform alternatives, proof-of-concept testing to determine whether the platform can meet requirements, and vendor selection.
2. Application development stage (eligible for capitalization): Coding integrations between the AI platform and internal systems, building data pipelines, configuring access controls, and integration testing. Qualifying costs in this stage are capitalized.
3. Post-implementation/operation stage (expense as incurred): User training, ongoing maintenance, and routine updates or modifications that do not add new functionality.

An implementation cost that is capitalized under ASC 350-40 must be recognized as a prepaid asset on the balance sheet (not as an intangible asset) and presented in the same line item as other prepaid expenses for the associated hosting arrangement. Such costs are expensed on a straight-line basis over the term of the hosting arrangement, including renewal option periods that are reasonably certain to be exercised. The expenses are recorded in operating expense because the arrangement is accounted for as a cloud computing service contract, not a software license.

Implications of ASU 2025-06: IASC 350-40-25-12A (as amended) delays capitalization when significant development uncertainty exists, including when uncertainty related to novel, unique, or unproven AI functionality has not been resolved through coding and testing or when significant performance requirements have not been identified or remain subject to substantial revision. The FASB noted in the basis for conclusions of ASU 2025-06 that the revised standard could result in a decrease in CCA implementation cost capitalization relative to current GAAP.

Crowe observation: The license-or-service determination must be made at contract inception based on actual contract terms rather than on a perceived “technology category” or vendor marketing. Agreements with multiple elements (for example, license, hosted storage, and so on) require separate analysis of each contractual element.

Scenario 2: Data acquisition for AI model training

This scenario applies to datasets purchased from third-party vendors, licensed data used to train or fine-tune AI models, and internal costs to collect, label, clean, and annotate training data.

ASC 730 and R&D-related acquisitions

Whether costs to acquire training data are an R&D expense or a capitalizable asset depends on the intended purpose of the acquired data at the time of the acquisition. Importantly, data purchased for use in an AI R&D program is considered purchased for use in R&D activities, regardless of whether the project ultimately succeeds and produces a deployed model.

When training data is acquired for use in R&D activities, ASC 730-10-25-2(c) explains that the accounting for the acquisition cost depends on whether the training data has an alternative future use beyond the specific R&D project. If no alternative future use exists, the acquisition cost is treated as an R&D expense when incurred. In contrast, if an alternative future use for the acquired data does exist, the acquisition cost would be capitalized in accordance with ASC 350.

Alternative future use exception

The alternative future use exception outlined in ASC 730-10-25-2(c) requires a substantive expectation of future use beyond the current R&D program, not a speculative possibility. Under ASC 730-10-25-4, this exception is limited to assets acquired from others. Costs related to internally developed assets and internal labor remain subject to the R&D expensing guidance.

Indicators that the exception applies:

• Licensing terms permitting use across multiple programs, products, or purposes
• A documented plan or reasonable expectation by the entity to use the data in production systems or additional programs beyond the current R&D effort
• General-purpose data with utility not exhausted by a single model training run
• Multiyear licensing structure consistent with ongoing production use

Indicators that the exception does not apply:

• License restricting use of a specific model or application
• Task-specific data that has no practical utility outside the current program
• One-time acquisition with no documented plan for reuse

Internal data preparation costs

Costs to collect, label, clean, annotate, and structure training data – whether by internal employee labor or third-party annotation services – are expensed as R&D when incurred in connection with an R&D program.

Data acquired for deployed production systems

Where data is acquired for direct use in an already deployed or committed production system, ASC 730 does not apply to that acquisition; it is not “for use in research and development activities.” Instead, the dataset is evaluated under ASC 350-30 on its own terms. Where recognition criteria are met, the dataset is recognized as an intangible asset and amortized over its estimated useful life.

The distinction between data acquired for R&D and data acquired for production is frequently a significant judgment when accounting for training data. The accounting outcome depends not on the nature of the data but on the status of the program at the time of acquisition and the purpose for which the data is acquired.

Implications of ASU 2025-06: ASU 2025-06 does not substantively amend ASC 730 or ASC 350-30. The R&D determination, the alternative future use exception, and the general intangible recognition framework are unchanged. The FASB decided not to address how current guidance applies to training data and data conversion costs, concluding that any such clarifications were beyond the scope of the project (paragraph BC66-67).

Crowe observation: Entities should design and implement internal controls documenting the accounting analysis, including judgments, conclusions, and program approval. An entity that acquires data during a development program and later characterizes it as a production-stage purchase, without documentation establishing that characterization at the time of acquisition, might be at risk of a material misstatement.

Scenario 3: Open-source model licensing and fine-tuning

This scenario applies to fine-tuning of open-source or structured-license foundation models for internal business applications. Where the entity embeds the fine-tuned model in products sold to customers, see Scenario 4.

The license and the fine-tuning: Two separate questions

The license of an open-source model and the fine-tuning that follows raise two distinct accounting questions under two different frameworks. Analyzing them together risks the wrong conclusion on both.

The license question resolves quickly in most cases:

• No-cost licenses (most open-source terms carry no fee): There is no acquisition cost, so there is nothing to capitalize under any framework.
• Fee-based licenses (enterprise arrangements with annual or usage-based fees): The fee is the cost of an acquired intangible asset under ASC 350-30-25-1, provided the recognition criteria are met. If the license is acquired in connection with an R&D program, the R&D guidance under ASC 730 applies instead.

The fine-tuning costs – for example, the labor, compute, and services incurred to adapt the model – are a separate question. An entity that downloads model weights and runs them on its own or contracted infrastructure has taken possession of software. That is different from Scenario 1, where the entity accesses a vendor-hosted model and never takes possession. Fine-tuning costs in this scenario are internal-use software development costs, evaluated under ASC 350-40 and potentially subject to the R&D guidance under ASC 730.

R&D versus application development

Under ASC 730-10-20, research is “planned search or critical investigation aimed at discovery of new knowledge with the hope that such knowledge will be useful in developing a new product or service (referred to as product) or a new process or technique (referred to as process) or in bringing about a significant improvement to an existing product or process.” Development is “the translation of research findings or other knowledge into a plan or design for a new product or process or for a significant improvement to an existing product or process whether intended for sale or use.”

The test is whether the entity is discovering whether an approach will work (R&D) or executing an established plan for a system it already knows will work (capitalizable application development). Activities that overlap in time and personnel still must be distinguished by their nature, not by who is doing the activities or when.

Capitalization threshold (current ASC 350-40)

Capitalization of application development stage costs begins when all of the following are true:

• The preliminary project stage is complete.
• Management with the relevant authority has authorized and committed to fund the project.
• Completion is probable.

For fine-tuning programs, this threshold generally is reached when the entity has determined which base model, fine-tuning methodology, and dataset it will use as well as when a qualifying management commitment decision has been made. Subsequent iterations that refine performance within that committed framework may be application development. Changes that revisit the fundamental technical approach may reopen the preliminary project-stage analysis.

Costs eligible for capitalization under ASC 350-40-30-1 include:

• Internal payroll (ASC 350-40-30-1(b)): Loaded payroll costs of AI engineers, data scientists, and machine learning infrastructure engineers directly engaged in qualifying application development-stage activities, to the extent of time spent directly on the project, supported by time-tracking records.
• External direct costs, including cloud graphics processing unit (GPU) and compute costs (ASC 350-40-30-1(a)): Costs attributable to production fine-tuning runs and infrastructure development, supported by usage logs and run manifests. Where project-level tracking is insufficient to support a reliable allocation between capitalizable and noncapitalizable usage, expensing all compute as incurred is appropriate.
• Interest costs (ASC 350-40-30-1(c)): Costs incurred while developing internal-use software.

Ongoing retraining after deployment

Retraining to address declining model performance, correct production errors, or make incremental adjustments within an established technical framework is generally post-implementation activity, expensed as incurred. Retraining that adds new functionality, modifies the underlying architecture, or adapts the model to a new use case generally constitutes a new development project and restarts the full analysis.

Implications of ASU 2025-06: Under ASU 2025-06, the significant development uncertainty assessment under ASC 350-40-25-12A (as amended) might lead to similar conclusions as the R&D analysis. Fine-tuning programs where novel or unproven AI capabilities have not yet been validated through coding and testing cannot meet the probable-to-complete threshold. The FASB observed in the basis for conclusions of ASU 2025-06 (paragraph BC57) that for novel or unproven software, the capitalization window might be narrow. Programs using established techniques for clearly defined use cases with identified and stable performance requirements might be less affected. 

Crowe observation: An entity that conducts exploratory fine-tuning experiments and then capitalizes the full development cost, including costs incurred during the experimental phase, on the grounds that the final model was placed in service is not applying the accounting model as intended. Exploratory costs are R&D at the time they are incurred and remain so regardless of the project’s ultimate success

Scenario 4: AI embedded in products sold to customers 

This scenario applies to software-as-a-service (SaaS) companies adding generative AI features to their platforms, professional services firms incorporating AI-powered analytics into managed service offerings, and any entity embedding AI capabilities into products or services sold, leased, or marketed to external customers. Scenario 4 raises both cost (ASC 985-20, ASC 730) and revenue (ASC 606) implications. 

Cost implications: ASC 985-20 and third-party costs

Scope determination

ASC 985-20 applies to software developed to be sold, leased, or otherwise marketed to external customers. Internal software infrastructure that supports a customer-facing product (for example, training pipelines, evaluation tooling, data processing systems, or model fine-tuning infrastructure) falls within the scope of ASC 350-40 as internal-use software, even when essential to the product’s functioning.

Technological feasibility: The standard and its application

Under ASC 985, costs incurred to develop software for sale are expensed until technological feasibility is established. Technological feasibility is met when the entity has completed all planning, designing, coding, and testing activities necessary to establish that the product can be produced to meet its design specifications, including functions, features, and technical performance requirements. Once established, qualifying costs are capitalized until the product is available for general release to customers. The establishment of technological feasibility may be demonstrated through either of the following:

• Detail program design. Under ASC 985-20-25-2(a), this path requires a completed product design; evidence that the entity has the necessary skills, hardware, and software technology to produce the product; documentation tracing the detail program design to product specifications; and resolution of any high-risk development uncertainties through coding and testing. High-risk development uncertainties include novel, unique, or unproven functions and features or technological innovations. Whether this path is available is based on the facts and circumstances of what the AI component is actually doing.
• Working model. Under ASC 985-20 and the FASB Master Glossary, a working model is “an operative version of the computer software product that is completed in the same software language as the product to be ultimately marketed, performs all the major functions planned for the product, and is ready for initial customer testing (usually identified as beta testing).” A prototype, proof-of-concept, or demo version that does not perform all major planned functions does not satisfy this definition. If the process of developing the computer software product does not meet the detail program design requirements, technological feasibility is established when the design and working model of the software are complete and the completeness of the working model and consistency with the product design have been confirmed by testing.

The combined effect for most AI-enhanced product development programs is that technological feasibility often will be established late in the development cycle, generally leaving a narrow window between technological feasibility and commercial release during which costs would otherwise be capitalizable under ASC 985-20-25-3. Development costs incurred before technological feasibility is established are R&D expenses.

Third-party API costs

Where the entity delivers AI capabilities by calling a third-party foundation model API, those costs generally are costs of revenue (not development costs) recognized in the period in which the related revenue is recognized. Generally, no basis exists to capitalize API costs as software development costs, prepaid assets, or intangible assets.

Key principle: Technological feasibility under ASC 985-20 requires that the product can be produced to meet its design specifications, including all functions, features, and technical performance requirements. For AI components with variable or probabilistic output characteristics, meeting this threshold requires comprehensive evaluation across the intended performance spectrum – not selective demonstration under favorable conditions.

Revenue implications: Performance obligation and principal versus agent

Is the AI functionality a distinct performance obligation?

Under ASC 606, a promised good or service is a distinct performance obligation only if it satisfies both of the following:

• The customer can benefit from the good or service on its own or with readily available resources (“capable of being distinct”).
• The entity’s promise is separately identifiable from other promises in the contract (“distinct within the context of the contract”).

The “separately identifiable” criterion often requires judgment in AI deployment contexts. Under ASC 606-10-25-21, factors indicating a promise is not separately identifiable include, but are not limited to, scenarios where the entity provides a significant service of integrating the AI capability with other goods or services, where the AI significantly modifies or customizes another promised good or service, or where the goods or services are highly interdependent or highly interrelated. AI functionality embedded throughout a SaaS platform – drawing on the platform’s proprietary data model, integrated with its workflow engine, and delivering output actionable only within the platform context – is typically not separately identifiable from the broader platform access obligation. The application of this determination requires judgment based on the facts and circumstances.

A discrete AI add-on module that is independently activatable or producing output the customer uses outside the platform context is more likely to be separately identifiable. The structuring of the commercial offering matters: An entity presenting AI as a bounded module with defined scope is making contractual promises different from promises made by an entity integrating AI throughout the platform.

Principal versus agent: The control assessment

When the entity delivers AI-powered output to customers using a third-party foundation model API, the principal versus agent determination addresses revenue presentation (gross versus net). Under ASC 606-10-55-37, an entity is a principal if it controls the specified good or service before transfer to the customer.

Identifying the specified good or service is the first step. The customer has contracted to receive a defined output (for example, AI-powered analysis, synthesized research, or generated reports). The next step is the control assessment. This refers to the entity’s ability to direct the use of, and obtain substantially all of the remaining benefits from, the asset transferred. This assessment requires judgment based on the facts and circumstances of the arrangement, including the role of any third-party AI provider. The following table includes indicators that an entity controls the specified good or service before it is transferred to the customer:

“Powered by” branding does not determine the outcome. An entity can market a third-party model’s underlying capabilities while also providing significant transformation that supports principal classification. The assessment depends on the substance of the entity’s role. Principal versus agent is not a portfolio-level determination. The same entity may be a principal for some product lines and an agent for others, depending on what the entity actually does between the API call and the customer delivery. Blanket classifications applied without product-level analysis might be a source of revenue misstatement risk.

Implications of ASU 2025-06: The technological feasibility framework under ASC 985-20 and the revenue recognition framework under ASC 606 are not affected by ASU 2025-06. Practitioners will observe, however, that the significant development uncertainty concept in ASC 350-40-25-12A (as amended) closely parallels the “high-risk development issues” construct in ASC 985-20-25-2(a): Both require that novel, unique, or unproven functions be resolved through coding and testing before capitalization begins. The result is R&D expense recognition for most of the development process across both frameworks for AI programs with genuine novelty.

A diagnostic approach to AI accounting

AI accounting does not reduce to a single linear checklist. A given AI program can involve cost elements within the scope of multiple frameworks, and the applicable framework for any given cost element depends on the nature of that element. The right starting point is diagnosis: Pause, understand what you have, and determine which framework applies to which cost.

Three questions are central to the analysis:

• What is the nature of this arrangement and this cost element? Is the arrangement a license or a service? Is the software for internal use or external sale? Is the cost a subscription fee, an implementation cost, a data acquisition, an internal labor cost, or a delivery cost? Each answer points toward a different framework: A cloud subscription fee, an enterprise resource planning (ERP) integration cost, a training dataset purchase, and a GPU bill during fine-tuning can all sit within the same AI program yet be governed by four different frameworks – or different stages of the same one.
• Does this activity meet the definition of research or development under ASC 730? The cost generally is expensed as incurred – regardless of what another framework would otherwise require, regardless of intent, and regardless of the project’s ultimate success. This R&D determination takes priority over every other test and applies to both internal labor and purchased assets, subject only to the alternative future use exception under ASC 730-10-25-2(c), which covers purchased intangibles alone, never internal labor or internally developed assets.
• Has the capitalization threshold been met under the applicable framework? Costs that are not R&D move to ASC 350-40 or ASC 985-20. Under legacy ASC 350-40, capitalization begins only once the preliminary project stage is complete, management has authorized and committed to funding the project, and completion and use are probable. Under ASC 985-20, capitalization begins only once technological feasibility is established. Apply this test cost element by cost element; some costs within a single project might qualify for capitalization while others continue to be expensed.

Generally, these questions are sequentially addressed; however, each question might not be relevant to every cost element. A recurring subscription fee never reaches the second question; it is a period service cost. A training dataset acquisition goes to the second question immediately because the R&D determination is the central issue. Internal fine-tuning labor requires both the second (R&D activity) and third (capitalization threshold) questions to reach a conclusion. Revenue recognition questions under ASC 606 run parallel to the cost analysis and require their own separate assessment.

A recurring risk in accounting for AI spend is applying a single accounting framework to an entire AI program without evaluating which guidance applies to each activity and cost element. Because the analysis often involves judgment, companies should evaluate the relevant guidance at the cost-element level and maintain documentation that supports the basis for their conclusions.

Appendix: What changes in ASU 2025-06 and what does not

ASU 2025-06 does not create new asset categories, does not change which cost types are capitalizable once a threshold is met, and does not affect ASC 985-20 or ASC 606. It changes the timing of when capitalization begins under ASC 350-40 by replacing the three-stage model with a two-condition threshold plus a required significant development uncertainty assessment.

The new capitalization threshold (ASC 350-40-25-12 and 25-12A, as amended)

Capitalization begins when management has authorized and committed to fund the project and it is probable the project will be completed and the software will be used as intended – but only if no significant development uncertainty exists. Significant development uncertainty exists, and the threshold is not met, if either 1) the software has technological innovations or novel, unique, or unproven functions or features whose uncertainty has not been resolved through coding and testing, or 2) the significant performance requirements have not been identified or continue to be substantially revised. “Performance requirements” are defined as “what an entity needs the software to do (for example, functions or features).”

Practical effects by program type

• Novel AI development programs. Many costs may be expensed. The FASB observed (paragraph BC57 of ASU 2025-06) that for novel or unproven software, the window between resolution of development uncertainty and completion of substantial testing might be narrow – producing an expense recognition outcome that might be similar to R&D accounting under ASC 730.
• Programs using established techniques. Where the entity applies documented development techniques to a defined use case with identified, stable performance requirements, significant development uncertainty might not exist. Capitalization may begin at or near project authorization if the other capitalization criteria are met, potentially producing outcomes similar to current GAAP.
• Cloud computing arrangement implementations. The FASB noted (paragraph BC4 of ASU 2025-06) that the revised standard could decrease CCA implementation cost capitalization, particularly for implementations where the AI functionality involves novel or uncertain capability.