Search for the Irish R&D tax credit and you will find the same post twenty times over. The rate went from 30% to 35%. The first-year payment threshold went from €75,000 to €87,500. Stack the credit on the 12.5% trading deduction and the effective benefit lands near 47.5%. All true, all written by accountants, and all of it describing money rather than the work that earns it.
Nobody writes the other half. The parts of Revenue’s guidance that decide whether a software claim survives are not tax questions. They are questions about how your team documents its work, when it commissions outside help, and whether anyone wrote anything down while the uncertainty was live. We build software for Irish companies who claim this credit, and the same three things go wrong every time. None of them happen in the accounts, so none of them are on your accountant’s list.
TL;DR
- The 35% rate applies to accounting periods with a specified return date on or after 23 September 2027, which in general means periods ending on or after 31 December 2026. For a calendar-year company, that is now.
- First-time claimants, and anyone who has not claimed in the previous three accounting periods, must file a pre-filing notification with Revenue at least 90 days before the claim is made. Miss it and the claim is not late, it is void.
- Revenue applies the OECD Frascati definition to software. Known methods in standard tools using the standard features of existing frameworks do not qualify, however hard the work was.
- Outsourced R&D is capped at the greater of €100,000 or 15% of your own in-house qualifying spend. Connected companies are worth nothing, and you must notify a subcontractor in writing, before or on the date of payment, that they may not claim.
- Revenue’s contemporaneous evidence standard requires an identifiable author and date of creation. Your team already generates that, and usually deletes the part that matters.
The deadline nobody puts in a headline
Under sections 766C and 766D of the Taxes Consolidation Act 1997, a company claiming for the first time, or one that has not claimed in any of the previous three accounting periods, must notify Revenue of its intention to file, in the prescribed form, at least 90 days before the claim is made.
The clock is not anchored where you expect. It does not run from your year end, it runs backwards from the date you file. Revenue’s own worked example makes the shape of it plain: a company with a 31 December 2026 year end intending to file its CT1 on 31 March 2027 must have the notification in by 31 December 2026. That leaves roughly four months, and the deadline lands in the same fortnight as everything else in December.
There is no reasonable-excuse door. If you have never claimed, or claimed in 2022 and then stopped, the notification is a precondition rather than a courtesy. It is also the most common way a first claim dies, and it dies quietly, because you do not discover the problem until you try to file.
What Revenue thinks software R&D is
Revenue leans directly on the OECD Frascati Manual: for software development to count, its completion must depend on a scientific or technological advance, and the aim must be resolving a technological uncertainty on a systematic basis. Then it says something most claims firms skate past. Development using known methodologies in standard environments with the standard features of existing tools does not typically advance technology. Routine analysis, copying, upgrading or adapting an existing product is out. Revenue’s own summary is blunt: much software development does not qualify as R&D activity.
That rules out a lot of genuinely difficult work. A framework rebuild is not R&D because it took nine months, and a fiddly integration against a documented API is not R&D because it was fiddly. User acceptance testing is explicitly named as non-qualifying, as is packaging a product for market. What does qualify, in Revenue’s own list of where uncertainty legitimately arises:
- Developing models or algorithms to hit a functionality goal, and translating them into code while establishing the goal is achievable at all.
- Establishing that what you built keeps functioning in different scale environments. Irish SaaS teams most often have this one and most often fail to claim it.
- Establishing that it functions across a range of platforms.
- Establishing that it integrates as intended with other systems, where that was a genuine open question rather than a documented API call.
Note the shape. Each is a question whose outcome was unknown when you started, that you resolved by systematic work, and that could have gone the other way. Revenue is explicit that a failed project still qualifies: the uncertainty is the asset, not the success. It also accepts that Scrum and similar methods are systematic despite not being linear, but it will not accept a claim that cannot separate qualifying from non-qualifying work inside the same sprint, and it puts that apportionment squarely on project managers.
The subcontracting rule that catches everyone
If you commission an external team, the credit does not follow the invoice. The statutory definition requires qualifying activity be carried on by the claimant company, with two exceptions: payments to a university or institute of higher education in a relevant member state, and payments to an unconnected third party. Both are capped at the greater of €100,000 or 15% of your own in-house qualifying spend, applied separately. Payments to connected companies do not qualify at all.
Two consequences. First, the cap is a ratio, and the legislation also requires you to have incurred at least the same level of qualifying expenditure yourself. A company that outsources its entire build has nothing to anchor the cap to. The credit is designed for companies doing the work with a partner, not companies handing it over, and that shapes the engagement before it starts rather than after.
Second, the trap: to claim on subcontracted costs, you must notify the subcontractor in writing that they may not themselves claim, in advance of the payment or on the date it is made. Not at year end. Not when the claim is prepared. Revenue accepts no notification is needed where the subcontractor could not have claimed anyway, such as an individual or a recruitment agency supplying staff. But a claim built on payments to an Irish development company with no notice given at the right time has a hole in it, and the hole is not fixable in arrears.
The fix is boring and effective: put the notice in the statement of work. One clause, signed before anyone writes code, and an entire failure mode disappears. Any agency worth working with will know exactly what you are asking for. Worth watching, meanwhile: the Department of Finance’s R&D Tax Credit and Innovation Compass has signalled a review of these subcontracting provisions, including the caps and the treatment of connected parties. The current rules do not match how software actually gets built, and that is now officially acknowledged.
Contemporaneous evidence is an engineering artefact
Revenue requires records made on a timely and consistent basis, kept continuously, with reliable assurance as to their integrity including the author and date of creation of each record. Electronic records are fine, provided they carry both.
Version control is a machine for producing exactly that. The problem is not that development teams lack evidence, it is that the evidence of uncertainty is the part that gets deleted. The spike branch proving the approach would not scale is force-pushed away. The benchmark that killed option B lives in someone’s terminal history. The decision record explains what was chosen and omits the three things that failed first, because nobody documents their own dead ends. Those dead ends are the claim. What to keep, none of it extra work if you decide at kickoff rather than at year end:
- Architecture decision records that name the uncertainty. Not “we chose Postgres”, but what was unknown, what the candidates were, what would have counted as failure, and what the evidence was. One page, dated, authored, in the repository.
- Spike branches that survive. Tag them and leave them. A branch proving an approach did not work is a dated, authored record of uncertainty being resolved, and it is free.
- Benchmark and load test output committed to the repository, not pasted into Slack. Scale-environment uncertainty is one of Revenue’s own qualifying categories and the easiest to evidence, because the artefact is a file with a timestamp.
- Time allocation applied as the work happens. Revenue asks for personnel, qualifications and time allocated. An R&D label in the tracker writes the sprint-level apportionment for you. Without it someone reconstructs from memory, and reconstruction is precisely what contemporaneous excludes.
Two more for the file. Grant aid against the same expenditure reduces the qualifying amount, so the credit and an Enterprise Ireland award do not simply stack. And there is a shortcut almost nobody knows about: where an Enterprise Ireland, IDA, Horizon 2020 or Horizon Europe R&D grant has been approved for the project, the company is a micro or small enterprise, the field is a prescribed one, and the credit claimed is €50,000 or less, Revenue will not as a rule challenge the science test.
What to do about it
- Establish whether you are a first-time claimant or have skipped three years. If so, get the pre-filing notification in. December is closer than it looks.
- Write down honestly which parts of the current project had an unknown outcome, then discard the rest. An over-broad claim that sweeps in the CRUD screens is worse than a narrow one that holds, because the review lands on the whole thing.
- Put the subcontractor notification clause into every statement of work, starting with the next one.
- Decide your evidence artefacts at kickoff. Retrofitting them in February is exactly what the guidance is designed to catch.
- Take the technical narrative to your accountant, not the other way round. They can price it. They cannot write it, and the science test is not a finance document.
The honest position: the credit should not change what you build. Architecting a system to be claimable rather than correct is a bad trade at any rate, and 35% of a worse product is still a worse product. But a lot of Irish software work genuinely qualifies and goes unclaimed, and the reason is almost never that the work was not novel. It is that nobody wrote down the uncertainty while it was still uncertain.
REPTILEHAUS builds custom software, AI systems and Web3 infrastructure for companies across Ireland and beyond, and we structure engagements so the evidence trail exists as a by-product of doing the work properly. If you are planning a build with real technical unknowns in it, get in touch.
Written from an engineering perspective, not tax advice. Rates, thresholds and the interpretation of qualifying activity change. Take the technical narrative to a qualified tax adviser before you file.
📷 Photo by Stephan HK on Unsplash
