Accounting for AI Compute Costs: Current Practice and What’s Changing

Accounting for AI compute costs is genuinely new territory. As AI-native and AI-enabled companies scale, they face classification decisions that conventional accounting frameworks were never built to handle. GPU compute hours, foundation model fine-tuning, inference infrastructure, and data pipeline costs land awkwardly in a chart of accounts designed for a different kind of business.

How a company classifies these costs shapes gross margin, R&D expense ratios, and the financial story it tells investors, lenders, and acquirers. There is no AI-specific accounting standard that dictates where these costs belong, so finance teams are applying existing frameworks by analogy — and a meaningful change to one of those frameworks is now scheduled to arrive. This piece looks at where practice has settled today, what is changing, and why the change is generating as much debate as clarity.

How AI Companies Are Accounting for Compute Costs Today

• Inference: Generally treated as cost of revenue, since it is incurred directly in delivering the product to customers.

• Training and experimentation: Generally expensed as R&D as incurred, the conservative treatment most auditors expect at the growth stage.

• Capitalization of model development: The unsettled area. Practice is inconsistent, the supporting guidance is mid-change, and the right answer is still taking shape.

Where To Categorize Compute Costs

Compute costs generally sit in one of three places on the financial statements, and each carries a different effect on the income statement and balance sheet. The right treatment turns on the nature of the underlying activity, which is what auditors evaluate, so the same GPU usage can be treated differently depending on its purpose.

Inference Is Typically Treated as Cost of Revenue

In most AI software businesses, inference costs are treated as cost of revenue because they are incurred directly in delivering the service to customers. Each time a customer uses an AI feature and the system calls a model, the GPU cost of that inference is a direct cost of serving the product, alongside hosting and embedded third-party software.

This treatment makes margins for compute-intensive products structurally different from those of software businesses without heavy inference workloads, which tend to run materially higher. A company benchmarking against conventional software margins owes its investors a clear conversation about what healthy unit economics look like for a model that carries real inference cost, and defining what belongs in cost of revenue is the first step in that conversation.

Training and Experimentation Are Generally Expensed as R&D

Training activities associated with research, experimentation, and model iteration are generally expensed as R&D as incurred. Auditors will assess the nature of each activity rather than the label attached to it, so what matters is whether the work supports research and development or the delivery of a defined product.

For most companies at an early stage, the work is still building toward a deployable asset, which supports expensing as incurred. This is the more conservative and defensible treatment, and it aligns with how most auditors approach early-stage AI development.

Capitalization Applies to Qualifying Production Asset

When a company develops or fine-tunes a model that will be deployed as a production asset with a determinable useful life, some portion of those compute costs may qualify for capitalization, shifting the cost from an immediate expense to a balance sheet asset that amortizes over time.

In practice, this is where treatment gets thin and inconsistent. Capitalization smooths expenses and lifts near-term margins, but it adds real complexity: a company has to track costs by project, document the basis for capitalizing, and defend useful-life assumptions that grow harder to support when models retrain frequently. There is also no clean, universally accepted line for when model-development compute should be capitalized, so companies taking aggressive positions are doing more interpretive work than the guidance clearly supports.

Recent FASB guidance (ASU 2025-06) points to where this is heading. It replaces the long-standing stage-based model with a principles-based threshold for when capitalization begins, and it takes effect for fiscal years beginning after December 15, 2027, with early adoption permitted.

Two points matter for AI companies. First, the guidance addresses internal-use software, and exactly how it maps onto GPU training compute and model development is not something the profession has fully worked out as of this writing. Second, for software delivered through the cloud, the change is expected to reduce how much development cost gets capitalized, not increase it. The direction of travel is toward expensing, and a policy set today should reflect that rather than get ahead of it.

Classification Depends on Engineering and Finance Working Together

A single GPU cluster often serves several purposes within the same month, running partly on exploratory research, partly on fine-tuning for a specific customer use case, and partly on retraining a production model. The costs arrive commingled by default, and finance cannot classify costs that engineering teams do not track. As AI organizations scale, cost accounting increasingly depends on shared operational definitions and tagging standards maintained jointly by engineering, finance, and operations.

Companies that lack this coordination tend to default to expensing everything as R&D or to dropping all compute into a single infrastructure line. The first choice understates the gross margin impact and hides true unit economics. The second produces financial statements that fail to reflect the actual shape of the business. A finance function built for an AI company needs cost tracking granular enough to separate inference from training from experimentation, which depends on engineering tagging compute by job type at the source.

How Investors Read Your Compute Cost Trajectory

Classification reshapes the financial narrative in ways that matter during a raise or an exit, and the audience reads it more skeptically than founders often expect. Capitalizing development costs lifts near-term gross margin on paper, but investors and acquirers — venture and private equity funds in particular — tend to look straight through it. They add the costs back to see the underlying P&L, because capitalization can flatter a margin profile without changing the economics beneath it. To that audience, an aggressive capitalization policy often reads as a distortion to unwind rather than performance to reward, and it can invite more scrutiny than it deflects.

The swing in reported gross margin from these choices can be large enough to move how investors apply revenue multiples and weigh capital efficiency, which is precisely why a margin profile that leans on capitalization tends to draw questions rather than settle them.

The gross margin impact is only part of the story. Investors increasingly focus on whether compute costs decline as a percentage of revenue over time. A company with comparatively lower gross margins today may be viewed very differently depending on whether inference costs are expected to fall through model optimization, workload efficiency, or infrastructure ownership.

Build the Infrastructure to Support the Numbers

Getting compute accounting right takes operational systems that produce the data behind the classification, well beyond a one-time policy decision.

Cloud Cost Allocation

The major cloud platforms provide cost tagging and allocation tools. Finance and engineering should tag compute jobs by purpose, separating inference, training, experimentation, and data processing. Reliable tags let a company allocate by data rather than assumption, which protects unit economics and reduces audit exposure. When the underlying systems strain to produce this detail, it is often a signal that the company has outgrown its current accounting platform.

Monthly Close Discipline

Compute costs often carry billing lags and usage-based complexity that complicate accruals. A rigorous monthly close process captures GPU costs in the right period and allocates them correctly. Allowing costs to accrue loosely across several months and then correcting in one period creates variances that are hard to explain, and clean monthly reporting is foundational for any company managing a compute-heavy cost structure.

Policy Documentation

Document the accounting policies for compute costs before the first audit. Set out the criteria that distinguish inference from training, define the basis for any capitalization, and record the useful-life assumptions behind capitalized assets. Auditors will ask, and written policy demonstrates that the treatment is principled and consistently applied. Companies that work with a finance partner who understands technology business models tend to enter that first audit with policies that hold up.

Consistency Outweighs Optimization

Companies should avoid changing compute-cost classification simply to improve reported margins. A business can often justify more than one reasonable treatment, and investors and auditors generally place more value on consistent application of a documented policy than on achieving a particular margin profile in any single period. A treatment that shifts year to year invites questions about every number above and below the gross margin line.

Make Your AI Cost Structure Work for Your Business

The decisions a company makes today about classifying GPU compute, training workloads, and inference infrastructure will shape gross margin, R&D ratios, and the capital efficiency story for years to come. These decisions are foundational to how investors, lenders, and acquirers read the financials, and they reward attention long before year-end.

Companies that build cost allocation infrastructure early, set clear accounting policies, and work with finance partners who understand compute-heavy models carry cleaner data, more defensible financials, and a stronger position into any raise or exit.

G-Squared Partners works with AI-native and AI-enabled companies to build the financial infrastructure that supports scale. Our fractional CFO services bring the domain expertise to establish classification policies that withstand audit scrutiny and produce financials that represent the business accurately. To talk through your accounting and what it means for your financial strategy, schedule a free consultation with our team.