Tracking R&D Capitalization for AI Engineering Work That Doesn't Look Like Software

Traditional software capitalization tracking often leans on time tracking tied to tickets or sprints in a project management tool, on the assumption that a ticket roughly maps to a deliverable. AI development work includes plenty of time that doesn't map cleanly to a ticket: running an experiment that fails, tuning a training configuration, or waiting on a long training job to complete while reviewing results. None of that is wasted time from an accounting standpoint, but it needs its own tracking category rather than being lumped in as overhead.

Have engineers log time against project and stage, not just project, using whatever project management tool you already run. The category that matters most is distinguishing exploratory work, deciding whether an approach will work at all, from committed build work, executing on an approach you've already decided to pursue. That's the same line ASC 350-40 has traditionally drawn between preliminary and application development stages (ASU 2025-06 replaces those stages with authorization and probable-completion criteria for annual periods beginning after December 15, 2027), so getting engineers into the habit of tagging work by project phase helps both operational visibility and capitalization support under either model.

Training and evaluation compute is often the largest single cost in an AI capitalization project, and it needs the same stage tagging as headcount time. Tag training jobs at the point of submission with the project and stage they belong to, so the compute bill can be split the same way the payroll cost is, rather than left as an undifferentiated infrastructure expense that never gets matched to the project it supported.

The number a CFO actually wants isn't payroll or compute in isolation, it's the total cost of ownership for the capability: engineering time, compute, any third party data or tooling cost, rolled up against the stage split. That TCO figure is what supports the capitalized balance, what justifies whether the project was worth doing, and what a future project can be benchmarked against when someone asks how much a similar capability should cost to build.

Keep the TCO rollup at the project level, not the team level, since a single team often runs several AI projects at once and a team-level number blends a cheap, mostly finished project with an expensive, still-exploratory one in a way that's useless for judging either.

A workable tracking setup covers these points:

• Have engineers log time against both project and stage, using the project management tool you already run.
• Separate exploratory work, where you are deciding whether an approach will work, from committed build work.
• Tag training and evaluation jobs with project and stage when they are submitted, so compute cost splits the same way payroll does.
• Roll headcount, compute and any third party data or tooling into one total cost of ownership figure by stage.
• Review logged stage allocation every quarter to catch both undercounting and overcounting.
• Track fine-tuning of a third party model as its own category, separate from training a model from scratch.

Time tracking drifts if nobody checks it. A quarterly review comparing logged stage allocation against what engineering leadership's own sense of the project's progress would suggest catches both undercounting, engineers who forget to log time, and overcounting, time logged against a project that's mostly idle while someone's actually working on something else. Neither error is malicious, but both compound if left unchecked for a full year.

The review doesn't need to be adversarial. Frame it to the team as a check on the process, not an audit of any individual's time, and it's far more likely to surface honest gaps early rather than encouraging people to quietly patch their own numbers to avoid a difficult conversation.

Fine-tuning a third party foundation model and training a model from scratch look similar in a project plan and don't always belong in the same capitalization bucket. Fine-tuning usually means a much smaller compute bill and a shorter application development stage, since most of the underlying capability was already built by the model provider, not by your team. Training from scratch or substantially retraining a base model's core weights is a larger, longer effort that more plainly resembles the traditional software development ASC 350-40 was written around, though your auditor decides how the guidance applies to your facts.

Track the two separately in your stage tagged time and compute data rather than rolling them into one undifferentiated AI project bucket, even when the same team works on both in the same quarter. A blended TCO figure that combines a light fine-tuning pass with a heavy from-scratch training run tells you less about either one than two separate figures would, and makes it harder to compare the cost of a future fine-tuning project against this one specifically.

This distinction also matters if you ever need to explain the capitalized balance to an auditor or investor: a much smaller capitalized figure for a fine-tuning project is expected and doesn't need defending the way an unusually small figure for a from-scratch training effort would.