Software development and R&D tax incentives: what counts and what does not

Most software projects contain some work that would satisfy any of the four schemes and a great deal that would not. Teams that claim the whole project get challenged; teams that identify the technical unknowns and claim the work that addressed them generally do not. The distinction is not about how modern the technology is. It is about whether the outcome was uncertain to people who knew the field.

What tends to qualify

• New or substantially improved algorithms where published methods did not meet the requirement.
• Architecture work to achieve performance, scale, reliability or security targets that the available approaches could not meet, proven through experimentation.
• Novel data processing, machine learning models or inference approaches where the outcome could not be predicted from existing knowledge.
• Integration at a scale or under constraints where standard patterns failed and new techniques had to be developed and tested.
• Extending the capability of a platform beyond what its design or documentation supported, where the extension required experimentation.

What tends not to qualify

• Building standard applications on established frameworks, however large.
• Configuring or customising commercial software using documented features.
• Routine bug fixing, refactoring, upgrades and maintenance.
• User interface design, user research and usability testing.
• Porting to a new platform or language using known methods.
• Data entry, content and routine data migration.

Jurisdiction specifics

United States

Software developed primarily for internal use faces additional tests beyond the standard four-part test, including a high threshold of innovation and significant economic risk. Software sold, leased or licensed to customers, or that enables interaction with third parties, is generally not treated as internal use.

United Kingdom

HMRC applies the general guidelines to software and has published specific guidance on how it views software projects, including the point that using existing technology in a new way is not R&D unless it required an advance in the underlying technology.

Australia

Software claims must identify core activities conducted as experiments whose outcome could not be known in advance, and AusIndustry has published sector guidance with examples; internal business administration software is specifically excluded from core activities.

Canada

The CRA's eligibility guidelines apply the same "why" and "how" questions to software; the technological uncertainty must be more than a business or programming challenge that competent developers could resolve with standard practice.

Documenting software R&D

Software teams already generate the best evidence any claimant could want, as long as it is kept:

• A design document or architecture decision record that states the unknown before the work starts.
• Pull requests, tickets and commit messages that record what was tried and why it was abandoned.
• Benchmarks, load tests and experiment logs, including the failures.
• Sprint records mapping people to the R&D work stream, so that time can be allocated without guesswork.

Ask the team to add one sentence of "why" to tickets touching the uncertain work. That single habit produces more defensible evidence than any year-end narrative.

A test you can apply today

For each candidate work stream, ask a senior engineer: "Before we started, did we know how to do this, or could we have found out from public sources?" If the honest answer is yes, it is development, not R&D. If the answer is "we had to try things to find out", you have the beginning of a claim, and the evidence to support it is probably already in your repository.

Educational material, not advice. Eligibility depends on the facts and the current rules in your jurisdiction.