Can AI Costs Be Capitalized? A Practical Test

A $300,000 annual AI bill is not automatically an operating expense, and it is not automatically an asset either. When finance asks, “can AI costs be capitalized,” the right answer is usually: some costs may qualify, but only when the underlying work meets established accounting criteria and the company can prove where each dollar went.

That distinction matters because AI programs combine several very different kinds of spend. A single initiative may include model API consumption, cloud infrastructure, implementation labor, software configuration, data preparation, vendor fees, and ongoing monitoring. Putting all of it into one “AI” general ledger account makes both capitalization decisions and future audits harder than they need to be.

Can AI costs be capitalized under U.S. GAAP?

AI does not have its own standalone capitalization rule under U.S. GAAP. Companies generally apply existing guidance for internally developed software, cloud computing arrangements, research and development, and intangible assets. The accounting treatment follows the nature and stage of the work, not the fact that it uses an LLM or an AI agent.

In practical terms, costs are more likely to be capitalizable when they are directly attributable to developing or implementing software for internal use after the project has moved beyond preliminary investigation. Costs are more likely to be expensed when they relate to research, experimentation, training, ongoing consumption, maintenance, or operations.

For an AI initiative, the question is not whether the business expects a benefit. Nearly every technology purchase is expected to help the business. The question is whether the specific cost creates or implements a controlled software asset under the applicable guidance, and whether it was incurred during the appropriate development stage.

A controller should also remember that a capitalization conclusion is not a cash-management decision. Capitalizing eligible costs changes the timing of expense recognition. It does not make spend disappear, and it creates an asset that must be amortized and tested for impairment when circumstances warrant.

Start with the AI cost, not the vendor invoice

Vendor invoices are rarely organized in the way accounting needs. A cloud invoice might contain inference usage, storage, engineering support, hosted application fees, and security tooling. An implementation partner may bill for requirements workshops, software configuration, model evaluation, and production deployment in the same statement of work.

Before applying accounting guidance, break the spend into economically meaningful components. Four categories usually produce a useful starting point:

• Research and evaluation, including proof-of-concepts, model testing, and vendor selection.
• Software development and implementation, including qualifying internal-use software coding and configuration.
• Data work, including data cleaning, labeling, migration, and ongoing data operations.
• Production operations, including API tokens, compute, monitoring, retraining, support, and recurring platform subscriptions.

These categories do not map to a single accounting answer. They create a fact pattern that finance, engineering, and accounting can evaluate consistently.

For example, an engineering team may spend six weeks testing whether an AI agent can resolve employee IT tickets. That work is typically preliminary and should generally be expensed. Once management authorizes a specific project, the team begins building application logic, integrations, workflows, permissions, and testing for a defined internal-use system. Certain directly attributable development costs from that stage may be eligible for capitalization, subject to the company’s accounting policy and the relevant guidance.

The monthly model API bill used to operate the agent after launch is a different matter. It is generally a period cost because it reflects ongoing consumption of a service. Calling the agent “software” does not convert every token, GPU hour, or hosted-model request into an asset.

The project stage often determines the answer

The most common error is treating the entire AI project as one phase. It is better to establish stage gates with dates, approval evidence, and a defined technical scope.

Preliminary project stage

This stage includes identifying business problems, comparing vendors, evaluating models, running pilots, and determining feasibility. Costs in this stage are generally expensed as incurred. For AI, this can include sandbox API usage, prototype prompts, short-term contractor evaluations, and exploratory data analysis.

This is often the largest source of confusion because an AI proof-of-concept can look sophisticated. A functional demo is not, by itself, evidence that the project has moved into an implementation stage.

Application development stage

After the company commits to a project and begins developing or configuring the selected solution, certain direct costs may qualify for capitalization. Examples can include payroll and external development costs for people directly building the internal-use application, integrating enterprise systems, configuring workflow logic, and performing necessary testing before the system is ready for use.

Eligibility is not automatic. General and administrative work, training, process redesign, data conversion, and project management may need separate treatment depending on the facts. Companies should avoid broad timesheet allocations that label an entire engineering organization as “AI development.” The labor record should identify the person, project, activity, period, and development stage.

Post-implementation and operating stage

Once the system is ready for intended use, most ongoing costs are expensed. This commonly includes model inference, recurring platform fees, monitoring, incident response, user support, routine maintenance, and incremental tuning that does not create new functionality.

A later enhancement may create a new capitalization question if it adds significant functionality. Small adjustments to prompts, retrieval settings, model routing, or agent instructions will often be operational work. A material upgrade to the software architecture may be different. The facts, materiality, and policy should drive the conclusion.

AI data and model costs require particular care

Data is often the least cleanly classified part of AI spend. Teams may acquire data, prepare internal documents for retrieval, label examples, create embeddings, or pay for ongoing data enrichment. These activities can support an AI application, but support alone does not establish capitalization.

Data conversion and cleansing work is often expensed, particularly when it is needed to make existing information usable. Costs to acquire a separately identifiable intangible right may require a different analysis. Similarly, expenses incurred to train or fine-tune a model require careful review under the company’s R&D and software accounting policies. The terminology used by the technical team is not enough to determine treatment.

The same caution applies to third-party AI platforms. If the company is paying for access to a hosted service, it may be accounting for a service arrangement, implementation costs associated with a hosting arrangement, or a combination of both. Contract terms matter: who controls the software, what rights the customer receives, whether there is a license, and whether the implementation creates a separate asset.

Build an evidence trail before the close

A defensible capitalization policy needs operating evidence, not a year-end spreadsheet assembled from memory. Finance needs a repeatable record of when the project moved from exploration to implementation, which activities occurred after that point, and how directly attributable costs were measured.

A practical monthly review should connect four records: approved project documentation, engineering work records, vendor and cloud usage data, and accounting entries. The accounting team can then evaluate costs by project and stage rather than trying to infer intent from a single corporate AI invoice.

Consider a company building an internal claims-triage agent. During the evaluation period, it incurs $40,000 for experiments and model testing. After approval, it incurs $120,000 of directly attributable development labor and $30,000 of implementation consulting that meets its capitalization criteria. After launch, it spends $18,000 per month on model usage and monitoring.

Subject to the company’s policy and conclusion, the evaluation costs and monthly operating costs would generally be expensed. Qualifying development and implementation costs may be recorded as an internal-use software asset and amortized over the estimated useful life. The entries should be supported by time records, statements of work, stage approvals, and an amortization schedule, not just management intent.

Cost attribution is the control that makes policy usable

Even a sound accounting policy fails when AI spending cannot be attributed. If finance sees one invoice while IT sees distributed usage across teams, agents, projects, and vendors, no one can separate a capital project from ordinary production consumption with confidence.

This is where AI FinOps becomes an accounting control as well as a cost-management practice. Tag or otherwise map usage to a cost center, project, application, agent, environment, and owner. Keep capital-project consumption distinct from pilot and production consumption. Reconcile those usage records to vendor invoices before preparing allocations or journal entries.

For shared infrastructure, use an allocation method that reflects consumption where possible. Token volume, compute hours, request counts, storage, or named project environments can be reasonable drivers depending on the service. A flat allocation may be acceptable when amounts are immaterial, but it is difficult to defend for a large, variable AI workload.

The goal is not to capitalize more AI spend. It is to record each cost according to what it actually represents, with enough evidence for finance, auditors, and operating leaders to reach the same conclusion. When AI costs are visible by owner and purpose, capitalization becomes a controlled accounting judgment rather than a debate over one oversized invoice.