Revenue doesn't ask you to submit your technical report alongside your CT1 when you make an R&D tax credit claim. But if your claim is picked for an aspect query or audit, it's the first thing they'll want to see, and a strong report can be the difference between a quick resolution and a drawn-out review.
Your R&D technical report is a document that sets out what you were trying to achieve, what made it uncertain, and what you did to find out; essentially, why your R&D qualifies for the credit.
Why your technical report matters more than you might think
Ireland's R&D tax credit is worth up to 35% of your qualifying expenditure for accounting periods beginning on or after 1 January 2026 (30% for periods before that). That's a significant amount of money to have riding on a document you might never be asked to hand over.
But "might never be asked" is doing a lot of work in that sentence. Revenue runs aspect queries and audits on R&D claims regularly, and when one lands, you're expected to respond fully and promptly. If your technical report already exists and covers the right ground, responding is mostly a matter of sending what you've already written. If it doesn't exist, you're writing it under pressure, often about work that wrapped up over a year ago.
There's also a tighter clock in Ireland than you might expect. Your R&D tax credit claim has to be made within 12 months of the end of the accounting period in which the expenditure was incurred. That's not much time to reconstruct a year's worth of technical detail from memory, especially if staff have moved on. Writing the report while the work is still fresh is best practice, for Revenue’s sake and your own.
What should your technical report cover?
A good technical report works through the same questions Revenue uses to assess whether your project qualifies. For each project, you should be able to address:
- The advance: what new capability, product, or process were you trying to create? This needs to be an advance in the field generally, not just new to your company.
- The baseline: what was the standard approach in your field before you started, and what were its limitations? What research did you do to establish this?
- The uncertainty: what didn't you know how to do at the start, and why wasn't the answer already available or readily worked out by a competent professional in your field?
- The resolution: what did you actually do to try to resolve that uncertainty? Include the tools, methods, and approaches used, and concrete examples of the hurdles you hit along the way.
- The results: what did you find out, whether the project succeeded, failed, or landed somewhere in between? Failed attempts and dead ends are useful evidence, not something to leave out.
- The competent professionals involved: who on your team has the expertise to recognise a genuine technical uncertainty in this field?
- Supporting evidence: what records, prototypes, test results, or documentation back up the narrative? Having contemporaneous evidence is actually a requirement of the scheme, so pay attention to this section.
Give the uncertainty as much attention as the advance
It's easy to write enthusiastically about what you were trying to build. That’s the exciting bit; your team’s goals and plans.
It's harder to articulate, in technical terms, why it was genuinely uncertain whether you could build it, and what you actually did about that uncertainty.
A report that spends three paragraphs on the advance and one sentence on the uncertainty and resolution tells Revenue that you might be describing a development project rather than an R&D one. The uncertainty and resolution sections are where the technical depth needs to live. Be specific about what you tried, what didn't work, why it didn't work, and what you changed as a result.
Keep the commercial context brief
It's natural to want to explain why your product is exciting from a business point of view, particularly if there's nothing else like it on the market. But Revenue isn't assessing whether your idea is commercially novel. It's assessing whether you advanced science or technology and resolved a genuine technical uncertainty to do it.
For example, take a drinks manufacturer launching a new flavoured product. That might be commercially novel, but if it's made using standard production equipment and established formulation techniques, there's no advance in science or technology and nothing here qualifies. Now take the same manufacturer developing a new preservation process to extend shelf life without additives, where existing methods don't achieve the required result and the team has to test and adapt several approaches to get there. That's the kind of project a technical report should be built around.
A short paragraph on commercial context is enough. Spend the rest of your time on the science and technology instead.
Who should write your technical report?
Your technical report should be written by the team that actually worked on the R&D projects. Their experience and expertise will save time and effort, as project details will come straight from the horse’s mouth.
It's tempting to default to whoever's most senior, but seniority isn't the test. For a software project, that's usually the developers actually doing the work, not a CEO or director. For an engineering or manufacturing project, it's the engineers and technical staff with relevant qualifications and hands-on experience.
When preparing your claim, take note of the team who worked on the project, their qualifications and experience. If Revenue question your work, they may want confirmation that an expert was working on the project who could accurately identify a genuine uncertainty.
It can be hard for your team to find time for this exercise, but it is essential to your claim complying. For more information, see our guide on getting your technical team to spend time on your claim.
Common mistakes that weaken a technical report
A few patterns come up again and again:
- Writing in heavy jargon. Revenue's caseworkers aren't necessarily experts in your specific field. Use the technical terms you need, but explain them. The caseworkers are more likely to request more information from you than try to work out an impenetrable report you’ve sent them, leading to more time spent on your claim than necessary.
- Treating it as a quick job. Gathering the detail and getting it into a coherent narrative takes real time, particularly if you have several projects to cover. Leaving it until close to your filing deadline usually means a thinner report than the work deserves.
- Vague descriptions of the work done. "We developed a new platform" tells Revenue almost nothing. Naming the specific technical challenge, the tools and approaches used, and concrete examples of what went wrong along the way makes the difference between a generic claim and a credible one.
- Inconsistent detail across projects. If you're claiming for multiple projects, each one needs its own report covering the same ground. A detailed report for your flagship project and a paragraph for everything else will draw attention.
Key takeaways
- Your technical report should answer the baseline, advance, uncertainty, resolution, and results of your R&D project. All of these topics should be covered in similar depth.
- Commercial novelty isn't the test. Keep the business context short and focus on the science and technology.
- Use the right team members. The people doing the technical work, not necessarily the most senior people in the company.
- Write it while the work is fresh. With a 12-month claim deadline, there's less room than you might think to leave this until later.
- Specifics beat generalities. Tools used, methods tried, hurdles hit, and what you changed as a result all make a report more convincing.
If you'd like help putting together a technical report that holds up to scrutiny, get in touch and we'll talk you through what's involved. You can also sign up to Tax Cloud to get started on your claim.
