Best Practices for Capitalizing AI Tool Spend

TL;DR: Capitalizing AI tool spend starts with tracing each token dollar to the project it funded. Under the current stage model in Accounting Standards Codification (ASC) 350-40, AI tool costs directly attributable to application development can be capitalized, while preliminary-project, training, and maintenance costs are expensed. Accounting Standards Update (ASU) 2025-06 replaces those stages with a probable-to-complete threshold for annual periods beginning after December 15, 2027. minware attributes token spend to each commit through its patented hypercube data model, then rolls it up to tickets and epics. Untraced spend lands in overhead cost, outside the capitalizable total, and PRs Traceable to Ticket shows where linking gaps sit.

AI coding agent vendors are moving from seat-based licensing to consumption-based pricing, which introduces highly variable cost structures. A cost that varies with usage has to be traced to the work that consumed it before any of it can be capitalized. An invoice shows the total an organization spent, while project attribution has to come from engineering data.

This piece covers classifying AI tool costs under ASC 350-40, allocating token spend to projects, building an audit trail, and closing the books each month. It also covers return on investment (ROI) reporting, which answers a separate question from capitalization. minware supports each step with cost capitalization reports and visible calculation logic. The method applies whether a team uses a platform or builds its own pipeline.

Classifying AI tool costs under ASC 350-40

This section covers the current accounting treatment, the upcoming standard change, and the conditions AI tool spend has to meet.

Applying the current stage model

Under ASC 350-40's stage model, preliminary-project and post-implementation costs are expensed as incurred, while application development costs are capitalized. Training costs are expensed at any stage, and routine maintenance or bug fixes can't be capitalized. Agile teams can move through all three stages quickly or even at the same time, which makes costs specific to application development difficult to identify.

The table below maps each stage to its treatment under the current model.

Project stage	Accounting treatment	Example activities
Preliminary project	Expense as incurred	Defining requirements, evaluating technologies
Application development	Capitalize	Building features, writing code, testing
Post-implementation	Expense as incurred	Training, bug fixes, routine maintenance

Preparing for ASU 2025-06

ASU 2025-06 replaces the project-stage framework in ASC 350-40 with a single recognition threshold. Capitalization begins once management has authorized and committed funding to the project. It also requires that completion is probable, with the software used to perform its intended function, which the standard calls the probable-to-complete recognition threshold.

The update takes effect for annual reporting periods beginning after December 15, 2027, with early adoption permitted. Until an organization adopts it, ASC 350-40's current stage model still applies. The threshold isn't met while significant development uncertainty remains, such as novel features whose feasibility hasn't been resolved through coding and testing. Finance teams need to apply judgment on that point and document their reasoning.

Qualifying AI tool spend for capitalization

AI tool spend can qualify for capitalization. AI services used to generate or modify code for approved functionality may be capitalizable development activities, provided the cost is directly attributable to a specific qualifying project. The same guidance sets four conditions. The cost must:

• Represent an external cost of materials or services consumed in developing the software

• Be directly attributable to a specific qualifying project

• Relate to a qualifying development activity

• Be incurred while the project's costs are eligible for capitalization

The pricing model doesn't settle the question on its own. A token-based charge isn't capitalizable just because it's measurable. Unlike a general subscription fee, though, a usage-based charge may be directly identified with a specific project and activity.

Allocating AI spend to projects

The steps below take token spend from the invoice to individual projects and teams.

Attributing token spend through the work it funded

Token spend should be attributed to projects through the work it funded. Allocating a broadly available AI tool's cost by developer headcount or labor hours doesn't on its own show that the spend was consumed by those projects. Evidence of project-level usage can come from AI platform reporting, billing details, project management records, and development tickets.

minware's patented hypercube data model connects that evidence. It recovers relationships between agent sessions, commits, pull requests, and tickets through time-based linking. That model tracks which commit and ticket each person was working on at any given time. Attribution can follow the work even when a developer forgets to link a branch to a ticket, though explicit linking makes those associations more accurate.

Mapping costs to capitalization criteria

Roadmap delivery cost is the figure to test against capitalization criteria. minware attributes engineering personnel cost plus AI token cost to each commit, then rolls both up to pull requests, tickets, and epics. By default, work on tickets in an epic counts as capitalizable, and teams can change that rule to match their own policy.

Capitalization criteria vary between organizations. Some classify work by issue type, others by label, epic, or a custom field, and many have changed their rules over time. minware represents those criteria as visible formulas, so finance can see which tickets count as capitalizable and why. Setting up an organization-specific rule is a configuration step, which customer success typically handles within a single call and about 24 hours.

Handling spend that can't be traced

Token spend that can't be traced to a project stays out of the capitalizable total, since a capitalizable cost has to be directly attributable to a specific project. minware counts work not traceable to any ticket as operating expense by default, and it reports that untraced cost as overhead cost.

Linking gaps shrink the capitalizable total, so they're worth fixing before the close. Hygiene metrics on minware's best practices report measure where the gaps sit. PRs Traceable to Ticket shows the share of merged pull requests linked to a ticket, and Tickets Completed with Estimate shows the share of completed tickets with an estimate set. Each failing pull request or ticket is listed, so a manager can work through the gaps one at a time.

Rolling spend up to teams

Team-level attribution depends on relationship recovery and identity resolution working together. Relationship recovery links agent sessions to the commits and tickets they produced, which is the harder half of entity resolution. Identity resolution, the easier half, matches each developer's usernames and emails across systems to a single contributor. Each system can hold a different name or email for the same person, and minware runs this matching automatically.

minware also infers team membership from source data, or matches activity to an organization chart from a human resources (HR) export. A developer's activity across every connected system then rolls up to one person on one team.

Creating an audit trail for capitalized AI spend

An audit trail depends on a few connected pieces, each covered below.

Tracing capitalized costs to tickets and pull requests

Capitalized costs need time records that track development effort by developer and by task to withstand auditor scrutiny. Time tracking is frequently the weakest link when auditing capitalized software costs, so build the record at the level of individual tickets and pull requests. The same guidance recommends defining the unit of account to reflect how management actually develops and manages the software.

Project attribution should be captured as the work happens, since capitalization decisions need contemporaneous documentation. minware builds that record from timestamped activity in the engineering tools themselves. Each capitalized cost then traces to the commits, pull requests, and tickets behind it.

Showing the calculation behind every number

An audit trail is a chain from token spend to capitalized cost, with every link visible. minware implements every metric in minQL, its patented formula language for engineering data, and the formula behind any report is visible in the UI. Each metric's data lineage, its full dependency chain, can be inspected the same way, so the calculation behind a reported number can be shown when an auditor questions it.

Definitions stay consistent across teams, because every report reads from the same formula.

Connecting the data in one layer

Capitalization data has to connect token spend, project codes, and the work behind them in one queryable layer. minware normalizes data from your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, and your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, into one model alongside AI tool data.

Three pieces of the patented hypercube data model make that layer usable for an audit. Relationship recovery links agent sessions, commits, pull requests, and tickets that carry no structured connection. Identity resolution matches each developer across systems. Data normalization converts each vendor's format into one consistent model, so a token spend figure traces to the work it funded without a manual rebuild.

Comparing a custom pipeline with a platform

Teams that build their own capitalization pipeline take on the extract, transform, load (ETL) work and its maintenance. The table below compares the two paths.

Factor	Custom pipeline	minware
Initial build	High, typically multiple weeks of engineering time for ETL, normalization, and reporting	Connect data sources. Pre-built reports are live once historical backfill completes
Ongoing maintenance	Your team owns compatibility as vendor APIs and schemas change	minware maintains compatibility with vendor APIs as they evolve
Capitalization rules	Written and maintained in your own code	Configured as visible formulas, usually by customer success within a single call and about 24 hours
Metric transparency	Formulas live in code or documentation you maintain	Every metric's formula is visible in the UI
Calculation questions	Fall to whoever built the pipeline	Customer success answers them without an engineering escalation

Closing the books on AI spend each month

Two tasks close out each month: reconciling token spend and exporting the data finance needs.

Reconciling token spend monthly

Reconcile token spend monthly, because usage-based AI costs vary from month to month. minware ingests data nightly, so spend figures reflect the previous day, and a mid-day ingest can be triggered when finance needs current figures before a close. Reviewing capitalization decisions on a recurring basis also keeps the classification consistent from one period to the next.

Reported token spend can differ from the amount actually invoiced. AI tool APIs and OpenTelemetry generally report what usage would cost at list price on a consumption-based plan, while flat-rate, tiered, or discounted plans bill differently. Where a customer has significant discounts, minware can multiply reported token costs by the total bill divided by total reported spend, so the capitalized figure reflects the average discount.

Exporting capitalization data for finance

minware exports capitalization data as a spreadsheet with a per-ticket breakdown of effort, its epic, and whether that time is capitalizable, which finance can map to enterprise resource planning (ERP) project codes. A second view sums capitalizable time for each person each month. Rows with no ticket ID show effort that wasn't traceable to a ticket, which matches the operating expense default for untraced work.

Salary data can be added after export to turn capitalizable time into capitalizable cost. Token spend attributed to the same epics sits in roadmap delivery cost, and the export can carry additional metadata for financial reporting on request. Self-service export is included on minware's Professional plan. On minware's Enterprise plan, customer success can also build custom spreadsheets, documents, or slides for cost capitalization.

Reporting the return on capitalized AI spend

This section covers how ROI reporting relates to capitalization, plus the metrics that belong alongside it.

Separating capitalization from return on investment

Capitalization answers which costs become an asset. ROI answers whether the spend bought more delivery, and it needs a different method. Regressing roadmap value delivery against token spend across teams and time periods gives a slope, the change in delivery per additional dollar of spend, which is the ROI figure itself. minware's AI impact reports show the slope alongside the R-squared value, which measures how much of the variation in delivery the spend explains.

Name the confounders when presenting the slope. Engineers reach for AI on work where it's likely to help, and early adopters are often already the strongest performers. Each outcome's trend over time for the same team is the supporting check. minware's Lean AI Framework regresses three outcomes separately against token spend: roadmap value delivery, on-time delivery rate, and overhead cost.

Pairing delivery outcomes with guardrail metrics

Bug rate and ticket cycle time act as guardrails on the value outcomes in minware's Lean AI Framework. Cycle time should hold steady or fall as AI spend rises. When delivery outcomes don't move, ticket cycle time and bug rate are where to look for the reason. minware's governance guide defines bug rate as bugs created divided by pull requests merged.

The table below shows common pairings. Story points completed, roadmap value delivery's default calculation, is the value metric. Pull requests merged and deployment frequency measure output, so neither says anything about delivery without a value delivery metric beside them. Each still needs both guardrails.

Primary metric	Quality guardrail	Efficiency guardrail
Story points completed	Bug rate	Ticket cycle time
Pull requests merged	Bug rate	PR lead time
Deployment frequency	Change failure rate, deployment-based configuration	Lead time for changes

minware lists the specific pull requests, tickets, and agent sessions behind each guardrail, so a manager can check whether a metric reflects the work before it reaches finance.

Building a capitalization process finance can audit

Capitalizing AI tool spend comes down to traceability. Classify costs under the stage model your organization currently follows, and plan for ASU 2025-06's probable-to-complete threshold. Attribute token spend through the work it funded, with untraced spend kept out of the capitalizable total. Then reconcile monthly against the bill, with every number backed by a visible calculation an auditor can follow.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source to explore the pre-built cost capitalization reports with your own data.

FAQs

What AI tool costs can be capitalized?

Under ASC 350-40's current stage model, AI tool costs directly attributable to application development work on a specific project can be capitalized. Preliminary-project, training, and maintenance costs are expensed as incurred. ASU 2025-06 replaces the stages with a probable-to-complete threshold for annual periods beginning after December 15, 2027. Confirm your policy with your auditors before capitalizing.

How do I handle AI spend that spans multiple projects?

Attribute it through the work each project consumed. minware's patented hypercube data model links agent sessions to the commits, pull requests, and tickets they produced, so token spend splits across projects by actual usage. Allocating by developer headcount alone doesn't show which project consumed the spend.

What if our project tracking data is incomplete?

Spend that can't be traced to a ticket counts as overhead cost and stays out of the capitalizable total. minware's PRs Traceable to Ticket and Tickets Completed with Estimate metrics list the specific gaps, so the team can fix linking before the close.

How often should we recalculate allocation?

Monthly, to match finance's reporting cadence. Usage-based AI spend varies month to month, so a quarterly catch-up leaves more unreconciled spend at each close. minware's nightly ingest keeps the monthly figure current.

Do we need a separate system for AI spend tracking?

Not for capitalization. minware connects AI tool data to version control and project management data in one normalized layer. That connection is what ties spend to projects.

Key terms glossary

Capitalization: Recording qualifying development costs as an asset on the balance sheet, to be amortized over the software's useful life. Under ASC 350-40's stage model, application development costs qualify.

Probable-to-complete recognition threshold: ASU 2025-06's trigger for capitalization. Management has authorized and committed funding to the project. It must also be probable that the project will be completed, with the software used to perform its intended function.

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 through the patented hypercube data model.

Overhead cost: Personnel cost and AI token spend not counted in roadmap value delivery. It covers cost not traceable to any ticket, plus cost traceable to an excluded ticket, by default a bug ticket or a ticket with no parent epic.

PRs Traceable to Ticket: A hygiene metric measuring the number of pull requests merged into a main branch with a link to a valid ticket, divided by the total number of pull requests merged into a main branch.

Tickets Completed with Estimate: A hygiene metric measuring the number of completed tickets that had an estimate field set, divided by the total number of completed tickets.

Relationship recovery: Linking commits, tickets, pull requests, and AI agent sessions that carry no structured connection between them. It is the harder half of entity resolution and the subject of minware's patent.

Identity resolution: Matching a developer's identity across systems with different usernames or emails. The easier half of entity resolution.

Data normalization: Standardizing messy vendor data formats into one consistent model so concepts can be connected across tools.

Audit trail: A visible chain from raw data to reported metric, with every calculation step inspectable. For capitalization, it ties each capitalized cost to the project, ticket, and pull request it funded.

Data lineage: The visible formula behind every metric, showing how raw data becomes a reported number. minware implements every metric in minQL, and the full dependency chain is visible in the UI.

Roadmap value delivery: The expected value of completed work items. If no explicit value field is configured, it defaults to story points completed on tickets that are not bugs and have a parent epic.

On-time delivery rate: The estimated roadmap item duration divided by the actual roadmap item duration, capped at 100% per roadmap item.

R-squared: In a regression chart, the share of the outcome metric's variation explained by the input variable, on a 0-to-1 scale.

Bug rate: A quality metric measuring the number of bugs created divided by the number of pull requests merged into a main branch.

PR lead time: The time from a pull request's first commit to when it was deployed. Deployment defaults to when the code merges into a main branch.

Ticket cycle time: The time from when a ticket was first marked in progress to when it was completed.