R&D Tax Credits¶

Software development is research-intensive work. In most jurisdictions, the tax code recognizes this in some form: credits, deductions, capitalization rules, or accelerated treatment that can materially affect what a project actually costs the business. Whether or not a given engineering effort qualifies, and how it is treated on the books, is a finance question with engineering inputs.

The specifics vary by country, by company size, by the nature of the work, and by recent legislative changes. This chapter does not attempt to substitute for tax advice. It explains why the question matters to engineering organizations and what kind of records make the conversation possible.

Why Engineering Should Care¶

The financial treatment of software work is not just an accounting curiosity:

It changes effective cost. A project that qualifies for an R&D tax credit can have a meaningfully lower after-tax cost than one that does not. For some organizations, this is the difference between a viable initiative and a deferred one.
It changes whether work is expensed or capitalized. Some software costs can be deducted in the year incurred; others must be capitalized and amortized over multiple years. This affects reported profitability, which in turn affects valuation, hiring capacity, and how the business is perceived.¹
It depends on evidence the engineering team produces. Tax authorities want to see that the work was genuinely experimental, that uncertainty was being resolved, that approaches were tried and discarded. The artifacts that prove this (commits, design docs, experiment results) are produced by the engineering team or not at all.
It is jurisdiction-sensitive. Rules in the US, UK, Canada, Australia, and the EU all differ, and have all changed in the last decade. A multi-jurisdiction company has to handle several at once.

The cost of missing a credit the company was entitled to is paid in cash. The cost of claiming one without evidence is paid in audit exposure.

What Tends to Qualify¶

The specifics vary, but the questions tax authorities typically ask are consistent across regimes:

Was there technical uncertainty? Were there meaningful questions at the start about whether or how the work could be done?
Was the work systematic? Was there a process of hypothesis, experimentation, and learning, rather than straightforward execution of a known approach?
Was new technical knowledge created? Did the work produce capabilities, techniques, or systems that were not previously available to the organization?
Was the work resolvable only through experimentation? Or could it have been answered by reading documentation or asking a specialist?

Building a new feature with a familiar framework usually does not qualify. Building a novel algorithm, a new integration with no existing pattern, or a significant performance breakthrough often does. Routine maintenance and bug fixing usually do not. Original research, prototype work, and capability-extending engineering usually do.

What Makes Claims Defensible¶

The evidence that supports a credit claim is usually evidence that already exists if engineering is being practiced well:

Version control history. Commits, branches, and pull requests show what was tried, what worked, and what was discarded.
Design documents and RFCs. Records of the alternatives considered and the reasons one was chosen demonstrate that the work was experimental rather than rote.
Experiment results. A/B test outcomes, prototype reports, and failed-approach postmortems are direct evidence of the systematic experimentation tax authorities want to see.
Time tracking against projects. Allocation of engineering time to qualifying activities, separate from non-qualifying support and maintenance work, is the basis of most credit calculations.
Contracts and scope documents. For client work, the contracts establish who owns the resulting IP and therefore who can claim the work for tax purposes.

The unifying pattern: tax-credit defensibility is mostly a byproduct of engineering hygiene the team should already be doing.

What This Looks Like in Practice¶

Talk to qualified advisors early. Tax credit eligibility is not something engineering can determine on its own. The right specialists, brought in early, can shape both the work and the records to make claims defensible.
Separate qualifying from non-qualifying work in tracking. Time spent on research and novel development is treated differently from time spent on routine maintenance. Tracking the distinction is usually a tagging exercise, not a process change.
Keep records contemporaneously. Reconstructing evidence at audit time is far more expensive than producing it as a natural byproduct of the work.
Coordinate with finance on capitalization. Some software costs need to be capitalized; others can be expensed. Knowing which is which at the start of a project avoids painful restatements at year-end.

Practical reminder

Financial treatment should be considered early enough that records and contracts support it. Trying to retrofit evidence for a credit claim is more expensive than producing it as work happens.

The distinction between capitalized expenditure (treated as an asset, depreciated over time) and operating expense (deducted in the year incurred) is a recurring source of confusion in software finance. Rules vary by jurisdiction and have been particularly volatile in the United States since the 2017 Tax Cuts and Jobs Act changes to Section 174, which required domestic software R&D to be capitalized and amortized over five years. ↩