Why did software development costs stop being immediately deductible?

Section 174 governs research and experimental expenditures, and a 2017 amendment effective for tax years beginning after 2021 required specified research or experimental expenditures to be capitalised and amortised over a period of years rather than deducted currently, with a longer period for foreign-conducted research. The statute expressly treats software development as such an expenditure. The rules in this area have drawn sustained legislative attention and have been the subject of repeated proposals, so the current-year position must be confirmed rather than assumed from any article.

Is prompt engineering software development for these purposes?

There is no clean statutory answer, and that is the practical difficulty. Writing and iterating prompts inside an application, building tool definitions, and constructing retrieval pipelines look like software development in substance because they are engineering work producing functionality. Writing a marketing prompt in a chat window plainly is not. The dividing line most advisers work from is whether the activity produces or modifies a component of a product, and the evidence for that lives in the repository, not in a job title.

How are inference and training compute bills treated?

The classification tends to follow the purpose of the spend rather than the invoice. Compute consumed to serve production traffic is an ordinary cost of delivering the service. Compute consumed to develop, train, fine-tune or evaluate a model as part of building the product looks much more like development expenditure. A single cloud bill often contains both, which is why cost attribution by workload — tagged at the project or job level — is worth more than a percentage estimated at year end.

Can we claim the R&D credit for AI work if we are just using a foundation model API?

Possibly, and it depends on whether the activity meets the credit's own tests rather than on whether the work feels innovative. The section 41 credit applies to qualified research meeting a multi-part test including a permitted purpose, technological in nature, elimination of uncertainty, and a process of experimentation, subject to specific exclusions. Systematically evaluating architectures against measured uncertainty can qualify; calling an API with the documented parameters is a harder argument. Note also that the credit and the capitalisation rules are separate regimes with different definitions, so qualifying for one does not settle the other.

Does it matter where the engineers are located?

Materially. Research conducted outside the United States is subject to a longer amortisation period under the capitalisation rules, and the research credit generally requires research to be conducted within the United States, with narrow exceptions. Offshore contractor arrangements that were priced purely on hourly rate can therefore carry a tax cost that was never modelled, and the location analysis follows where the work was performed rather than where the invoice was issued.

What documentation actually decides these positions?

Contemporaneous, activity-level evidence: project descriptions stating the technical uncertainty being resolved, time allocation tied to those projects rather than to departments, tagged compute spend, and a repository history that corroborates the narrative. Reconstructed allocations built from an org chart after year end are the weakest form of support and are exactly what gets challenged, because the underlying question is what people were doing, not who they reported to.

Section 174, R&D Credits and AI Development Costs: The Tax Question Nobody Scoped in 2026

Why This Became a Cash Problem for Software Companies

For most of the modern software era, engineering salaries were deducted in the year they were paid. A statutory change effective for tax years beginning after 2021 required specified research or experimental expenditures — a category the statute expressly extends to software development — to be capitalised and recovered over a period of years, with a materially longer period where the research is conducted abroad.

The immediate effect for a company spending most of its money on engineers was taxable income appearing where there was no profit, and the position has remained politically contested with repeated legislative proposals to change it. Anyone reading this should confirm the rule in force for the specific tax year with their adviser rather than relying on a summary. What has not changed, and what this article is actually about, is the structural question underneath: which of your AI activities fall inside the category at all.

The Three Buckets an AI Project Splits Into

Most AI work in a product company distributes across three treatments, and the boundaries run through the activity rather than the team.

Development expenditure. Building the feature: designing the pipeline, implementing retrieval, writing tool definitions, running fine-tunes, building the evaluation harness, iterating on architecture. This is the bucket where the capitalisation question bites.
Cost of delivering the service. Inference for production traffic, the hosting that serves it, and the ongoing support of a shipped feature. Ordinary operating spend, and the largest line item for many companies once a feature is live.
Qualified research for the credit. A narrower set defined by its own statutory test, overlapping with the first bucket but not identical to it. Work can be capitalised development and still fail the credit's experimentation requirement.

The common error is treating these as one decision made at the department level — "the AI team's costs" — when the same engineer in the same week may generate spend in all three. The second common error is assuming the cloud bill belongs entirely to the second bucket because it arrives monthly.

Where AI Work Is Genuinely Ambiguous

Several categories of AI spend have no settled treatment and reasonable advisers reach different conclusions. Knowing which they are is more useful than a false answer.

Prompt and system-instruction work. Functionally it configures product behaviour and is version-controlled like code; nominally it is text. Substance-over-form arguments generally favour treating in-product prompt engineering as development work.
Data preparation and labelling. Sometimes an integral part of developing a model, sometimes a routine data-cleaning cost, and the spend is often large enough that the distinction matters on its own.
Evaluation infrastructure. An eval harness is built to resolve uncertainty about whether an approach works, which is close to the core of what the research concept describes.
Failed experiments. Abandoned approaches are often the strongest evidence of a genuine process of experimentation, and are the first thing deleted from the repository and forgotten in the write-up.
Third-party model subscriptions. A seat licence consumed by developers is not obviously the same as compute consumed by a training job, and a single vendor invoice may cover both.

The Credit Has Its Own Test — and Its Own Traps

The research credit under section 41 requires qualified research meeting a multi-part test: the expenditure must be of a kind eligible under the research expenditure rules, be undertaken to discover information technological in nature, be intended for use in developing a new or improved business component, and substantially all activities must constitute a process of experimentation. Several exclusions then apply, including adaptation of an existing component to a particular customer's requirement, research after commercial production, and research funded by another party.

Three of these are unusually live for AI work. Funded research matters where a customer paid for the build and retains rights, which describes a great deal of applied AI work done under enterprise contracts. Adaptation matters where the work is tuning an existing system for one client. And internal-use software — tools built for your own operations rather than for sale — is subject to additional and more demanding requirements, which is precisely the category most internal AI automation falls into.

What to Put in Place This Quarter

Tag compute at the workload level so training, evaluation and production inference are separable in the bill without a year-end estimate.
Track engineering time against projects that correspond to technical objectives, not against departments.
Write a short technical-uncertainty statement at the start of each significant AI project: what was unknown, what alternatives were considered, how you tested them.
Record where work was performed, including contractors and offshore teams, because location changes the treatment on both regimes.
Preserve the failed branches. Discarded experiments are evidence, and the repository history is the cheapest contemporaneous documentation you will ever have.
Flag customer-funded builds at the contract stage, since who bears the risk and who keeps the rights determines whether the credit is available at all.
Revisit the position each year rather than rolling it forward. This is an area with active legislative attention and a rolled-forward assumption ages badly.

Frequently Asked Questions

We are pre-revenue. Does any of this affect us?

It can, in two directions. Capitalisation can produce taxable income at a company with no profit, which is the scenario that made this rule notorious among startups. On the other side, eligible small businesses may in some circumstances apply a portion of the research credit against payroll tax liability rather than income tax, which is one of the few mechanisms that returns cash to a pre-revenue company. Both need to be confirmed against current-year rules and your specific facts.

Does buying an AI product rather than building one avoid the question?

Largely, yes — subscription software purchased and used as sold is ordinarily an operating expense. The line blurs once your engineers build substantially on top of it, because the integration work is your development, not the vendor's. The more the deployment is configured, extended and evaluated by your own team, the more it starts to resemble a build.

How does this interact with financial-statement capitalisation?

They are separate systems and they routinely produce different answers. Accounting standards for internal-use and for-sale software have their own thresholds around technological feasibility and project stage, and the tax rules do not follow them. A company can capitalise for tax and expense for book, or the reverse, and the reconciliation is normal rather than a sign of error.

Can we simply amend prior returns once we get this right?

Changing how these expenditures are treated is generally a method-of-accounting question with prescribed procedures rather than something handled by amending at will, and there have been specific transition procedures for this area. That is an adviser conversation, not a spreadsheet one — but the documentation you build now is what makes any future correction defensible.

Is there a de minimis amount below which nobody cares?

There is no bright-line exemption, and the practical threshold is set by materiality to your own return rather than by rule. The more useful framing is that the documentation cost is low and front-loaded while the reconstruction cost is high and arrives under time pressure, so the case for tagging spend properly does not really depend on the size of the number.

Who typically raises this first?

Diligence. Buyers and investors ask how AI development costs were treated, whether credits claimed are supportable, and whether offshore engineering was analysed. An unsupported position becomes a purchase-price adjustment or an escrow item, which is a considerably more expensive way to discover the answer than asking your accountant this quarter.

Check What Your Site Claims About How the AI Was Built

Product and about pages describe proprietary models, in-house research and custom training in language that diligence will compare against how the spend was actually classified — and against what the engineering work really was.

See every claim your site makes about your AI and how it was built. Run a free scan and check each against what you would say under diligence.

This article is general information and not tax or legal advice. The treatment of research and experimental expenditures has been the subject of ongoing legislative change, and the correct position depends on your tax year, entity type and specific facts. Confirm with a qualified tax adviser before taking any position on a return.

Your AI Spend Has a Tax Classification. Someone Picked It Already.