You Put AI to Work in Your Business. Now How Do You Account for What You Built?
Published Sep 30, 2026
By GOMEZ CPA
A lot of companies have reached the same conclusion over the last couple of years.
We need to start using AI.
For one company, that means the controller has been asked to automate pieces of the accounting function. Another hires an outside vendor to build an AI-assisted lead-generation system. A multi-location service business may use AI to analyze customer activity, schedule technicians and reduce drive time between jobs. An accounting team may build its own reconciliation workflow, management-reporting system or close automation.
And yes, sometimes the whole thing still starts when an owner or employee opens Claude, ChatGPT or Codex and starts experimenting with an idea.
What begins as:
“Let's see if AI can help with this.”
can turn into a real internal system surprisingly quickly.
Now employees are spending meaningful time developing it. Outside consultants have been hired. There are API charges, cloud infrastructure costs, AI coding tools and implementation expenses. The system may be pulling information from several sources, applying business rules and doing work employees used to handle manually.
At some point, this stops being only a technology discussion. It becomes an accounting and tax question.
What exactly did the company build, and how should the costs be treated?
Should some of those costs be capitalized for GAAP?
Can the same expenditures be deducted for federal income-tax purposes?
What happens when employees are spending compensated time building internal AI systems?
What about outside developers, AI coding tools, API charges, cloud infrastructure and implementation costs?
And what happens when GAAP says capitalize something while the tax law allows the business to deduct it now?
These questions are becoming more relevant because software development no longer belongs only to technology companies and large corporate IT departments. Businesses that would never describe themselves as software companies are now building their own internal systems. Sometimes they know that is what they are doing. Sometimes they do not.
But before we start capitalizing every AI-related invoice or assuming every dollar spent on an AI initiative is currently deductible, let’s look at the relevant accounting and tax guidance and see how it applies here.
And to be crystal clear, materiality matters here.
This article is not suggesting that a company should build a capitalization schedule around a $20 AI subscription or a few hundred dollars spent experimenting with an API.
Many companies preparing GAAP financial statements adopt capitalization policies that include reasonable dollar thresholds below which expenditures are normally expensed. The threshold should make sense for the size of the company and should be applied consistently.
But a capitalization threshold does not make the underlying accounting rules disappear. Because every capitalization policy should be applied consistently and should reflect the underlying substance of the transactions.
For example, a company should not take one material development project, divide it among dozens of smaller invoices and conclude that nothing needs to be capitalized because each individual invoice falls below the threshold.
While the point is not to create accounting work where none is needed. It is to recognize when an experiment has turned into a real project and the company is putting material amounts of employee time, outside services and technology costs into something it expects to use for several years.
That is when the accounting starts to matter.
And the answer depends much less on whether someone calls the project “AI,” an “agent,” “vibe coding,” or “my friend Claude” and much more on what the company actually built, what it does and what the company actually spent building it.
One More Point Before We Talk About GAAP
Many small businesses do not prepare financial statements in accordance with GAAP and nothing in this article suggests that every small business is required to do so.
Some businesses maintain tax-basis financial statements or use another special-purpose framework. Others need GAAP financial statements because of lender requirements, loan covenants, investor or ownership reporting, acquisition due diligence, contractual requirements or other external reporting needs.
The financial accounting discussion that follows assumes the business is preparing GAAP financial statements or otherwise needs to determine the GAAP treatment of its software-development costs.
If GAAP does not apply to the business, the financial statement answer may be different.
The federal tax analysis is also a separate question.
Did the Company Actually Develop Software?
This is where the analysis should always start.
Paying for Claude, ChatGPT or another AI application does not mean a company is developing software.
A business might use the same AI subscription to:
- draft emails;
- summarize contracts;
- research competitors;
- prepare marketing content;
- analyze spreadsheets;
- answer technical questions; and
- help employees write code.
But suppose the company combines an AI model with APIs, databases and other tools to create a system that:
- retrieves information from several sources;
- applies company-specific business rules;
- stores and processes data;
- routes transactions;
- generates reports;
- triggers other processes; and
- performs recurring work inside the company.
For GAAP purposes, how the resulting software will be used matters.
ASC 350-40, Intangibles, Goodwill and Other Internal Use Software, applies to software that is acquired, internally developed or modified to meet the company's own internal needs when the software is not being sold, licensed or otherwise marketed externally and there is no substantive plan being developed to do so. That can include much more than a traditional accounting system or ERP implementation.
A company might develop software to automate its close, route field personnel, analyze customer activity, manage inventory, generate reports, process transactions or perform any number of other internal business functions. The fact that employees used AI to help design or write the software does not change the underlying scope analysis.
Software subject to a substantive external marketing plan generally falls under ASC 985-20, Costs of Software to Be Sold, Leased, or Marketed, rather than the internal-use model in ASC 350-40.
That difference matters because ASC 985-20 uses a different capitalization threshold.
Under ASC 985-20, development costs incurred before technological feasibility has been established generally are treated as research and development expense. Once technological feasibility has been established, qualifying production costs, including coding and testing needed to produce the product master, generally are capitalized until the software is available for general release to customers.
Technological feasibility can be a relatively late point in the development process. High-risk development issues involving novel, unique or unproven functions generally must be resolved through coding and testing before that threshold is reached. As a result, companies developing software for external sale often expense a substantial portion of their development spending before capitalization begins.
That is quite different from simply saying:
“We developed software, so we capitalized the development costs.”
The intended use of the software determines which accounting framework applies, and those frameworks can produce materially different capitalization patterns.
There is also some nuance around software used to provide services to customers. Software can still fall within ASC 350-40 when the company uses the software itself to provide a service and customers do not receive a software license, assuming there is no substantive plan to market the software externally. By contrast, software that the company also sells, licenses or otherwise markets externally generally moves into ASC 985-20.
Consider two companies that build essentially the same AI-enabled scheduling system:
Company A builds the system solely to schedule its own field technicians.
That generally points toward ASC 350-40.
Company B develops the system as a product that it intends to license to other service companies.
That generally points toward ASC 985-20.
The software may perform almost exactly the same function. But the company's intended use can change the accounting model.
There can be another situation too. The company may not actually control the underlying software at all. It may be implementing or configuring a hosted application provided by somebody else. Under ASU 2018-15, if a hosting arrangement does not include a software license, it is generally accounted for as a service contract. The hosting fees are expensed as the service is provided, while qualifying implementation costs are evaluated for capitalization using the guidance in ASC 350-40 and, if capitalized, are amortized over the term of the hosting arrangement.
So before asking whether an AI-related cost should be capitalized, first figure out what the company actually has.
While that may sound obvious, with modern AI systems, it often is not.
Internal-Use Software Under ASC 350-40 (GAAP)
For a calendar-year company preparing 2026 financial statements that has not early adopted ASU 2025-06, the existing ASC 350-40 project-stage model still matters.
Under that model, internal-use software generally moves through three stages.
1. Preliminary project stage
This is where the company is figuring out what it needs.
Management may be evaluating alternatives, considering different technologies, defining requirements or determining whether the idea is even feasible.
Costs during this stage generally are expensed.
2. Application development stage
Once the preliminary work is complete, management has authorized and committed to the project and completion and intended use are considered probable, qualifying development costs generally are capitalized.
This is where you normally start seeing activities such as design, coding, configuration and testing.
3. Post-implementation operation stage
Once the software is substantially complete and ready for its intended use, ordinary training and maintenance generally are expensed.
Later upgrades may require another look if they add new functionality.
So when somebody says:
“We spent $150,000 on our AI project.”
that does not tell us enough.
What did the $150,000 pay for?
When were the costs incurred?
What work was being performed at the time?
Those questions matter.
What Costs Can Be Capitalized for GAAP?
ASC 350-40 is not limited to the invoice from the outside programmer.
Depending on the facts, capitalizable costs can include things such as:
- outside development services;
- external materials and services consumed directly in development;
- certain software acquired from third parties; and
- payroll and payroll-related costs for employees directly associated with the project, to the extent their time is spent on qualifying development activities.
General overhead does not suddenly become capitalizable because the company has a software project.
Neither does training.
And neither does every technology invoice that happens to arrive while development is underway.
That distinction is becoming especially important with AI.
Deloitte addressed AI-assisted development costs directly in August 2026. Its analysis reinforces that ASC 350-40 still governs. Companies must evaluate the substance of the AI services being purchased and determine whether the related costs are directly attributable to qualifying software-development activity.
For example, a dedicated AI coding agent used only for an identified software project can present a very different accounting fact pattern from an enterprise-wide AI subscription being used by accounting, marketing, sales, operations and management for general productivity.
The vendor name does not decide the treatment.
The activity does.
There Is No Automatic Five-Year GAAP Amortization Rule
This is where the GAAP and tax rules are often confused. People often remember something about 60 months and software. That is not a blanket GAAP rule.
For GAAP, capitalized internal-use software is amortized over its estimated useful life. Maybe the useful life is three years. Maybe it's four. It could be five. The answer depends on expected use, technological change, obsolescence and other economic factors.
The 60 month number comes up later on the tax side, which is a different rule.
The Rules Are Changing for ASC 350-40
FASB issued ASU 2025-06 in September 2025, making a significant change to the accounting for internal-use software under ASC 350-40. One of the biggest changes is the elimination of the traditional preliminary, application-development and post-implementation project stages for purposes of determining when capitalization begins.
FASB acknowledged that modern software development does not always follow a clean, linear path. Development methods such as agile can move repeatedly between design, coding, testing and revision, making the old project-stage model increasingly difficult to apply. Under ASU 2025-06, the same recognition threshold applies regardless of whether the company uses a traditional linear development process or a more iterative approach. Under the amended guidance, capitalization begins when two basic conditions have been met:
- management, with the appropriate authority, has authorized and committed to funding the software project; and
- it is probable that the project will be completed and the software will be used to perform its intended function.
- the software contains technological innovations or novel, unique or unproven functions or features, and the related uncertainty has not yet been resolved through coding and testing; or
- the software's significant performance requirements have not yet been identified or continue to be substantially revised.
Sometimes AI is simply one of the tools being used to develop otherwise conventional software. In other cases, the AI functionality itself may be the source of the technological uncertainty that affects when capitalization can begin. The amendments apply to all entities for annual reporting periods, including interim periods within those annual periods, beginning after December 15, 2027. Early adoption is permitted. For 2026 financial statements, a company therefore needs to know whether it has early adopted ASU 2025-06. If it has not, the existing stage-based model continues to apply.
What has not changed is the need to understand the substance of the project. Whether the development involves traditional programming, low-code tools, AI-assisted coding or more advanced AI functionality, the accounting follows the applicable software guidance and the facts surrounding what the company is actually developing.
Before We Get Into Tax, Section 174 Has Changed
This is worth slowing down for because the federal tax treatment of research and experimental expenditures has changed substantially in just a few years.
For tax years beginning after December 31, 2021 and before January 1, 2025, the TCJA version of §174 generally required domestic research and experimental expenditures to be capitalized and amortized over five years. Foreign expenditures generally were amortized over 15 years.
But Congress changed the domestic treatment in 2025. For amounts paid or incurred in tax years beginning after December 31, 2024, new IRC §174A generally allows a current deduction for domestic research and experimental expenditures. Current §174 generally applies to foreign research and experimental expenditures, which continue to be capitalized and amortized over 15 years. Software development is specifically addressed under the current rules.
When this article discusses a 2026 domestic software development project, the starting point is §174A, not the 2022-2024 domestic capitalization regime under former §174. Current IRS guidance reflects that post-2024 structure. There can still be old domestic §174 balances on a company's tax records from 2022 through 2024. Those legacy balances have their own transition rules and recovery options. They are a separate issue from the treatment of new development expenditures incurred in 2026.
Now Onto Tax, Section 174A
For tax years beginning after December 31, 2024, §174A generally allows a current federal deduction for domestic research or experimental expenditures. That includes domestic amounts paid or incurred in connection with software development. For qualifying domestic software-development expenditures, the general federal rule is now:
deduct them currently.
But that is not the only possible treatment. A taxpayer may elect under §174A to capitalize qualifying domestic expenditures and amortize them over 60 months or more, beginning when benefits from the expenditures are first realized.
Section 59(e) can also provide a separate 10-year election. The IRS currently describes those alternatives in the Form 4562 instructions and won't be covered in detail here. The point is simply that current deduction is the general rule, but it is not the only possible timing treatment.
Foreign Development Is Different
Domestic and foreign development should not simply be thrown into the same bucket. Foreign research or experimental expenditures generally remain subject to §174 and 15-year amortization using the midpoint convention. The IRS specifically includes foreign software-development expenditures in that treatment. That can matter for an established SMB. A company may have:
- an employee working on the project in Atlanta;
- a U.S. integration consultant;
- a software contractor in India;
- and another developer somewhere else overseas.
What Counts as Software Development for Tax?
The current statute specifically brings software development into the §174A framework. Older IRS guidance also gives us useful background on the types of activities the government has viewed as software development. That can include activities such as:
- planning software development;
- designing the software;
- building models;
- writing code;
- testing; and
- making necessary modifications before software is placed in service.
There is an important caveat here. Some of the existing IRS administrative guidance and Treasury regulations were written before Congress enacted §174A.
The IRS itself continues to reference Notice 2023-63, as modified, in its current Form 4562 instructions, but it does so alongside current §§174 and 174A and newer procedural guidance. The better approach is to start with the current Code and post-2024 guidance, using the older material where appropriate as interpretive background.
Section 174A Is Not the R&D Credit
There is another distinction worth making. Software development does not automatically mean:
§174A deduction + research credit.
The §41 research credit has its own requirements. Internal-use software can face additional research credit requirements. It is entirely possible for expenditures to enter the §174A analysis without producing a research credit. Those are two separate questions. That distinction becomes particularly important when an AI project is being built mainly to improve an ordinary internal business process.
The Same Project Can Have Two Different Answers
Now let's put some numbers to it.
Assume a calendar-year company spends $160,000 developing internal-use software in 2026. To simplify the example, assume:
- the company has not early adopted ASU 2025-06;
- the full $160,000 qualifies for GAAP capitalization under ASC 350-40;
- the same amount qualifies for the current §174A deduction;
- no §59(e) election or research credit applies; and
- the software is ready for use on January 1, 2027.
At December 31, 2026, the company has incurred $160,000 of development costs under both the GAAP and tax assumptions used in the example. For GAAP, the full $160,000 remains capitalized because the software is not yet being amortized. There is no current GAAP expense in 2026. For federal tax, the company takes the full $160,000 §174A deduction in 2026, leaving no remaining tax basis associated with those deducted costs. So at year-end, the company has a $160,000 GAAP carrying amount and a $0 federal tax basis for the same illustrative cost pool. GAAP capitalizes the cost for later amortization, while federal tax deducts it currently.
What Would Happen in a C Corporation?
For a taxable C corporation subject to ASC 740, the $160,000 book carrying amount and $0 tax basis generally create a taxable temporary difference.
At a 21% federal corporate tax rate:
$160,000 × 21% = $33,600
Ignoring state taxes and other adjustments, the corporation generally would recognize a $33,600 deferred tax liability because the tax deduction occurred before the GAAP expense.
What If the Business Is an S Corporation?
Using the same $160,000 project, assume the S corporation otherwise has $300,000 of ordinary business income. GAAP still reports the $160,000 software asset, while the current §174A deduction reduces federal ordinary business income to $140,000. The $160,000 difference becomes part of the book-tax reconciliation.
Because an S corporation generally does not pay regular federal income tax at the entity level, it ordinarily would not record the same federal deferred tax liability illustrated for the C corporation. The federal tax effect generally passes through to the shareholder.
What Happens to the Shareholder?
The shareholder receives $140,000 of ordinary business income on the Schedule K-1 rather than $300,000.
That also affects stock basis. For example, with a $500,000 beginning basis and no other adjustments:
- without the §174A deduction, ending basis would be $800,000;
- with the deduction, ending basis would be $640,000.
Then the Difference Starts Reversing
Assume the software has a four-year GAAP useful life beginning January 1, 2027. The company records:
$160,000 ÷ 4 = $40,000 of GAAP amortization per year
But the federal §174A deduction was already taken in 2026. There is no second federal deduction simply because GAAP now recognizes amortization.
The timing difference reverses over the following years. In 2026, the company records no GAAP amortization but takes the full $160,000 federal §174A deduction, creating a $160,000 book-tax difference.
Beginning in 2027, the company records $40,000 of GAAP amortization each year for four years, while no additional federal deduction remains because the tax deduction was already taken in 2026.
By the end of 2030, GAAP has recognized the full $160,000 as expense, federal tax has recognized the same $160,000 as a deduction, and the cumulative book-tax difference has fully reversed to $0.
The tax deduction happened first. The GAAP expense came later.
What About an LLC?
The first thing to remember is:
“LLC” does not tell us how the company is taxed.
LLC is a legal form.
For federal tax purposes, an LLC may be treated as a disregarded entity, partnership, S corporation or C corporation, depending on ownership and elections.
The first tax question is simple:
How is the LLC taxed?
The financial-reporting framework is a separate question, which is why we dealt with GAAP applicability earlier.
Multi-Member LLC Taxed as a Partnership
Assume the same business is a two-member LLC taxed as a partnership.
With $300,000 of income before the §174A deduction and a $160,000 deduction, partnership ordinary business income falls to $140,000. With a 50/50 allocation, each partner receives $70,000 rather than $150,000.
The partnership may still report a $160,000 software asset for GAAP while having no remaining federal tax basis in those deducted costs.
The partners then have separate outside-basis calculations, which can differ from both GAAP equity and tax-basis capital. Partnership-specific rules can affect the ultimate result, and those issues are beyond the scope of this article.
What About a Single-Member LLC?
A single-member LLC that has not elected corporate tax treatment generally is disregarded for federal income-tax purposes.
That means the federal income-tax activity generally flows directly onto the owner's return.
If the company is preparing GAAP financial statements, however, it can still have a GAAP software asset even though the associated tax deduction is being reported directly through the owner. Again, financial reporting and tax classification are separate questions.
What Does the Owner Actually Save in Cash?
This is usually the number people want to jump to.
A $160,000 deduction does not mean $160,000 of tax savings.
The deduction lowers taxable income.
The actual cash-tax benefit depends on the tax that otherwise would have applied.
Return to the S corporation example. Assume the shareholder is subject to an illustrative 32% marginal federal income-tax rate on the incremental income affected by the deduction.
The quick calculation is:
$160,000 × 32% = $51,200
That is a reasonable first estimate. But even that may be too simple.
The Business Still Spent $160,000
This is where tax meets FP&A.
The company spent:
$160,000 in cash.
Under our simplified assumptions, the owner's current federal income tax may be lower by approximately:
$51,200
So one way to look at the immediate cash effect is:
Cash invested: $(160,000)
Illustrative current federal tax reduction: $51,200
Net current after-tax cash outflow: approximately $(108,800)
That does not mean the project's universal economic “cost” is $108,800. It is simply one view of the current cash effect.
Management still needs to evaluate whether the project was a sound investment. That means considering whether the system reduced labor or operating costs, improved accuracy or capacity, generated additional leads or revenue, and how long those benefits are expected to last. Ongoing maintenance costs also matter, as does the opportunity cost of using the capital for this project instead of another investment.
The tax benefit belongs in that analysis. But it should not become the reason the investment was made.
Applying the Rules to a Real AI Project
Now let's put some numbers to it.
Assume a 30-person, multi-location company uses AI and automation to improve finance and operations. Employees work on the project alongside an outside integration firm, using APIs, a database and AI development tools to build an internal system for reporting, scheduling, lead management and administrative automation.
This is no longer a simple software subscription. It is a development project.
Assume the company incurs $136,000 in total project-related costs. That includes:
- $48,000 of employee payroll
- $35,000 of outside development and integration services
- $8,000 of dedicated AI development tools
- $12,000 of development API and cloud costs
- $14,000 of training and change-management costs
- $9,000 of enterprise-wide AI subscriptions
- $10,000 of production hosting and operating costs.
Employee Time Can Be a Real Development Cost
Suppose the controller, financial analyst and operations manager collectively spend meaningful portions of their compensated time designing, testing and implementing the new system. If the company is incurring actual payroll and payroll-related costs for employees directly associated with qualifying software-development activities, those costs can enter the ASC 350-40 capitalization analysis.
That means employee time records can become relevant. Not because everyone suddenly needs to complete a six-minute billing sheet. But if a material amount of compensated employee time is going into a capital project, management needs some reasonable basis for determining how much.
The fact pattern is very different from:
“The owner worked on this during the weekend and thinks his time is worth $250 an hour.”
What About the Owner Who Vibe Coded Part of It?
Suppose the owner personally spends 100 uncompensated hours improving the system. The owner normally values time at $250 per hour. That does not automatically create:
100 hours × $250 = $25,000
of a software asset.
It also does not automatically create a $25,000 §174A deduction. That $25,000 may be a very real opportunity cost. The owner could have spent the time serving customers, managing employees or doing something else. That matters for FP&A. It does not mean the business incurred a $25,000 accounting cost simply because the owner assigns an hourly value to unpaid time.
But suppose the owner is a compensated S corporation shareholder-employee and part of the owner's actual compensated working time was spent directly on qualifying development activity. That can be a different accounting situation because now the corporation has incurred an actual payroll cost. The analysis follows the real cost. Not an after-the-fact estimate of what somebody believes unpaid time was worth.
What About the AI Development Tools?
Of the company's $8,000 in dedicated AI development costs, assume the tools are available only to employees working on the internal application and are used for coding, testing and debugging. Those facts provide a stronger basis for associating the cost with development activity.
Contrast that with the company's $9,000 enterprise AI plan, which employees use for research, correspondence, analysis and general productivity as well as occasional development work. Broad business use makes the entire subscription much harder to associate with the software project.
The accounting follows the activity and the relationship to the project, not the AI vendor or product name.
So once again:
“We use Claude”
doesn't really answer anything.
We need to know what was purchased and what it was actually used for.
API Fees and Cloud Costs Require the Same Analysis
API and cloud costs may support development, testing, production use, storage or several activities at once.
The vendor category does not determine the accounting. If the amounts are material, the company may need a reasonable way to identify or allocate the development-related portion.
That's why simply recording everything to Software & Technology Expense can create problems later.
Training and Change Management Are Different Again
Suppose the company spends $14,000 teaching employees how to use the new system, redesigning internal processes and helping staff transition from the old workflow. Those activities may be essential to making the project successful. That does not necessarily make them software-development costs for GAAP.
An expenditure can be operationally necessary without becoming part of the software asset. That distinction is easy to lose when management thinks of the entire project as one large “AI implementation.” Accounting may require us to pull that project apart.
Production Hosting Is Not the Same as Development
Once the application is working, the company begins paying $10,000 per year to keep it running. That may include:
- production servers;
- API usage;
- data storage;
- model usage;
- monitoring; and
- other operating costs.
Maintenance Is Not the Same as New Development
AI systems often continue to evolve after launch, so maintenance and new development can overlap.
Bug fixes, prompt adjustments, credential updates and similar work generally look like maintenance. Adding a new module or significant new functionality may require a new development analysis.
The question is not whether the company is “still working on the AI system.”
It is what work is actually being performed.
The Records Matter More Than the Buzzword
Traditional software projects usually left a fairly clear paper trail. There were budgets, developer invoices, employee time records, approvals and a defined go-live date.
AI-assisted development can be much less structured. A project may begin as an accounting experiment, expand into operations, involve an outside API vendor, and eventually include custom code, databases and additional cloud capacity. Six months later, the company has a functioning internal application.
But nobody can quite identify when the “AI experiment” became a software development project.
That is the accounting challenge.
Small projects do not require an administrative monster. But when the amounts become material, the company should preserve enough information to identify:
- the project's purpose and management authorization
- employees and outside parties involved
- directly attributable labor and development costs
- project-specific AI, API and cloud costs
- domestic versus foreign development
- when the software became ready for use; and
- later maintenance versus new functionality.
For material projects, management should know that a development effort exists, who is working on it, what costs are being incurred and when the software becomes ready for use. Accounting should also have a process for distinguishing development from maintenance, tracking domestic and foreign development where relevant, and applying the current accounting and tax guidance. And let's not forget about internal control. See our previous insight article on the COSO framework and Internal Controls for AI.
The goal is not to slow down experimentation. It is to make sure that once an experiment becomes a material software project, the accounting does not have to be reconstructed after the fact.
One AI Project Can Produce Three Different Numbers
At the end of all this, management can legitimately have three different numbers for the same project.
Cash spent
What did the company actually pay?
GAAP expense
How much belongs in current earnings, and how much belongs on the balance sheet to be recognized later?
Tax deduction
How much can be deducted now, how much receives another tax treatment and what does that mean for the entity and its owners?
Those numbers do not have to match and often they will not.
So Your Company Has “Gone AI.” What Do You Do Now?
Do not start with:
“Can we write off our AI costs?”
Start with the facts.
What did the company build? Is it controlled software or a hosted service? Is it for internal use or customers? When did experimentation become development? What costs were incurred, where was the work performed, and when was the system ready for use?
Those facts drive the accounting and tax treatment. The development tools may have changed but the accounting questions did not. And sometimes “our AI project” is really a software-development project with accounting, tax and capital-allocation consequences.
Selected Authorities and Current Guidance
The principal authorities and guidance considered in preparing this discussion include:
Financial accounting
- ASC 350-40, Intangibles—Goodwill and Other—Internal-Use Software
- ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software
- ASU 985-20, Costs of Software to Be Sold, Leased, or Marketed
- ASU 2018-15, Customer’s Accounting for Implementation Costs Incurred in a Cloud Computing Arrangement That Is a Service Contract (Subtopic 350-40)
- ASC 740, Income Taxes
- KPMG, Software and Website Costs, February 2026
- Deloitte, Accounting for AI Costs Associated With Internal-Use Software Development, August 2026
Deloitte's August 2026 guidance specifically addresses project-specific AI coding tools, enterprise subscriptions, token and API charges, fixed subscriptions, employee activity and other costs increasingly found in AI-assisted software projects.
Federal income tax
- IRC §174
- IRC §174A
- IRC §41
- IRC §59(e)
- Revenue Procedure 2025-28
- Revenue Procedure 2026-32
- Notice 2023-63, as modified, where relevant as interpretive background
- Current IRS instructions for Form 4562 and other applicable forms
Revenue Procedure 2026-32, published in September 2026, provides current procedural guidance for method changes involving the post-2024 §§174 and 174A framework as well as the earlier TCJA §174 regime.
This article is intended for general informational and educational purposes only and does not constitute accounting, tax or legal advice. The accounting and tax treatment of software-development costs depends on the specific facts, financial-reporting framework, tax classification, elections, jurisdiction and other circumstances.
© 2026 Gomez CPA. All rights reserved.