The Token Bill Is an Accounting Problem as Much as a Cost Problem

Finance teams need to account for a growing AI bill with records that rarely explain what the spending supported. Closing that gap gives them a stronger basis for capitalization and R&D credit decisions. 

Tokens: the Line Item that Came From Nowhere 

Eighteen months ago, an engineering organization's spend on AI tokens was a rounding error on a cloud bill. For many companies, it has since crossed into material territory, with finance teams trying to keep pace. 

Token spend arrived without the apparatus around labor. Headcount comes with a cost center, an approval chain and a department, and finance can tie an engineer's time, however roughly, to a project or business component. In contrast, tokens are consumed across sessions that may include development, testing and production support, and the nature of the work doesn't appear on the invoice. 

We're seeing that gap change who joins the conversation. Discussions about AI tooling that once happened with VPs of Engineering now include CFOs, controllers, tax and FP&A leads who want to understand where this new spending is going. 

Faced with a number they can't decompose, finance teams are doing the reasonable, defensible thing and expensing the whole bill in the period incurred. As that bill grows, so does the value of knowing which costs merit a closer look. 

Expensing Everything is the Simple Option, but Often a Costly One 

A single operating expense line gives the controller little basis for identifying capitalizable development costs and the tax team little evidence for a credit claim. Both need to know which projects and activities consumed the spend. 

The financial consequences are familiar: capitalization under ASC 350-40 affects when qualifying internal-use software costs reach the income statement; section 41 may provide a credit for eligible research expenses. Under section 174A, companies can deduct domestic R&E costs for tax years beginning after December 31, 2024, while foreign R&E remains subject to fifteen-year amortization under section 174.

Domestic R&E expensing under section 174A remains favorable. The avoidable cost comes from missing evidence: finance may be unable to support a treatment the underlying work would otherwise justify. 

The contract also deserves attention. Token pricing alone doesn't determine book treatment, while the tax analysis needs to consider the service purchased and the applicable expense category. Metered compute, flat-fee assistants and prepaid commitments raise different classification and timing questions for the reviewer. 

Teams evaluating AI spend are applying existing rules to new arrangements. Attribution gives their accountants and tax advisors the facts to assess those arrangements, without presuming the outcome. 

Unfortunately, the Easy Alternative Does Not Stand Up to Scrutiny 

The next move looks straightforward: divide the AI bill by headcount or labor hours, then assign the result to finance's existing projects. This reconciles the number, but a reviewer still needs evidence that those projects consumed the services. 

In its August 2026 analysis, Deloitte explains that allocating a broadly available AI tool by headcount or labor hours does not, by itself, establish a direct project cost. Usage records can support capitalization when they identify services consumed by qualifying projects and activities. 

A dashboard showing $40,000 of inference spend by one team last quarter illustrates the gap. Finance can use that total to manage a budget, but still needs to separate development work from maintenance and production support before assessing treatment. 

The tax team has another question to resolve: how much technical uncertainty remained in the work? AI may handle a coding task while engineers continue to test alternative designs or investigate reliability problems. A record of the uncertainty, the alternatives evaluated and the results gives the reviewer something to assess against the research credit's experimentation requirements. The use of AI alone doesn't answer the eligibility question. 

Robust Attribution is Possible, but not from a Spend Report 

Finance and engineering can assess their current reporting against four questions: 

1. Does spend resolve all the way to a project or business component? A team or cost center identifies the budget owner. Finance also needs to identify the project the work supported and map it to the relevant accounting or tax review. 

2. Does spend resolve to an activity? The record needs enough detail to distinguish development and testing from maintenance or support. Reviewers can then apply the relevant rules to each portion. 

3. Is the method a measurement or a convention? An equal split across projects may balance the spreadsheet without showing how the team consumed the services. A reviewer should be able to understand the allocation method and inspect the records supporting it. 

4. Can a reviewer trace the reported amount back to its source? Finance needs to follow a summary figure through the calculation to the underlying work and cost records, with enough detail to explain how the amount arose. 

Engineering tracks work through repositories, pull requests, epics and sprints. Finance uses capital projects and cost centers. Agreeing how those records connect saves both teams from rebuilding the mapping each time someone requests a report. 

If these questions expose gaps in your reporting, talk with Span about token attribution. Bring your finance and engineering reporting requirements to the conversation so we can discuss where Span fits. 

Four Things Worth Doing Before the Year Closes 

Start collecting attribution data now

Capture the project and activity context while engineers are doing the work. Once tools delete session details, reconstructing what happened can become difficult or impossible. The IRS requires records sufficient to substantiate the expenses claimed; keeping those records as work happens reduces the burden of preparing evidence later. 

Set a retention period with your reviewers

Check how long your tools retain the records, name an owner and document the policy. Unused research credits can carry forward for twenty years, so align retention with the periods your tax team may need to substantiate. A tool's default retention setting may be too short for that purpose. 

Know the shape of the bill and where the work happened 

Separate metered consumption, subscriptions and prepaid commitments, and capture where the underlying research took place. Finance and tax teams need those distinctions to evaluate the arrangement and the domestic or foreign treatment. Collecting them during the period saves an invoice reconstruction exercise later. 

Agree what a project is, with both departments in the room

Choose the project definitions finance needs and map engineering's records to them. Give someone responsibility for maintaining that mapping as teams start new work, so engineers can answer reporting requests without translating their work from scratch. 

Put Your Token Reporting in Front of the People Who Review It 

Ask your controller and tax advisor to review a sample of the attribution records before the next reporting cycle. They can identify gaps while engineering still has the context to fill them. Accounting and tax judgments depend on the company's facts; a usable record lets those discussions move beyond estimates of the total bill. 

At Span, we've been working with engineering and finance teams on this reporting problem. If token spend has become material and your current reports stop at the team or vendor, book a demo focused on your finance reporting needs. We can walk through the evidence available for review and discuss how it fits your existing process.