Does Your Software Development Qualify for R&D Tax Credits?

Software companies are among the biggest claimants of Ireland’s R&D tax credit. But software is also one of the areas Revenue scrutinises most closely, because so much day-to-day development work looks like R&D without actually meeting the definition.

Knowing the difference before you claim is what separates a robust claim from one that unravels under review.

What qualifies for the R&D tax credit?

Revenue's test has nothing to do with how technically demanding your work felt, or how much code you wrote. To qualify, your activities must:

• Be systematic, investigative or experimental
• Sit within a field of science or technology
• Seek to advance that field
• Involve resolving genuine scientific or technological uncertainty

All four conditions have to be met together.

The word doing most of the work here is "advance." Building something new to your company is not the same as advancing the state of the art in software engineering. A new customer portal might be a first for your business, but if it's built with established frameworks and known integration patterns, it isn't R&D, however much effort it took.

A useful exercise before you claim is to set out your scientific or technological baseline: what was achievable in your field before the project started, and how did you go beyond it? If you can point to a specific limitation in existing tools, frameworks or methods, and show that your team didn't know in advance whether their approach would work, you're likely looking at a genuine claim.

Failed attempts and false starts are a good sign here, not a weakness. If your first approach didn't work and you had to iterate, that's often the clearest evidence that the outcome wasn't a foregone conclusion.

Software projects that can qualify

Software R&D tends to cluster around a few genuine categories:

• Novel algorithms or architectures, where no existing solution achieves what you need and the approach itself is uncertain
• New data structures or processing techniques built to reach a level of performance, scale or reliability that current methods can't achieve
• Resolving uncertainty about feasibility, where it isn't clear at the outset whether a required piece of functionality can be built within known technical constraints

Example: a company is building a platform that needs to process millions of transactions per second while maintaining full ACID compliance. Existing database architectures can't meet both requirements at once, and it isn't clear whether a new approach combining distributed computing with a novel consensus mechanism will work. That uncertainty, and the systematic work to resolve it, is what qualifies.

What doesn't qualify

The list of exclusions is longer than the list of inclusions, and it covers most of what a typical development team does day to day:

• Standard web or mobile app development using existing frameworks
• Integrating third-party APIs, however many are involved
• Implementing known features using established coding practices
• User interface and user experience improvements
• Customisation of software to your needs
• Routine maintenance, bug fixes, or updating software to a new version

Example: a team is building a web application on an established framework and needs to integrate several external APIs. The work requires real skill and careful planning, and there are challenges and some failures along the way, but there's no scientific or technological uncertainty about whether it can be done. A competent developer could solve it using standard approaches. It doesn't qualify.

Common pitfalls for software claims

Most software work fails the test on uncertainty, not advancement. The question Revenue asks is whether a competent professional in your field, someone with a solid grounding through training or experience, could have solved the problem using existing knowledge and standard approaches.

If the answer is yes, it doesn't matter how long the work took or how many iterations it went through. Difficulty and uncertainty are not the same thing. A junior developer might genuinely struggle with a problem that a senior engineer would resolve in an afternoon; that's a skills gap, but not quite a technological uncertainty.

It's also worth separating scientific or technological uncertainty from business uncertainty. Not knowing whether users will like a new feature, or whether your team has the budget or headcount to finish a project, has no bearing on whether the underlying technology is uncertain.

What documentation supports a software R&D claim?

Contemporaneous records matter more than a well-argued narrative written after the fact; they’re actually a necessity for a compliant claim. For each qualifying project, keep a record of the goal you were working towards, the specific uncertainty you faced, the approaches you tried, and the results, including the ones that failed. Alongside the technical record, track staff time spent on qualifying work, project timelines, and how costs were apportioned between R&D and non-R&D activity.

The kinds of evidence you might have include:

• Project management tools (Asana, Jira…)
• Source code management tools and code repositories (GitHub, GitLab…)
• Timesheets
• Internal communication (emails, Slack, meeting minutes…)
• Project scope documents, schedules, deliverables and project reports
• Risk registers
• Project budgets and financial reports

Companies claiming for the first time, or that haven't claimed in the last three years, also need to submit a pre-filing notification at least 90 days before the claim.

Key Takeaways

• You must seek to advance the technological field of software AND overcome uncertainty. Meeting one without the other means the work doesn't qualify.
• Difficulty isn't uncertainty. A competent professional readily solving a hard problem still fails the test.
• Most day-to-day development doesn't qualify. Standard frameworks, API integrations and UI work sit outside the definition, even when they're technically demanding.
• Failed attempts strengthen a claim. They're evidence the outcome genuinely wasn't known in advance.
• Documentation has to be contemporaneous. Records built after the fact carry far less weight with Revenue.

If you're not sure whether your development work meets Revenue's bar, it's worth getting a second opinion before you claim rather than after a compliance check. Contact us to talk through your specific projects with our team.