R&D tax incentives for software and SaaS

Software teams often assume that because their work is technical it is all R&D, and the tax authorities in all seven countries have published guidance saying the opposite. Building a new product with established techniques, integrating systems through documented interfaces and configuring a platform are development, not research, however new the product is to the market. The qualifying work is narrower: the specific technical questions a competent software professional could not answer from available knowledge, and the systematic work done to answer them.

This guide shows where those questions usually sit in a software or SaaS business, what to leave out, what evidence a reviewer expects and the costs often missed. It follows the shape of the manufacturers guide, because the method is the same even though the evidence looks different.

What this guide covers

• Where technical uncertainty tends to sit in software and SaaS work, and where it does not.
• The work to exclude, including the internal administration rules that several countries apply.
• Evidence that engineering teams already produce, and how to keep it usable.
• Costs that are often missed, including cloud, data and contractor costs.
• The software rule that matters most in each of the seven schemes.

Where to look

The question is the same as in every sector: was there something a competent professional could not know or deduce from available knowledge, and was systematic work done to find out? In software the answer is hidden inside a larger release, so look at the technical unknowns rather than the roadmap.

Performance and scale

A latency, throughput or concurrency target that no documented approach was known to meet at the required scale. The work to benchmark alternatives, modify them and find one that meets the target is a candidate; tuning a known approach by standard methods is not.

Algorithms and models

A model that had to reach a required accuracy, false positive rate or robustness on the company's own data, where it was not known whether any approach could. The experiments, including the architectures that failed, are the work. Retraining a model with a known method on new data is routine.

Distributed systems and data integrity

Consistency, ordering or recovery guarantees under failure conditions that the available components did not provide and that had to be designed and tested. Deploying a managed service that already provides them is configuration.

Security

A security property that had to hold under adversarial conditions, where it was uncertain whether any design could achieve it without breaking a performance requirement. Applying a standard library as documented is not R&D.

Embedded and device software

Software that had to work within power, memory or timing constraints that no known technique was shown to fit. The constraint and the failed attempts to meet it are the evidence.

What to exclude

• Feature development that follows known patterns, however commercially important.
• Integration through documented interfaces, platform configuration and vendor tooling used as intended.
• User interface and visual design, content and copy.
• Routine debugging, maintenance, upgrades and migrations with known methods.
• Hardening, rollout and support after the technical uncertainty has been resolved.
• Commercial uncertainty, such as whether customers will adopt a feature or what to build next.
• Software built to run the business's own administration, which several countries exclude or restrict.

Internal tools need particular care. The United States, Australia and New Zealand each have a rule aimed at software developed for the business's own administration, so a payroll, finance or reporting tool is treated differently from a product sold to customers. The country table gives each rule.

Evidence in software teams

Software teams produce records made at the time as a matter of routine, but most are unusable for a claim because nothing links them to a technical uncertainty. Make the link as the work happens.

• A dated design note at the start of each technical unknown: what was not known, what had been read or tried, and what result would count as success.
• Tickets and epics tagged to that unknown, so the backlog separates the experiment from the release.
• Benchmark harnesses and results, including failed runs, kept with the commit that produced them.
• Architecture decision records and pull request discussions showing the alternatives rejected.
• Model training logs, evaluation metrics and the dataset versions used.
• A closing note recording when the uncertainty was resolved, because the qualifying work ends there.
• Time by engineer by project, captured at least monthly.

A reviewer will ask who the competent professionals were and why they could not have known the answer. Record names, roles and the sources checked at the time, not at year end.

Costs often missed

A finance team that claims only developer salaries will under-claim, and may claim the wrong people. Check each item against the country page.

Getting started

Run a project identification workshop with the engineering leads, working from the architecture and the incident log rather than the roadmap. Ask for each release: what did we not know how to do, who judged it unknown, what did we try, and when did we know the answer? Expect the challenge round to remove most of the feature work. Then set up the tagging and design notes described above, so next year's claim is built from records rather than memory. Check the internal administration rule before claiming any internal tool.

Illustrative example

Illustrative example. Harrow Ledger Ltd, a hypothetical company, sells a SaaS accounting platform and spent 1,000,000 on engineering in the year. Of twelve roadmap items, three carried a technical unknown recorded in a dated design note: a reconciliation engine that had to match 50 million transactions a night where the benchmarked approaches took three nights; an anomaly model that had to reach a target false positive rate on the company's own data; and a multi-region failover design that had to keep ledger ordering intact. The other nine were features, integrations through documented interfaces and an interface redesign. Engineering time tagged to the three unknowns came to 300,000, plus 40,000 of cloud compute consumed in benchmark runs and 60,000 paid to a contractor who built the test harness. The reconciliation work ended in month five when the target was met; the two further months of rollout are outside. The internal reporting dashboard built for the finance team was not one of the three, and is in any case caught by the internal administration rules in several countries. The candidate base is 400,000 before each scheme's rules on contractors, cloud costs and location; the benefit at that country's rate applies to what survives those rules.

Country differences

One rule per country, in the scheme's own wording, that decides software claims. The country pages hold the detail.

Related pages

• Guide: R&D tax incentives for manufacturers
• Technical Teams Program, Module 5: Industry examples
• Guide: qualifying versus non-qualifying activities
• Guide: contemporaneous documentation
• In-House Finance Team Program, Module 4: Contractors and overseas costs
• Resource hub: eligibility

Educational material, not advice. Eligibility and treatment depend on the scheme and the facts.