Can you capitalize AI coding tool costs?

If you read my last post on software capitalization, you might remember the Slack message from the CFO about Very Important Tax Credit Scheme 123. You sorted that one out (or you’re still sorting it out, no judgment). Now there’s a sequel, and it goes something like this:

Hey, our AI tooling bill has gone up a fair bit this year. Most of it is engineers building product, right? Can we capitalize it?

And it makes sense — your company used to spend most of its R&D budget on engineers’ salaries, and a chunk of those salaries got capitalized because the engineers were building software that would be around for years. Now a growing share of that same budget goes to Claude Code, Cursor, Copilot, Codex, or whatever API bill your in-house agents are running up, and the software being built is (hopefully) as long-lived as before. So why shouldn’t some of that spend end up on the balance sheet too?

Some of it can be capitalized, under US GAAP at least, but it’s probably less than your CFO is hoping for. You need reliable evidence of which costs supported qualifying development activities and which software projects benefited. Direct token-level tracking is the strongest starting point, although a systematic and rational allocation can sometimes work when direct identification isn’t practicable.

A quick refresher on CapEx and OpEx

If you expense a cost (OpEx), it hits your income statement in full in the period you spend it. If you capitalize it (CapEx), it goes on the balance sheet as an asset and gets amortized over the software’s useful life. The amortization is excluded from EBITDA, which is a big part of why finance teams like capitalizing things.

Under US GAAP, the standard most companies will be looking at here is ASC 350-40 for internal-use software. Despite the name, it also covers software you sell only as SaaS, which is most of us. It lets you capitalize payroll for people working directly on a qualifying project, plus “external direct costs of materials and services consumed in developing or obtaining internal-use computer software.” That second part is where AI tools come in.

The rules haven’t changed just because it’s AI

In 2026, two Big Four firms published detailed guidance on AI development costs:

Deloitte’s starting point is that nothing fundamental has changed:

The internal-use software accounting framework does not change merely because the development resource is an AI-enabled service rather than a person.

An AI tool is an external service, and it gets tested the same way as any other external service you’d pay for during development. To capitalize a cost, it has to:

Be an external cost of materials or services consumed in developing the software
Be directly attributable to a specific qualifying software project
Relate to a qualifying development activity
Be incurred while that project is eligible for capitalization

What does change, according to Deloitte, is “the nature, pricing, and evidence of activities incurring the costs.”

Pricing doesn’t decide it, the activity does

You might assume that per-token API charges are the capitalizable kind (they’re measurable, after all) and that flat per-seat subscriptions aren’t. Both firms say that’s not how it works.

As Deloitte puts it:

A token-based charge is not capitalizable merely because it is measurable, and a fixed or subscription-based charge is not necessarily non-capitalizable merely because it is not billed by usage.

The same goes for what the tool is called. A vendor calling a product an AI coding assistant or coding agent doesn’t govern the accounting, because the same product can be used for work that qualifies and work that doesn’t. Nor does it help that the person using it is an engineer: you can’t assume a cost supports capitalization simply because it was incurred by a member of a development team.

What counts is the work that the AI did.

According to Deloitte, AI services used to generate or modify code for approved functionality, develop interfaces, configure software, perform development testing, or correct defects before the software is ready for its intended use may be capitalizable.

AI used for preliminary evaluation, general experimentation, employee training, routine maintenance, production support, or general research and productivity isn’t. EY adds search queries to the non-capitalizable pile, which I suspect covers a fair amount of what engineers use these tools for.

Note the bit about defects: fixing bugs in the new thing you’re building, before it’s ready, is development. Fixing bugs in software that’s already in use is generally maintenance and gets expensed, unless the work is part of a qualifying upgrade or enhancement.

Seats, tokens, and everything in between

Here’s how common AI tooling arrangements sort out, based on examples from both firms.

Company-wide and general-purpose engineering subscriptions are generally expensed. EY describes an LLM platform with a fixed monthly fee that everyone in the company can use, from finance and HR to engineering. Deloitte reaches a similar conclusion for enterprise-wide subscriptions.

The same problem applies when every engineer has a Cursor or Claude Code seat and uses it for new features, maintenance, debugging, explaining legacy code, and summarizing meetings. Deloitte says this may be more like a shared technology or overhead expense than a direct development cost. Allocating the subscription fee across projects based on which engineers hold seats doesn’t make it directly attributable to those projects.

A subscription bought for one project can be capitalized. Deloitte’s Example 3 is a six-month subscription to an AI coding agent bought solely for Project A, with access limited to that team and used only for qualifying development during the capitalization period. That fee can be capitalized, fixed price and all. It’s a pretty rare setup for most engineering orgs, though.

Token usage you can trace to a project can be capitalized. EY describes an LLM platform priced per token, used to code a specific new application, with controls to show the fees weren’t for maintenance, bug fixes to existing software, or administrative work. Deloitte gives a similar example, with consumption tracked by project ID, employee, and development environment. In both cases, the identifiable costs of qualifying development can be capitalized.

Mixed arrangements get evaluated component by component. Some contracts combine a fixed fee with usage-based charges. Deloitte’s Example 4 involves a company that capitalizes token charges traceable to a qualifying project but expenses the fixed monthly charge for shared compute capacity, because that charge is payable regardless of what any particular project consumes.

So a subscription isn’t necessarily OpEx, and token usage isn’t necessarily CapEx. It comes down to whether you’re paying for services directly consumed by a qualifying project, and whether you can demonstrate that connection.

Like always, attribution is the hard part

The obvious shortcut is to take the total AI bill and split it the same way you’d split engineering salaries.

However, both firms warn against this. EY specifically rejects broad corporate and headcount-based allocations, such as capitalizing 40% of AI spending because 40% of IT staff are developers.

Deloitte makes a similar point about broadly available tools: allocating their cost to projects based on developer headcount, labor hours, or broad project budgets doesn’t, by itself, establish that the costs represent services directly consumed by those projects. Spreading the cost of access around isn’t the same as showing what was consumed where.

What both firms prefer is specific identification.

EY’s examples are project-level token tracking tied to specific development activities and usage logs that connect AI consumption to software projects. Deloitte is clear that using operating data like this is fine. If the vendor invoice shows identifiable API usage by project and activity, you’re measuring direct service consumption, not turning an indirect cost into a direct cost through general allocation.

But EY also allows a systematic and rational allocation methodology when specific identification isn’t practicable, as long as it “faithfully reflects the underlying use of the AI resources.”

The example EY gives is a two-step approach. First, identify which token costs relate to capitalizable activities like coding and testing. Then allocate those costs across projects based on the hours developers spent on each.

That can work if there’s a clear relationship between labor effort and token consumption, the data is reliable, and appropriate controls are in place. EY’s rule of thumb is that “the further the allocation methodology gets from actual usage for a specific software project, the less likely it will be an appropriate method.”

So EY and Deloitte aren’t as far apart here as it might first look. Deloitte’s warning about hours-based allocation is about broadly available tools, like fixed subscriptions. EY’s hours-based example only applies to costs already identified as direct AI development costs. Even then, the allocation has to reflect actual consumption reasonably well.

Whether a given auditor would accept the EY approach is something to ask them directly.

And if you can’t track or allocate the costs reliably, you expense them. EY puts it plainly:

We do not believe entities should capitalize costs if they do not have appropriate processes and controls to reliably determine the amount of costs that should be capitalized.

Agent sessions make it trickier

A single agent session can include all sorts of work. Deloitte’s example is an agent that inspects a repository, plans the work, generates code, runs tests, and prepares a pull request, while in the same session also researching alternatives or looking into a production issue.

You can’t capitalize the entire session just because part of it involved development.

In Deloitte’s Example 5, a company can split the session because the vendor’s logs record tokens time-stamped by prompt and task, and the company can tie those to the repository and development ticket referenced in the session. The tokens for coding and testing Project A are capitalized, while those spent on the production incident and unrelated documentation are expensed.

Without reliable evidence to separate the activities, the company couldn’t support capitalizing the combined session cost.

That evidence usually requires more than a vendor’s usage report. You need to connect AI consumption with project management records, development tickets, and other project accounting data. Vendor logs may not identify the project or activity at all, and a single request might go through several models or providers.

Deloitte also warns that the processes companies already use to track human development effort might not be sufficient for AI-related costs. You may need to change how projects and agent sessions are set up to make that connection possible.

Prepaid credits and minimum commitments

Enterprise deals where you pay upfront for AI credits add another complication.

Deloitte distinguishes between credits purchased for actual consumption and fixed commitments that effectively pay for access.

If you prepay for credits you expect to use, the payment is initially a prepaid asset. As credits are consumed, the portion used for qualifying development may be capitalized, while consumption for maintenance or general research is expensed.

But if you’ve committed to $1 million for far more tokens than you expect to use, dividing that fee by actual consumption doesn’t necessarily make it a direct development cost. The payment may effectively be a fixed fee for access rather than a charge for identifiable services consumed by a project.

That doesn’t rule out every minimum-commitment arrangement. Deloitte also notes that a fixed commitment obtained exclusively for qualifying development on a specific project may be directly attributable to that project.

The contract terms and expected usage matter, not just whether the invoice includes a token count.

What about developer salaries?

AI doesn’t change the rules for capitalizing developer labor. Payroll is capitalizable to the extent people spend time directly on qualifying project work, same as it ever was.

What changes is what that time looks like: more writing specs, reviewing, iterating on prompts, and verifying output, and less typing code by hand.

And about review, actually: is reviewing AI-generated code capitalizable too?

Neither firm directly addresses the specific question of human employees reviewing AI-authored pull requests. Deloitte does include code review among activities an AI development service may perform, and the existing labor rules cover qualifying coding and testing work.

My read (as an engineer, mind, not an accountant) is that human review and testing of AI-generated code for an approved feature during the capitalization window should qualify, while supervising an agent through production triage or preliminary research shouldn’t. Simply reviewing a PR doesn’t automatically make the time capitalizable; the underlying work still has to qualify.

That’s how we’ve approached it in Swarmia too: bots aren’t counted as human contributors, but the human reviews of bot-authored pull requests are counted as engineering effort, because that’s what they are.

And as AI changes how engineers spend their time, the amount of capitalizable labor may change too, even if the amount of software shipped increases. AI service costs and human labor remain separate costs, each with their own evidence requirements.

If you want more detail on how to capture that human effort without timesheets, we’ve covered how software capitalization works with developer activity data separately.

ASU 2025-06 changes when, not what

If your finance team has mentioned ASU 2025-06, they’re talking about the FASB update that replaces the three-stage model in ASC 350-40.

It’s effective for annual periods beginning after December 15, 2027 (so calendar 2028 for most companies), with early adoption allowed if it makes sense for your organization.

Under the new model, capitalization starts when management has authorized and committed to funding a project and it’s probable the project will be completed and the software will perform as intended.

For agile teams, that may be simpler than mapping sprints to stages. But for teams building novel AI capabilities, significant development uncertainty can delay capitalization until the uncertainty has been resolved.

The important thing for AI tooling costs is that the update changes when capitalization starts, not which types of costs qualify. Ask your finance team which version of the guidance your company is applying.

If you report under IFRS

Under IFRS, the framework is different. As the IFRS Interpretations Committee’s cloud computing guidance explains, SaaS arrangements are generally treated as service contracts when the customer doesn’t control the underlying software, so AI seats and API access don’t typically create standalone software assets.

But that doesn’t mean every AI service used in development has to be expensed. The cost can still be capitalized as a directly attributable cost of developing your own intangible asset, provided the project is in the development phase and meets the six IAS 38 recognition criteria.

The distinction is between capitalizing access to someone else’s AI service and capitalizing qualifying costs incurred to create a software asset you control.

And remember that book capitalization and tax treatment are separate questions, with their own eligibility requirements.

How Swarmia helps

We’ve already helped companies take the manual work out of software capitalization. Now we’re bringing AI costs into the same workflow.

With Swarmia’s software capitalization feature, you can track engineering effort using commits, pull requests, code reviews, and issue tracker data. You define which work qualifies for capitalization, and Swarmia calculates how engineering effort is distributed across projects, producing audit-ready reports without asking engineers to fill out timesheets.

We’re extending that approach to AI development costs, too.

Swarmia already connects AI usage to engineering work. You can see token consumption attributed to individual pull requests, while the broader AI cost view distributes each person’s daily AI usage across the issues and pull requests they contributed to, in proportion to their effort. And with AI tokens in investment balance, you can see how much usage is associated with building new things versus maintaining existing software.

By bringing AI costs into the software capitalization workflow, we’re making it possible to look at human engineering effort and AI consumption together, using the underlying development work to help identify potentially capitalizable costs.

There are still some accounting considerations. Swarmia’s AI cost figures use the list-price value of consumed tokens, which may differ from what your company actually paid. You’ll need to reconcile those figures with your invoices, particularly if you have enterprise discounts, prepaid credits, or subscription allowances.

And as Deloitte and EY make clear, connecting token usage to a project doesn’t automatically make the cost capitalizable. The underlying activity still needs to qualify, and any allocation methodology needs to meet the relevant accounting requirements.

But that’s exactly why connecting AI usage to the underlying engineering work is important. Rather than starting with a company-wide AI bill and trying to divide it up after the fact, you have project and activity data to work from, alongside the human effort you’re already tracking for capitalization.

So, can you capitalize AI coding tool costs?

The answer to your CFO is yes, some of them. But not just because engineers are using AI tools to build software, and not just because you can count the tokens. You need to show what the AI was used for, which project benefited, and how much the qualifying work actually cost.

If you’re looking to start capitalizing AI spending, here’s where I’d begin:

Start with the costs you can actually attribute. Broadly available AI subscriptions will generally be operating expenses. Usage-based charges tied to specific development projects are a more promising starting point.
Agree on the rules with finance and your auditors. Find out what evidence they’ll accept, whether a systematic allocation method is appropriate, and when your projects qualify for capitalization.
Connect AI usage to the work. Agent sessions linked to development tickets and PR-level token tracking can help establish which costs relate to qualifying development rather than maintenance, research, or other activities.
Make sure the numbers add up. Token usage isn’t necessarily the same as what you paid. Reconcile it with your invoices, and keep AI service costs separate from capitalizable human labor.

The accounting rules haven’t changed (yet), but what has is how software gets built, and how much of the development budget now goes to AI tools alongside engineers’ salaries. So get all this in place now, and you’ll have a much better answer ready the next time your CFO appears in your DMs with questions.