AI Capitalization Guidance
There is no accounting standard written for AI spend. This paper gives Finance and IT teams a practical framework — one test, three worked scenarios, one governance checklist — for deciding what to capitalize and proving it.
Capitalization
Guidance
Most teams can capitalize software. Very few can capitalize AI.
Organizations have mature processes for capitalizing software development costs. Governance for AI tools, AI agents, LLM usage, and AI-assisted development is a different story — very few have established it.
No accounting standard specifically governs AI development costs. Existing guidance still applies: internal-use software under ASC 350-40, software for sale or licensing under ASC 985-20, certain R&D activities under ASC 730. AI doesn't change the principles. It introduces new cost types and attribution problems that have to be evaluated inside frameworks that were not written with token metering, agent sessions, or AI pair programming in mind.
The result is a visibility gap. Without project-level insight into AI costs, Finance teams struggle to identify eligible capitalization opportunities, support audit evidence, measure AI ROI, forecast AI investment, and govern enterprise AI adoption.
This guidance sets out the operative test, a clean capitalizable-versus-expensed reference, and three fully worked scenarios — each with a calculation and a journal entry — matched to the tracking-maturity levels most enterprises actually find themselves in.
As AI investment accelerates, organizations that cannot identify capitalizable AI costs may be leaving millions of dollars on the table each year.
The right time to establish a capitalization methodology is before AI spend accelerates further — not after.
Spending figures cited in the paper are drawn from Gartner's 2026 AI Spending Forecast. Standards references: FASB ASC 350-40 and FASB ASU 2025-06.
What you'll take away
A clean capitalizable vs. expensed reference
Where the line actually falls, cost type by cost type — so a reviewer can classify a line item without re-litigating the standard each time.
- Engineer time coding, refactoring or testing with AI assistance during active development
- License fees or usage credits tracked and restricted to an identified project build
- Model fine-tuning, validation and training runs done as the direct equivalent of building the asset
- General productivity or exploratory use not tracked to a specific project
- Preliminary-stage work: feasibility studies, vendor bake-offs, architecture exploration
- AI-assisted bug fixing, routine maintenance and monitoring after deployment
- Staff training on how to use AI tools
One three-part test: scope, activity, evidence
Every AI cost line — labor, subscription, token and API usage, compute — runs through the same test. All three conditions must be met. Fail any one and the cost is expensed.
Pricing structure does not determine capitalizability
A metered charge isn't automatically capitalizable because it's measurable, and a flat subscription isn't automatically overhead because it isn't metered. Direct attribution and supportable evidence are what matter.
Three methodologies, matched to your tracking maturity
Direct tracing for metered, project-tagged usage. A timesheet-based proxy for pooled licences with logged hours. An agile-output ratio for dedicated teams with no timesheets. Each one worked through end to end.
A governance checklist you can adopt
Mapping cost lines to authorized projects, confirming the capitalization window, tagging at the API gateway, and preserving the artifacts that stand behind each capitalized amount.
The hard cases, handled
Mixed-activity agent sessions, broad enterprise licences spread across teams, and why partial project relevance doesn't entitle partial capitalization without a defensible allocation basis.
Written for the people who have to defend the number.
Finance teams
Identifying eligible capitalization opportunities, measuring AI ROI, and forecasting AI investment without project-level visibility.
Controllers & policy owners
Setting a consistent methodology under ASC 350-40 and ASU 2025-06, and documenting it before spend scales.
IT finance, TBM & FinOps leads
Instrumenting AI cost data — API tagging, project billing codes, allocation logic — so the treatment can actually be verified.
Internal audit & assurance
Testing whether capitalized AI amounts are supported by task- or project-level records rather than aggregate estimates.
Engineering & delivery leaders
Understanding what sprint metadata, timesheet detail, and tool tagging Finance needs from delivery teams.
CIO and CFO organizations
Deciding how AI investment appears on the balance sheet as it becomes a larger portion of technology spend.
The paper closes with an implementation path: match each team to a scenario, route the tagging taxonomy and allocation logic through a governance review with Accounting Policy and IT Finance, and pilot in parallel for at least one full reporting cycle before relying on it in the general ledger.
Download the white paper
Fifteen pages of practitioner guidance, free. Tell us where to send it.
- The three-part capitalization test
- Capitalizable vs. expensed reference table
- Three worked scenarios with journal entries
- Governance policy checklist
- Recommended implementation path
Your copy, one form away
Yarken uses your details to send you this white paper and occasional guidance on IT spend management. We don't sell your data, and you can unsubscribe from any email. See our privacy notice.
Thank you! Your white paper is ready to download.
We've also emailed a copy so you can find it later.
Trouble with the download? Email hello@yarken.com and we'll send it straight over.
Get the treatment right from the beginning.
The longer you wait, the greater the potential adjustment or missed capitalization becomes as AI investment scales. Build the tracking capability now.
Download the white paper