AI Unit Economics, FinOps & Infrastructure Cost ModelingPlaybook3 min readUpdated September 2026

Capitalizing AI Pretraining Costs: What the Guidance Covers

Pretraining a foundation model from scratch can run into eight figures, and how you account for that spend, capitalized and amortized over time, or expensed as incurred, materially changes what your income statement looks like in the year you spend it. This isn't a call to make casually, and it isn't the same call for every company or every model.

Start with what the accounting guidance actually says, then apply it to your specific situation with your auditor, not the other way around.

Vendors Covered in this Article

Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.

What does the capitalization guidance actually cover?

Under the long-standing ASC 350-40 stage model, you could capitalize costs incurred during the application development stage, once you'd decided the project would be completed and used for its intended function, but not during the preliminary or post-implementation stages; ASU 2025-06 replaces the stages with authorization and probable-completion criteria for annual periods beginning after December 15, 2027. Whether a large-scale pretraining run counts as internal-use software development, versus research and development that should be expensed as incurred, depends on facts specific to your project: is the model built for internal use in your own product, and is there substantive uncertainty about whether the effort will even produce a usable model. This is a real judgment call, and it's one to make with your auditor, not one this article can make for you.

The costs that typically qualify once you're past that judgment call

Once you're in the application development stage, compute costs for the actual training runs, the engineering time spent building and tuning the training pipeline, and directly attributable third-party costs tend to qualify for capitalization. Costs from the research phase, exploring whether the approach will even work, evaluating architectures, early experimentation, typically don't, since that phase is squarely research and development under most interpretations.

The line between the two phases is rarely as clean in practice as it sounds on paper. A single training program often moves back into research when an early result looks wrong and the team goes back to testing a different architecture, and that shift should move the accounting treatment with it rather than leaving everything capitalized on the strength of the original plan.

Why this decision has real cash and tax implications beyond the income statement

Capitalizing spend doesn't change how much cash goes out the door, but it changes when the expense hits your income statement, which affects reported profitability, loan covenants tied to earnings, and how a training-heavy year looks to a board or an acquirer comparing you against a competitor who expensed the same kind of spend instead. Talk to your tax advisor separately from your auditor, since tax treatment of research costs doesn't always follow the same rules as the book accounting decision above.

How do you pick a useful life that survives an audit?

The useful life you choose has to reflect how long the model will actually generate value before it's retrained or replaced, not the longest defensible number you can find. For a model in a fast-moving domain where you expect to retrain within a year or two, a short useful life is the honest one, even though it means recognizing the expense faster. A useful life stretched out for a model your team is already planning to replace within a year would not hold up to scrutiny.

Documenting the decision as you make it, not after

Write down, at the time you make the call, which phase each major cost fell into and why, what the intended use case was, and what useful life you assumed and how you arrived at it. Process Street is a reasonable place to keep that decision checklist as a repeatable process for the next model, rather than reconstructing the reasoning after the fact when a new model or a new auditor asks about it.

Record these points at the time you make the decision:

  • Which stage each major cost fell into, whether preliminary, application development or post-implementation, and why you placed it there.
  • The intended use case for the model when you decided to capitalize, so the completion judgment is documented.
  • The useful life you assumed and how you arrived at it, tied to your expected retraining cadence.
  • Which research-phase costs, such as early experimentation and architecture evaluation, you separated from later training-run costs, and how.

Bringing your finance team up to speed on a policy most of them haven't seen before

Most finance and accounting staff have applied this guidance to conventional internal-use software, a CRM build-out or an internal tool, and not to a foundation model training run, so the policy needs actual explanation, not just a memo nobody reads. Trainual is one place to turn that policy into something new team members actually work through, rather than a document that sits in a shared drive until the next audit surfaces a gap in understanding.

Executive Capability Standard

What Good Looks Like

The standard is a documented, auditor-reviewed judgment call on capitalization made at the time of each major training run, with a useful life that reflects how long you actually expect to use that model.

Building The Capability (5-Stage Skill Ladder)

1. Learn:Read ASC 350-40's application-development-stage criteria in full with your controller before your next major training run, not after the invoice arrives.
2. Do Manually:Draft a one-page capitalization decision memo for your next training run by hand, covering phase, intended use, and proposed useful life.
3. Delegate:Assign your controller or a senior accountant to own the capitalization judgment call and useful-life review for every major model going forward.
4. Automate:Build a recurring reminder tied to each capitalized model's anniversary to reassess whether its useful life still matches your actual retraining plans.
5. Buy:Bring in your external auditor or a technical accounting advisor before your first large capitalization decision, not after you've already recognized the expense one way.

How to Get Started

Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.

Frequently Asked Questions

Does this apply to fine-tuning an existing model, or only pretraining from scratch?

Yes, the same framework applies to fine-tuning, but the facts usually point differently. Fine-tuning is often a shorter, more certain project with a clearer intended use from the start, which can make the capitalization case more straightforward than for a large, exploratory pretraining effort. Talk to your auditor about your specific project rather than assuming either answer.

What happens if we capitalize a model and then abandon it?

Generally, you write off the capitalized costs when a project is abandoned before completion rather than continuing to amortize them. Avoid capitalizing costs from a project where completion is still genuinely uncertain, since a later write-off is a far more visible event than expensing the spend as you went.

How often should we revisit the useful life assumption?

At least annually, and any time your retraining cadence or product roadmap changes materially. A useful life set when you expected to run a model for a few years needs revisiting the moment your team decides to retrain sooner instead, since continuing the original amortization schedule at that point would no longer reflect reality.

About the numbers

This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.

Related Guides