When You Can Capitalize LLM Fine-Tuning Costs Under ASC 350-40

Until ASU 2025-06 takes effect (annual periods beginning after December 15, 2027, with early adoption permitted), ASC 350-40 splits internal-use software into preliminary project, application development, and post-implementation stages. Only the middle one, application development, is eligible for capitalization, and only once management has committed to funding the project and it's probable the project will be completed and used as intended. That commitment point is the line, not the calendar date the project started.

Once you're past evaluating whether to build the capability at all and into actually building it, these tend to qualify:

• Engineering time spent building the fine-tuning pipeline, data preprocessing scripts, and evaluation harness
• Compute costs for training and validation runs once the approach is settled, not the exploratory runs before it
• Third party or contractor costs for the same work, on the same basis as your own engineers' time

The test is always the same: is this building the thing you decided to build, or still deciding what to build.

Keep these out of the capitalized asset regardless of when they happen:

• Preliminary work: comparing base models, running early proof of concept prompts, deciding whether fine-tuning beats prompting at all
• Data collection and labeling that would have happened anyway for other purposes
• Ongoing inference costs once the model is in production, since that's operating the asset, not building it
• Training runs after launch that are really retraining for drift rather than building new functionality

You don't need new software to track this well. A shared sheet with columns for date, description, stage, hours or dollars, and the person who approved the project commitment is usually enough for an auditor to follow the trail later. The habit that matters most is logging the commitment date itself as its own line, since that's the fact everyone forgets to write down and needs to reconstruct months later.

Ask each engineer or contractor working on the project to tag their own time entries by stage as they go, rather than trying to reallocate a lump timesheet after the fact. A weekly five minute habit of tagging time is far more reliable than a quarterly reconstruction based on memory and old calendar invites, and it's the difference between a capitalization schedule you can defend and one you're guessing at.

Expect three requests: the board or management approval showing commitment to the project, a breakdown of capitalized costs by category and by month, and evidence that post-implementation costs, like ongoing inference and routine retraining, were kept out of the capitalized balance. Auditors are used to internal-use software judgment calls; what they're less forgiving of is a capitalized balance with no supporting detail behind the total.

The stage boundaries are clear in the standard but judgment calls show up constantly in practice, especially around when exploration ends and commitment begins, and around whether ongoing fine-tuning refreshes are new development or maintenance. Bring your CPA or auditor in while the project is happening, not at year end, so the capitalization policy you're applying matches what they'll expect to see when they review it. A short policy memo written at project kickoff, describing how you'll draw the stage lines for this specific project, saves a much longer conversation at audit time.