Artificial intelligence has moved from innovation labs into core business operations. Organizations are developing AI-powered employee assistants, automating finance workflows, embedding AI into customer-facing products, and building entirely new revenue streams around AI-enabled solutions. As investment accelerates, finance leaders are increasingly asking a simple but important question: 

How should we account for the costs of developing AI? 

The answer is less about the artificial intelligence itself and more about how the software will be used. Despite the rapid evolution of technology, AI development and implementation generally fall within existing accounting frameworks. The challenge for CFOs and controllers is determining which framework applies, identifying when capitalization begins, understanding the implications of licensing models, and helping to ensure appropriate subsequent measurement and disclosure.  

Organizations that answer these questions early can avoid accounting surprises, support defensible capitalization positions, and provide greater transparency into the return on their AI investments.  

With AI, the tool matters. The intent matters more

Many organizations begin by focusing on the technology itself. Is it generative AI? Agentic AI? A large language model? A custom machine learning solution? 

From an accounting perspective, those distinctions are often secondary. 

The more important questions are: 

1. 1. Who is the intended audience?
   2. What is the intended use case?
   3. What does the development and implementation workflow encompass?  

The answers generally help determine whether the development costs are accounted for under: 

• • ASC 350 for software developed or obtained solely to meet an entity's internal needs, including certain software used to provide hosted services to customers, or 

• • ASC 985 for software that will be sold, leased, or otherwise marketed externally  

Other costs associated with an AI initiative, such as certain data, infrastructure, or research and development costs, may require consideration of other accounting guidance. 

Making this determination as early as possible is critical because capitalization thresholds under the two standards differ significantly and can materially affect reported earnings and asset balances. For hosted or software-as-a-service arrangements, additional analysis may be necessary to determine whether the arrangement includes a software license, and which software-cost guidance applies.  

A three-step framework for evaluating AI projects

Step 1: Who will use the software? 

An important initial consideration is whether the solution will support the organization's own operations, be used to provide a hosted service to customers, or be provided to customers through a software license or other arrangement. 

Understanding the intended users helps frame the analysis, but external customer use does not, by itself, determine whether ASC 985-20 applies. 

Examples of internal-use AI initiatives include: 

• • Employee help desk assistants 

• • Finance and accounting automation tools 

• • Internal knowledge management agents 

• • Human resources support applications 

• • AI-powered workflow automation solutions 

These projects will generally fall under ASC 350.  

However, external users do not automatically mean ASC 985 applies. 

That brings us to the second question. 

Step 2: What is the use case? 

The determining factor is not simply whether customers use or benefit from the AI solution. The analysis focuses on whether the software is developed solely for the entity's internal needs, including providing a hosted service, or whether it will be sold, leased, or otherwise marketed externally. 

Consider two examples: 

Example 1: A company develops an AI-powered customer service tool used internally by its own service representatives. Customers may benefit indirectly from the tool, but they do not access the software.  Because the software is being developed to meet the company's internal needs, the project would generally fall within ASC 350-40.  

Example 2: A company develops a fraud detection AI platform that it intends to license to banks for deployment by those customers. If the arrangement provides the bank, as the customer, with a software license rather than access solely through a hosted service, the related development costs would generally be accounted for under ASC 985-20. 

This distinction is foundational because it determines when costs begin transitioning from expense to capitalization. 

Step 3: What does the workflow encompass? 

The final step is documenting the development process itself. 

Organizations should clearly define: 

• • Intended functionality 

• • Inputs and outputs 

• • Technical requirements 

• • Testing procedures 

• • Acceptable performance thresholds 

• • Governance requirements 

• • User acceptance criteria  

For AI projects, this step is often more important than the coding itself. 

Modern AI tools can reduce the time required for certain coding activities, while increasing the effort devoted to testing, validation, governance, and performance monitoring. The accounting for those costs depends on the applicable software guidance, when the relevant capitalization threshold is met, and the nature of the activities performed. Organizations should therefore understand and document these activities throughout the development process rather than assume that all testing or validation costs qualify for capitalization.   

ASC 350 and internal-use AI 

Most current AI initiatives generally fall within ASC 350 because they are intended to improve internal operations rather than create standalone software products.  

Examples include: 

• • AI accounting assistants 

• • Employee support agents 

• • Procurement automation 

• • Internal research tools 

• • Knowledge management systems 

• • AI-enhanced intranet platforms  

As of today, organizations evaluate these projects using three project stages: 

1. 1. Preliminary project stage
   2. Application development stage
   3. Post-implementation-operation stage  

The preliminary project stage generally includes: 

• • Strategic decisions 

• • Performance requirements 

• • Ensuring the technology exists 

• • Vendor selection (if being performed by a third party) 

Under current guidance, capitalization generally begins during the application development stage after the preliminary project stage is complete. Management, with the relevant authority, authorizes and commits to funding the project when it is probable that the project will be completed and the software will be used to perform its intended function. Qualifying application development costs are capitalized, while costs such as training and most data conversion activities continue to be expensed. 

Finally, during the post-implementation operation stage, training, maintenance, and operating support costs generally are expensed. Costs of upgrades and enhancements may be capitalized when it is probable that the expenditures will provide additional functionality. 

However, ASU 2025-06 significantly changes that approach. The guidance is effective for annual reporting periods beginning after December 15, 2027, including interim periods within those annual periods. Early adoption is permitted as of the beginning of an annual reporting period. 

How ASU 2025-06 changes the analysis 

ASU 2025-06 eliminates the project-stage framework and replaces it with a principles-based capitalization threshold. Under the new guidance, capitalization of eligible costs begins when both of the following conditions are met: 

Has management authorized and committed to funding the project? 

Evidence supporting this conclusion will depend on the organization's governance and approval process and may include: 

• • Approved funding 

• • Executed development contracts 

• • Other formal authorization of expenditures 

• • Formal project approval documentation  

Is it probable that the project will be completed and the software will be used to perform its intended function? 

In assessing whether completion is probable, management must consider whether significant development uncertainty exists. That uncertainty exists when:  

• • The software involves technological innovations or novel, unique, or unproven functions or features, and the related uncertainty has not been resolved through coding and testing, or  

• • The software's significant performance requirements have not been identified or continue to be substantially revised 

• • If significant development uncertainty exists, the probable-to-complete threshold has not been met and capitalization does not begin until that uncertainty is resolved. 

This assessment is particularly important in the AI environment. 

For AI projects using established technologies with clearly defined performance requirements, determining when the capitalization threshold is met may be relatively straightforward. Projects involving novel or unproven functionality may require additional development and testing before significant development uncertainty is resolved. Accordingly, the effect of ASU 2025-06 on the timing of capitalization will depend on the facts and circumstances of each project.   

Defining the project matters  

Under ASU 2025-06, determining the software project to which the capitalization criteria are applied may require judgment, particularly for agile or iterative development. AI development is often iterative, with new features, agents, models, or capabilities developed and released independently. Organizations should therefore establish what constitutes the software project for purposes of applying the capitalization criteria. This determination may require judgment when individual modules or features have independent functionality or are developed and deployed separately. 

What costs may be capitalized? 

Once capitalization has begun under the applicable guidance, the types of costs eligible for capitalization generally do not change as a result of ASU 2025-06. Depending on the nature and timing of the activities performed, qualifying costs may include: 

Depending on the nature and timing of the activities performed, capitalizable costs may include:  

• • External costs of materials and services used to develop or obtain the software  

• • Payroll and payroll-related costs for employees who are directly associated with and devote time to qualifying software development activities  

• • Qualifying coding, configuration, integration, and testing activities  

• • Interest costs when the applicable capitalization requirements are met 

A person's title or involvement in an AI project does not, by itself, determine whether the related cost is capitalizable. Organizations should evaluate the underlying activities performed and when those activities occur.   

AI projects frequently involve extensive testing and validation. Those activities should be evaluated carefully because some may occur before the capitalization threshold is met, while other qualifying activities may be capitalized after that threshold is satisfied. 

AI development may also involve usage-based costs, such as token or API consumption charges. These costs should be evaluated based on their purpose and relationship to the development activity. Costs that are directly attributable to a specific qualifying software project may be eligible for capitalization when incurred during the applicable capitalization period, while costs associated with research, maintenance, general experimentation, or ongoing operations generally would be expensed. 

AI projects may also require significant expenditures to acquire, prepare, label, or otherwise develop the data used to train or operate a model. These costs do not automatically follow the accounting for the related software. Depending on the nature and purpose of the data and how it was obtained, organizations may need to consider other applicable guidance, including the accounting for research and development or acquired intangible assets. 

Certain costs continue to be expensed, including: 

• • Training activities 

• • Data conversion efforts 

• • General administration 

• • Post-implementation operating support  

ASC 985 and AI solutions developed for sale 

Organizations creating software products for commercial sale face a different accounting model. 

Under ASC 985, costs incurred before technological feasibility are generally treated as research and development expenses. Capitalization begins only after technological feasibility has been established.  

 As a result, the timing of capitalization under ASC 985-20 may differ significantly from the timing under ASC 350-40. 

Unlike the "probable-to-complete" threshold, technological feasibility generally requires demonstrating that the solution can achieve its functional and technical requirements. In practice, substantial design, development, and testing may occur before this point is reached.  

An AI product example 

Consider a company developing a fraud detection AI platform for financial institutions. 

The early phases might include: 

• • Designing algorithms 

• • Developing detection logic 

• • Building and training models 

• • Initial testing 

These activities would typically fall within research and development.  

Capitalization begins once technological feasibility has been established in accordance with ASC 985-20. Depending on the development process, that determination may involve completion of a detailed program design or a working model and resolution of high-risk development issues. For AI products involving novel or unproven functionality, significant development and testing may therefore occur before technological feasibility is established. 

After technological feasibility is established, qualifying costs incurred to complete the software product are capitalized until the product is available for general release to customers. The accounting should be based on the nature of the activities performed and whether they relate to completing the product for which technological feasibility was established. 

Licensing: The overlooked AI accounting issue 

One of the most important considerations in AI accounting is licensing. 

Many AI solutions rely on: 

• • Third-party large language models 

• • Cloud-based AI services 

• • API-driven architectures 

• • Usage-based pricing arrangements  

As organizations move toward commercialization, several questions become increasingly important: 

• • What intellectual property does the company actually own? 

• • Can customers operate the software independently? 

• • Is continued access to a third-party LLM required? 

• • Does the arrangement resemble software ownership or SaaS delivery?  

These issues can affect the applicable software-cost model as well as valuation, impairment, commercialization strategy, and financial reporting. For hosted AI offerings, the underlying development costs may be subject to ASC 350-40, including when the software is used to provide a SaaS offering to customers. When evaluating the applicable software-cost model, organizations should consider whether the customer receives a software license or instead receives access only to the hosted functionality. Determining whether a hosted arrangement includes a software license requires consideration of the customer's contractual rights, including whether the customer can take possession of the software without significant penalty and whether it is feasible for the customer to run the software independently or through an unrelated hosting provider. 

Example 

A company may develop a highly sophisticated AI application but rely entirely on a third-party large language model accessed through APIs. 

Although the company owns the workflow and application layer, critical functionality remains dependent on external providers. Management should understand how those dependencies affect intellectual property rights, commercialization economics, and long-term sustainability.  

Subsequent measurement is becoming more complex 

Capitalization decisions are only the beginning.

Once costs have been capitalized, organizations must determine: 

• • Useful life 

• • Amortization method 

• • Enhancement accounting 

• • Impairment considerations  

Determining useful life 

AI technology evolves at a pace rarely seen with traditional enterprise software. 

A useful life assessment should consider: 

• • Competitive developments 

• • Planned product redesigns 

• • Expected enhancement cycles 

• • Business strategy 

• • Technological obsolescence  

The rapid evolution of AI technologies may affect the estimated useful life of certain software assets. Useful-life estimates should reflect the facts and circumstances of the specific asset, including expected technological obsolescence, planned enhancements or replacement cycles, competitive developments, and the period over which the software is expected to provide economic benefit.    

Enhancements versus maintenance 

Not every update should be treated the same. 

Organizations should distinguish between: 

Maintenance 

• • Bug fixes 

• • Prompt modifications that maintain existing functionality 

• • Minor model tuning that does not add functionality 

• • Routine updates that maintain existing functionality 

Enhancements 

• • Significant new functionality 

• • Platform redesigns 

• • Major capability expansions 

• • New commercial modules  

This distinction becomes increasingly important as AI solutions undergo continuous evolution. 

Impairment considerations 

The pace of AI innovation also increases the importance of impairment monitoring. 

Potential indicators may include: 

• • Project abandonment 

• • Earlier-than-expected replacement 

• • Competitive disruption 

• • Reduced customer demand 

• • Significant strategic changes  

However, the existence of newer technology by itself does not necessarily trigger impairment. 

The emergence of newer technology does not, by itself, establish that an impairment has occurred. Organizations should instead evaluate whether relevant events or changes in circumstances indicate that the carrying amount of the software may not be recoverable or that its remaining useful life should be reassessed. 

What about disclosure? 

Currently, there is no specific requirement to separately disclose AI software assets simply because they involve artificial intelligence.  

Nonetheless, CFOs should consider whether AI investments are sufficiently material to warrant additional discussion. 

Potential disclosure considerations may include: 

• • Significant internally developed software assets 

• • Dependence on third-party AI platforms 

• • Concentration risks 

• • Material licensing arrangements 

• • Significant AI-related capital expenditures  

ASU 2025-06 also clarifies the disclosure framework for capitalized internal-use software. Upon adoption of ASU 2025-06, capitalized internal-use software costs are subject to the applicable disclosure requirements in ASC 360-10 regardless of where those costs are presented in the financial statements.  

Public companies should also evaluate risk factor implications when operations become dependent on external AI providers or cloud-hosted technologies.  

The CFO playbook for AI accounting 

The accounting for AI is not fundamentally different from the accounting for other software investments. What has changed is the speed of development, the complexity of licensing arrangements, and the importance of governance around testing and validation.  

For finance leaders, a practical framework is: 

1. 1. Determine the applicable accounting model based on how the software will be used and delivered.
   2. Define the software project and significant performance requirements.
   3. Document management's authorization and commitment to funding the project.
   4. Evaluate whether significant development uncertainty exists.
   5. Establish governance around coding, testing and validation, and project costs.
   6. Evaluate licensing, third-party technology dependencies, and intellectual property considerations early.
   7. Establish processes to identify eligible capitalizable costs.
   8. Develop appropriate amortization and impairment policies.
   9. Assess disclosure implications based on materiality and risk.  

The organizations that will derive the greatest value from AI are not necessarily those that deploy it fastest. They are the ones that combine innovation with disciplined governance, sound accounting, and a clear understanding of how AI investments create long-term enterprise value.