Engineering Cost Capitalization for AI Tool Spend: The Complete Guide

TL;DR: AI token spend can be capitalized under Financial Accounting Standards Board (FASB) Accounting Standards Codification (ASC) 350-40 only when it supports authorized development work on a specific project. Spend on preliminary planning, experimentation, routine maintenance, or work you can't trace to a project is expensed. The defensible method is activity-based attribution, linking agent sessions to commits, pull requests, and tickets, then rolling spend up to epics. minware's patented hypercube data model does this linking, with every formula visible to the controller or auditor who asks how a figure was calculated.

Your AI coding tool reports token spend in granular detail. Your finance team needs that spend attributed to specific projects and development stages before they can capitalize a dollar of it. If you can't connect those two data sources with a defensible trail, the spend gets expensed in the period it's incurred, when it could have been amortized with the software it helped build.

AI usage data usually sits in vendor dashboards. The work it supported lives in your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, and in your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps. This guide covers the accounting framework, the attribution methodology, and the audit evidence required. It then shows how a normalized data layer turns that requirement from a manual spreadsheet exercise into a repeatable report.

Understanding ASC 350-40 for AI spend

Capitalizing AI tool spend hinges on one question: does the spend qualify as a cost of internal-use software under FASB ASC 350-40, or is it expensed as incurred? The answer depends on the development work the spend supported and whether you can prove that link with data.

Defining what ASC 350-40 covers

FASB ASC 350-40 is the US generally accepted accounting principles (GAAP) standard for costs to develop or obtain internal-use software. It covers internally developed software, including AI software built for internal use. It also covers implementation costs for a cloud computing arrangement (CCA) that is a service contract, such as a software as a service (SaaS) subscription.

The standard limits which costs qualify. Capitalizable costs fall into two main groups. The first is external direct costs of materials and services consumed in development. The second is payroll cost for employees who work directly on the project. Overhead, along with general and administrative costs, is expensed as incurred. ASC 350-40 also excludes training costs and data conversion costs from internal-use software development costs, so those are expensed too.

Applying the stage model and ASU 2025-06

Under current rules, capitalization begins only after three conditions hold: the preliminary project stage is complete, management has committed funding, and the project will probably be completed. ASC 350-40 sorts project costs into three stages. The preliminary project stage and the post-implementation stage are expensed. The application development stage, covering design, coding, installation to hardware, and testing, is where costs can be capitalized.

Accounting Standards Update (ASU) 2025-06 removes the stage-based model. For fiscal years beginning after December 15, 2027, capitalization begins once management has authorized and committed funding, provided the project will probably be completed for its intended use. Early adoption is permitted under the new standard, so confirm which model your company applies before classifying any spend.

Extending the rules to AI token spend

US GAAP has no AI-specific guidance, so companies apply existing guidance by analogy. Fees paid for AI services follow the same underlying principles as other development resources. What decides the treatment is the activity the AI service performed and whether its cost can be traced to an eligible project.

Token costs for generating code, configuring software, testing, or correcting defects before release may be capitalizable. Token costs for experimentation, routine maintenance, or production support are expensed.

In both cases, project stage labels and ticket metadata in your project management system are the evidence behind the classification. They show finance which work each dollar of token spend supported, and when in the project it was spent.

Building an attribution framework for AI spend

A practical framework for AI spend capitalization has three components: spend classification, team mapping, and project attribution. Each one depends on engineering data that lives outside your accounting system.

Classifying AI spend by development stage

Token spend is an external cost of services consumed in development, which puts it in a different ASC 350-40 category from salaries. Like any external direct cost, it must be directly attributable to a qualifying project before it can be capitalized. Spend supporting preliminary evaluation, experimentation, training, or routine maintenance is expensed.

In practice, classification often happens at the ticket level. A ticket supporting new feature development under an approved epic may be capitalizable once the criteria are met, including management authorization, funding commitment, and probable completion. A ticket supporting routine maintenance or production support is expensed, while defect fixes before release can still qualify. The token spend associated with each ticket follows the ticket's classification, provided the spend is directly attributable to the project and supported by observable usage data.

Consistent ticket hygiene makes this classification traceable. Labeling epics as capitalizable or non-capitalizable helps, as does linking tickets to epics and branches to tickets. When those links are missing, the attribution is harder to defend in an audit.

Measuring and mapping AI spend by team

Team mapping assigns AI spend to the organizational unit that generated it. minware infers team membership from source data, or matches source activity to canonical team and org hierarchy information from a human resources (HR) data export. It then attributes token spend across teams and time periods in the same data model it uses for delivery metrics.

Token spend is the dollar cost of AI usage, a separate data point from the token count. AI tool APIs and OpenTelemetry generally report token cost at list price, so reported spend may differ from what you actually pay on flat-rate plans such as Claude Pro. Where your organization has negotiated discounts, reported costs can be scaled by your total bill divided by total reported spend.

The capitalizable amount is what you were actually billed, so apply that scaling before any reported spend enters the capitalizable total. Qualifying token spend is capitalized as part of the total project cost under the same rules as other development resources, since fees for AI services form no new category of capitalizable cost.

Attributing AI spend to projects

Project attribution is the hardest part, because AI coding tool usage data usually doesn't record which ticket an agent session worked on. minware's patented hypercube data model recovers relationships between agent sessions, commits, pull requests, and tickets that carry no structured link. It uses time-based linking to model what commit and ticket each person was working on at any given moment, so attribution can start before source data is fully cleaned up.

minware attributes token costs to each commit, then rolls them up to pull requests, tickets, and epics. That connects AI spend to the roadmap initiatives it supported, alongside the human engineering effort behind them. Explicit links still help, since developers often have several tickets in progress at once. Branch names or commit messages that reference a ticket make those associations more accurate.

Connecting AI usage data to projects

Connecting AI spend to projects draws on three data sources: AI tool telemetry, version control activity, and project management metadata. A normalized data layer joins all three, so token spend can follow the work it supported.

Collecting AI spend data from vendor sources

AI coding tools expose token spend through vendor APIs and OpenTelemetry integrations. minware's current integrations read GitHub Copilot and Cursor data through vendor APIs. Claude Code connects through both routes, while Codex connects through OpenTelemetry.

Historical coverage varies by source. The Claude Code Analytics API backfills historical usage for Claude Console organizations. The Claude Enterprise Analytics API covers engagement and adoption from January 1, 2026 onward. OpenTelemetry captures data from the point it's configured, so connecting it early widens the window you can report on.

Vendor dashboards typically report usage per user, model, or day. They can't show how much of a developer's spend supported a capitalizable feature or an expensed maintenance task. A developer might use Claude Code on three tickets across two epics in a single day, and the dashboard shows one total for that user.

Choosing an attribution method

There are three common ways to attribute AI spend:

• Seat-based allocation: Divides total spend equally across users (seats). It is simple, but spreading a broadly available tool's cost by developer headcount does not make it a direct cost of any project.

• Usage-based allocation: Attributes token spend to users, then splits it across projects using time tracking or other estimates.

• Activity-based attribution: Links token spend to specific commits, pull requests, and tickets, then rolls it up to epics. Reliable usage records like these can measure the cost each project consumed, which gives auditors a supportable basis.

Handling spend that can't be traced

Some AI usage can't be linked to a specific project or ticket. This happens when a developer uses an AI tool for exploratory work, or for any other work with no ticket in progress at the time. Spend that can't be tied to a qualifying project is expensed as incurred.

By default, minware counts work on tickets in an epic as capitalizable. Work on other tickets, along with work not traceable to any ticket, counts as non-capitalizable. Spend in that second group lands in overhead cost, minware's measure of personnel cost and token spend not counted in roadmap value delivery. Overhead cost is a minware metric, separate from the accounting overhead ASC 350-40 expenses.

minware's hygiene metrics, such as PRs Traceable to Ticket and Tickets Completed in Epic, flag pull requests with no linked ticket, plus tickets with no parent epic. Each gap becomes a specific item a manager can work through before the next reporting cycle.

Preparing audit evidence for AI spend

Audit readiness depends on a repeatable evidence package showing how AI spend was attributed to capitalizable projects. That package covers authorization records, calculation logic, and a trail from source data to reported figures.

Documenting authorization and cost support

Auditors focus on the capitalization start date. They require evidence of management authorization, funding commitment, and probable completion under ASC 350-40. The most common failure points are weak time tracking, unsupported cloud cost allocations, and capitalizing experimentation or maintenance.

AI spend adds its own version of the allocation problem. A token cost needs support showing the project it served, the work it supported, and the period it fell in. Usage records linked to tickets provide that support directly, since each record carries a date and inherits its project from the ticket.

Keep the authorization record for each epic alongside the spend it governs. When the approval date and the usage records sit in the same system, an auditor can check the capitalization start date against the first capitalized dollar without a separate reconciliation.

Showing the formula behind each figure

Defending a capitalization figure requires transparent data lineage, meaning you can show the calculation behind any number without filing a support ticket. In minware, you can view the formula behind any report, along with the definitions of its full dependency chain, directly in the UI. Customer success agents answer questions about formula behavior in minutes or hours.

When an auditor asks how token spend was attributed to a specific project, you answer by showing the formula in the UI. The same calculation runs across every reporting cycle, because minware defines each metric once and applies that definition in every report. Finance gets the same method regardless of which team or project they ask about.

Reporting on a monthly cadence

Audit readiness improves with reporting frequency. Monthly capitalization memos tied to the general ledger reduce audit friction. Manual capitalization reporting means rebuilding spreadsheets every cycle, pulling data from vendor dashboards, version control, and project management tools, then reconciling different definitions of the same metric. That work takes hours per cycle, and the data is often stale before it reaches finance.

A normalized data layer produces the capitalization report on demand from the previous day's data, since ingest runs nightly.

Working with finance on capitalization audits

The engineering leader's role in a capitalization audit is to produce the data trail finance needs and explain the attribution methodology. That means standardizing AI spend data and bringing in the controller early.

Standardizing AI spend data for finance

Finance needs AI spend broken down by project, team, and development stage. The breakdown happens at the ticket level, where each ticket is classified as capitalizable or non-capitalizable based on its epic, labels, and custom fields. The data comes from your AI coding tool's usage API or OpenTelemetry integration, connected to version control and project management through a normalized data layer.

The minware metric that captures the full cost is roadmap delivery cost, broken down by project or epic. It combines personnel cost with AI token cost at the commit level, so finance sees the full cost of each roadmap initiative, with human and AI inputs together. minware's cost capitalization reports show capitalizable work by team, contributor, or project. Personnel cost comes from full-time employee (FTE) count or salary data shared in a spreadsheet, with HR system integration on minware's Enterprise plan.

Involving your controller and external auditor

Involve your controller or external auditor before you capitalize AI spend for the first time. The accounting treatment depends on your capitalization policy, which should be reviewed by someone with audit experience.

The controller decides whether the attribution methodology satisfies ASC 350-40 and your organization's capitalization policy. The external auditor verifies that the data trail supports the capitalization decision. Settling the methodology before the first capitalization entry is easier than defending it mid-audit, and it gives the controller time to review how each figure is calculated.

Preventing misclassification of AI spend

Misclassification happens in two directions. Spend that should be expensed gets capitalized, or capitalizable spend gets expensed because the data trail is incomplete. Both create audit risk.

Expensing AI spend before project authorization

AI spend on preliminary project work is expensed under ASC 350-40. Until management authorizes the project and commits funding, AI spend on evaluating approaches, prototyping, or exploratory prompting is expensed.

Document the authorization date in your project management system as the date management approved the epic, backed by the approval record itself. That date marks where capitalizable spend can start. Because minware's default rule capitalizes epic work, an epic created during early exploration can pull preliminary work into the capitalizable total. Customer success can add rules on top, such as excluding preliminary-stage tickets inside an epic, or counting a non-epic ticket as capitalizable when a label or custom field says so.

Separating pre-release defect fixes from maintenance

Bug tickets need classification by timing. Fixes made while an epic is still in development can count as capitalizable work, because the software isn't yet ready for its intended use. Once a feature is released, fixes against it become routine maintenance or production support, which is expensed.

Record a ready-for-use date for each project so the dividing line sits in your data. A bug ticket opened during testing on an unreleased epic can qualify. A bug ticket against a released feature is expensed. Linking each bug ticket to the epic or release it belongs to lets the classification follow the project stage. In minware, bug tickets linked to an epic are capitalizable by default, so customer success can add a rule that excludes those closed after the ready-for-use date.

Evaluating build vs. buy for capitalization analytics

The build vs. buy decision for capitalization analytics comes down to total cost of ownership (TCO). An internal build starts with a large up-front project, typically several weeks of engineering time to build the data pipeline, before ongoing maintenance begins.

Comparing capitalization analytics capabilities

The capabilities that matter for AI spend capitalization are token spend attribution, flexible capitalization rules, pricing transparency, and integration coverage across your software development lifecycle (SDLC) tools. Integration coverage here means your version control system, project management system, and AI coding tools, with CI/CD optional for this use case.

Capability	Competitor landscape	minware's approach
AI spend attribution	Jellyfish lists token spend metrics and software capitalization on its pricing page. Pricing is quoted through sales, with a demo in place of a free trial	Token spend attributed to commits, tickets, and epics via entity resolution, with visible formulas in the UI plus a self-serve trial
Capitalization rules	Faros AI supports SQL customization, which may be as flexible, but customization is more difficult and less transparent	Customer success sets org-specific capitalization criteria, such as issue types, labels, or custom fields, typically within a single call and about 24 hours, with every formula visible in the UI
Pricing model	LinearB Essentials is $29 per user per month with a 50-user minimum, and Enterprise is $59 with a 100-user minimum, both billed annually. Span lists $45 per contributor per month on its comparison pages, with all prices as of this writing	$25/contributor/month Professional with no seat minimum, $45/contributor/month Enterprise with a 50-seat minimum, pricing listed publicly
Workflow and integration	LinearB is known for PR workflow automation, including PR routing and policy enforcement	Connects version control, project management, CI/CD, and AI tools through a normalized data layer with entity resolution

The tradeoff on the vendor side is configuration. Capitalization criteria differ between organizations, so minware's customer success team configures org-specific rules, while standard cost attribution reports work as soon as data is connected.

Weighing the cost of an internal build

Building an attribution pipeline internally means writing your own extract, transform, load (ETL) stack. This works until the vendor API changes or a stakeholder asks how a number is calculated. From then on, someone owns that maintenance and that explanation forever.

An internal build also has to solve cost allocation on its own, one of the most common audit failure points. For AI spend, the pipeline has to absorb schema drift in OpenTelemetry data as well as changes to vendor APIs.

minware connects to these sources through vendor APIs and OpenTelemetry integrations. It normalizes the data into a canonical model, then backfills one year of history on the Professional plan or unlimited history on the Enterprise plan, wherever the source keeps it.

Checking your capitalization readiness

Use this checklist to assess whether your current data hygiene supports audit-grade AI spend capitalization:

• Authorization dates recorded: Each capitalizable epic records the date management approved and funded it.

• Epics labeled as capitalizable or non-capitalizable: Every epic has a label or custom field indicating whether it qualifies for capitalization.

• Tickets linked to epics: Development tickets are children of a defined epic or project.

• Branches linked to tickets: Feature branches reference a ticket ID in the branch name or commit messages.

• AI usage connected to projects: Your AI coding tools feed an analytics platform that attributes token spend to tickets and epics.

• Project stage labels consistent: If your company still applies the stage model, all teams use the same labels for the preliminary project, application development, and post-implementation stages.

• Calculation logic documented: You can show finance the formula used to attribute AI spend to projects, applied consistently across reporting cycles.

Each unchecked item is a gap that will need manual cleanup every reporting cycle.

Making AI spend capitalization repeatable

AI token spend can be capitalized only when it traces to authorized, qualifying development work, so the attribution trail matters as much as the accounting policy. Connecting agent sessions to their commits and tickets shows finance which epics the spend supported, while spend that can't be traced falls into overhead cost. minware keeps that trail in one place, and the formula behind each figure is open for review in the UI.

Start a 14-day free trial at minware.com, no credit card required. Connect your version control, project management, and AI coding tools to see cost attribution reports with your own data.

FAQs

Can we capitalize AI tool spend if we can't tie it to specific projects?

Generally no. Under ASC 350-40, an AI cost must be directly attributable to a specific qualifying software project before it can be capitalized. AI spend with no traceable link to a qualifying project is expensed in the period it's incurred.

How do we allocate token spend when engineers work on multiple projects?

Use activity-based attribution: link each agent session to its commits and tickets, then roll that spend up to epics. Usage records tied to commits and tickets give a supportable basis for measuring each project's share, which seat-based allocation can't provide.

What if our AI tool vendor doesn't provide project-level usage data?

Connect AI usage to version control commits and project management tickets through a normalized data layer, such as minware's. Vendor usage data usually stops at the user, model, or day level, so spend is attributed to projects through those commit and ticket links.

Do we need to capitalize AI spend the same way we capitalize salaries?

Not in the same way. Under ASC 350-40, token spend generally counts as an external direct cost of services, a separate category from payroll. It is capitalized when it's directly attributable to a qualifying project and supports a qualifying development activity during the eligible period.

How far back do we need historical data for capitalization reporting?

You need historical data back to the start of the capitalization period for each project. minware backfills one year of data on the Professional plan and unlimited history on the Enterprise plan, wherever the source system keeps that history. For AI spend, that means vendor APIs such as the Claude Code Analytics API, since OpenTelemetry data starts from the point it's configured.

Key terms glossary

Capitalization vs. expensing: Capitalization records a cost as an asset on the balance sheet and amortizes it over time. Expensing records the full cost in the current period on the income statement.

Application development stage: The stage of software development under FASB ASC 350-40 when qualifying costs are capitalized. It begins once the preliminary project stage is complete, management has committed funding, and completion is probable. It ends when the software is substantially complete and ready for its intended use.

Cost attribution: The process of linking token spend and contributor effort to specific roadmap initiatives, epics, or cost centers.

Token spend: The dollar cost of AI tool usage, as reported by AI tool APIs or OpenTelemetry. On flat-rate, tiered, or discounted plans, reported spend may differ from the amount actually invoiced.

Roadmap delivery cost: Engineering personnel cost combined with AI token cost, attributed to each commit, then rolled up to pull requests, tickets, and epics via minware's patented hypercube data model. Includes both human and AI cost so leaders can see how heavily each project used AI.

Overhead cost: Personnel cost and AI token spend that goes toward work not counted in roadmap value delivery, i.e. cost not traceable to any ticket, or traceable to a ticket excluded from roadmap value delivery (by default, a bug ticket or a ticket with no parent epic/project ticket).

Data lineage: The visible calculation logic behind a metric, showing how source data flows through transformations to produce the reported figure. Transparent data lineage supports audit-defensible capitalization reporting.