How to Capitalize Software Development Costs When an AI Wrote the Code

For most software companies, capitalization used to arrive wrapped in a timesheet.

An engineer worked on Project A for six hours. The project had moved beyond planning. The work involved building a feature, rather than keeping an old system alive. Someone reviewed the entries at month-end, and finance had an answer.

AI agents have made that answer less tidy. An agent can plan a change, write code, run tests, investigate a production issue, and draft documentation in one uninterrupted session. It can do all of that before lunch, which is good for the product roadmap and mildly annoying for the spreadsheet that is supposed to explain the cost.

The basic answer, at least under U.S. GAAP, is straightforward: software development costs can still be capitalized when AI wrote the code. The accounting framework does not change because the development resource was an AI service rather than a person.

What changes is the evidence. Finance needs to establish what the agent did, which approved software project it served, whether the project was in the appropriate development period, and what the service actually cost. The lines of code do not answer those questions on their own. Neither does a very impressive transcript.

This article provides general information for U.S. companies. The final treatment depends on the facts, the applicable reporting framework, contracts, accounting policy, and tax jurisdiction. Controllers and tax advisers should apply those facts to their own books and returns.

‍

The Agent Does Not Decide the Accounting

The first mistake is to classify costs by the tool that incurred them. A coding agent is neither inherently a capital expense nor inherently an operating expense. It is a development resource, and its use has to be classified by the work it performed.

For internal-use software, the relevant question under U.S. GAAP is whether the cost is a direct external service consumed in developing a particular software project, incurred while the project is eligible for capitalization. The service must be directly attributable to that project and a qualifying development activity.

That can include an agent that generates code for approved functionality, configures a system, develops an interface, performs development testing, or fixes a defect before the software is ready for use. The fact that the work happened through a model request rather than an employee keyboard does not make it less like development work. PwC reaches a similar conclusion for AI software: the coding effort is assessed under the same guidance as coding in other software projects.

The boundary matters as much as the activity. Preliminary evaluation, general research, employee training, routine maintenance, and production support are usually expensed. An agent that spends a session comparing technical options, repairing an active production problem, and generating new code has performed several different kinds of work. The entire session does not inherit the accounting treatment of its most capitalizable five minutes. That would be a creative reading of the rules, which is generally the least useful kind of creativity in a close process.

Pricing does not solve the issue either. A metered charge for tokens, requests, or agent tasks can provide unusually good evidence of when a service was consumed. But measurable usage alone does not make a cost capitalizable. It still has to connect to qualifying work on a defined project.

The opposite problem appears with broad subscriptions. A company may give a development team access to one AI tool for new features, maintenance, troubleshooting, research, and ordinary work. Even if the development team uses it heavily on a capital project, a broadly available fee can resemble a shared technology cost rather than a direct project cost. Spreading that subscription across projects based on headcount or token volume does not automatically change its character.

The most defensible record separates usage that is truly tied to a specific qualifying project from usage that keeps the general engineering machine running.

‍

The Tax Return Has a Different Story

Book accounting and tax accounting have always had a complicated relationship. AI did not invent that relationship, but it has given it another opportunity to confuse people.

For U.S. federal income-tax purposes, the current treatment of domestic research and experimental spending changed in 2025. New Section 174A permits an immediate deduction for domestic research and experimental expenditures, including software development, for tax years beginning after December 31, 2024. Taxpayers may also elect a capitalization and amortization method for domestic costs.

That means a cost that becomes a capitalized software asset for financial reporting may follow a different path on the tax return. The two treatments can coexist. They frequently should.

The domestic qualifier matters. Foreign research remains subject to the separate Section 174 capitalization and amortization regime. Earlier domestic costs may also carry their own transition rules. The IRS has issued procedures for elections and method changes, and the choice can interact with credits, losses, interest limitations, and state taxes.

So the title’s premise contains a small trap. “How do we capitalize this?” has at least two answers: one for the financial statements and another for the tax return. A third answer may emerge for a foreign subsidiary or a state that does not follow federal rules. A useful policy starts by labeling those questions separately.

The accounting policy should also state which version of the internal-use guidance the company applies. The current project-stage model remains in use for many companies, while ASU 2025-06 changes the recognition threshold for annual periods beginning after December 15, 2027, with early adoption permitted. The types of cost eligible for capitalization do not change under that update, but the moment capitalization begins may.

This is why a finance policy written only around “developer time” will age quickly. The policy needs to focus on project approval, eligible activity, direct attribution, and evidence. The person, contractor, or agent doing the work comes after that.

‍

Build the Evidence Before the Close

A capitalization policy gets much easier to apply when the operational record is built alongside the development work instead of reconstructed at quarter-end.

At a minimum, finance needs a link between an agent’s usage and a defined project. It needs the dollar cost, the timing, and a usable description of the activity. It also needs a way to separate software construction from exploration, maintenance, production support, and other work that belongs in operating expense.

That record should survive a skeptical question from someone who did not attend the planning meeting. What was being built? When had management approved the effort? What did the agent do? Was the software ready for its intended use yet? Which part of the provider invoice belongs to that activity? Those are old accounting questions. AI has merely stopped letting teams answer them by pointing at a time sheet.

This is where Miranda becomes useful. It reads coding-agent usage and prices it against real model rates, then attributes the spend to the project, agent, session, model, and user. Miranda does not decide whether a cost belongs in capex or opex. It gives the controller and technical accounting team the cost trail they need to apply that decision consistently.

That is probably the right division of labor. Let the agents write quickly. Let the accounting policy decide carefully.