Many businesses carry out genuine R&D without ever calling it that. Engineers solve problems they haven't solved before. Developers build functionality that doesn't yet exist in any library. Food scientists tweak formulations until something works. The work is real; the structure around it is often improvised.
That lack of structure has a cost, and not just for your tax credit claim. A well-planned R&D process produces better outcomes, reduces wasted effort, and generates the kind of records that make it straightforward to show Revenue what you did and why it qualifies.
This post looks at the stages of an effective R&D process and, at each stage, what you can do to make R&D tax credit claim preparation feel like a natural part of the work rather than an afterthought.
The stages of an effective R&D process
Stage 1: Generating and framing ideas
Every R&D project starts with a problem or an opportunity. The mistake at this stage is moving too quickly from "here's a challenge" to "here's what we're going to build." Before you commit time and budget, it's worth taking a step back to define the problem precisely.
A good problem statement does three things: it describes what you're trying to achieve, it identifies what's technically uncertain about achieving it, and it sets out why existing approaches or off-the-shelf solutions don't already solve it. That last part matters more than people realise.
Revenue's definition of qualifying R&D requires that the work advances a field of science or technology, which means it has to go beyond what's already publicly known. Doing this analysis early means you're not just setting your team up for more focused work; you're also establishing the foundation of your technical narrative.
Practical tip: At the end of each ideation session, write up a one-paragraph problem statement for any idea that progresses. Include what you're trying to achieve, what the technical uncertainty is, and why it's not already solved. This takes almost no time and becomes invaluable later.
Stage 2: Evaluating and prioritising
Once you have a range of ideas or project candidates, the next job is deciding which ones are worth pursuing. This is where R&D processes often go wrong: teams pick projects based on enthusiasm or business pressure rather than a clear-eyed assessment of feasibility and potential.
A structured evaluation considers at least three things: technical complexity (is this genuinely uncertain, or just unfamiliar?), resource requirements (do you have the skills and capacity?), and market readiness (is there demand for the outcome?). Projects that score well on all three are the ones most likely to generate value and, as a side benefit, are also the ones most likely to qualify for R&D tax credits.
It's also worth asking at this stage whether the work involves basic research, applied research, or experimental development. Most Irish business R&D is experimental development, meaning you're using existing knowledge to develop or substantially improve a product, process, or system. Knowing which category your project sits in helps you shape how you document and describe it later.
Practical tip: Use a simple scoring matrix to evaluate projects. Include a column for "technical uncertainty"; if the team can't articulate clearly what they don't know yet, the project may not be qualifying R&D even if it's technically complex.
Stage 3: Structuring the development phase
Once a project is greenlit, the temptation is to start building immediately. Resist it, at least briefly. The development phase is where the bulk of your qualifying costs accumulate, and a small amount of upfront structure pays off significantly.
Before work begins in earnest, agree on how the team will track time, what constitutes a meaningful technical decision or design choice, and who is responsible for keeping records. You don't need a sophisticated system; a shared document or a column in your project management tool is enough. What you need is consistency.
Consider breaking the project into phases or sprints with defined technical goals. At the end of each phase, record what you set out to achieve, what the team actually encountered, and how you resolved it (or why you couldn't). This is the kind of narrative that makes a Revenue audit straightforward, not because you prepared it for the auditor, but because it reflects how the project actually unfolded.
Practical tip: At the end of each development sprint or milestone, hold a fifteen-minute retrospective focused specifically on technical challenges. What didn't work as expected? What did you have to figure out from scratch? Capture this in writing.
Stage 4: Prototyping and iteration
Prototyping is often the most clearly recognisable R&D activity, and it's where the most interesting documentation opportunities arise. Failed prototypes, unexpected results, and pivots in approach are evidence of genuine technical uncertainty, which is exactly what Revenue looks for.
The trap here is treating iteration as embarrassing or as a sign that the project isn't going well. In R&D terms, it's the opposite. A team that builds a prototype, discovers it doesn't behave as expected, and has to rethink their approach has demonstrated something important: this wasn't a routine engineering task.
Keep records of what each prototype was intended to test, what results you got, and what you decided to do next. If you changed direction mid-project, note why. These decisions are the technical story of your R&D, and a coherent technical story is the core of a robust claim.
Practical tip: When a prototype fails or produces unexpected results, write a brief note at the time. What were you testing? What happened? What does it tell you? Notes written in the moment are far more useful than recollections written six months later.
Stage 5: Preparing for launch
As a project matures, the work shifts from resolving technical uncertainty to bringing a product or process to market. Regulatory requirements, manufacturing scale-up, commercialisation planning, and marketing all come into focus. Most of this activity doesn't qualify for tax credits, and it's worth being clear about where the line sits.
The qualifying R&D work doesn't necessarily end at the prototype stage. If you're encountering new technical challenges during scale-up, or discovering that the product needs to be substantially redesigned to work at volume, that's still likely to qualify. The test is always the same: is there genuine scientific or technological uncertainty that your team is working to resolve?
This is also a good moment to consolidate your project records. Before the team moves fully into delivery mode, document what the R&D phase achieved, what uncertainties were resolved, and what (if anything) remains outstanding. It's much easier to do this while the work is fresh.
Practical tip: Nominate one person, ideally your technical lead or R&D manager, to produce a short, written summary of each completed project phase. A page is enough. This becomes the basis of your technical report without requiring anyone to reconstruct what happened from memory.
Stage 6: Launch and post-launch review
Launch is rarely the end of R&D activity. Products continue to be evaluated, improved, and adapted after they reach the market, and qualifying R&D can continue through these later stages if genuine technical uncertainty remains. The key is distinguishing between routine updates and genuine development work.
Post-launch, it's worth reviewing your documentation one more time with your accountant or R&D tax adviser before your claim deadline. Check that the technical narrative is coherent and complete, that costs are accurately allocated to qualifying projects, and that any team members who contributed to the R&D have been accounted for. This review is much quicker if you've been keeping records throughout.
Making the two processes work together
The businesses that find R&D claims most straightforward have made a habit of capturing decisions and outcomes as part of their normal project rhythm rather than scrambling to reconstruct them at year-end.
A few principles that help:
· Assign ownership early. Someone on the technical team should own project documentation. Consistency is what matters.
· Treat uncertainty as an asset. Every time your team encounters something they don't know how to solve yet, that's both a technical challenge and a documentation opportunity. Record it.
· Keep your accountant in the loop. Your accountant doesn't need to understand every technical detail, but they should know which projects are likely to qualify so they can track costs appropriately throughout the year. Bringing them in at year-end almost always means a scramble.
· Don't wait until your claim deadline. If you're preparing a claim for the first time, or haven't claimed in the past three years, Revenue requires a pre-filing notification at least 90 days before you submit. That's a good prompt to start reviewing your records.
Key takeaways
· A clear problem statement at the start of each project sets up both better R&D and a stronger technical narrative for your claim.
· Failed prototypes and unexpected results are valuable, not just for what they teach you technically, but as evidence of genuine uncertainty.
· Notes written in the moment are worth far more than reconstructions written later. Fifteen minutes at the end of each sprint compounds significantly over a year of R&D.
· Qualifying R&D doesn't always end at the prototype stage. If technical uncertainty persists into scale-up or post-launch development, that work may still qualify.
· A well-run R&D process and a well-prepared claim aren't two separate things. The records that make your R&D more rigorous are exactly the records Revenue wants to see.
If you'd like to understand how your R&D process maps to what Revenue expects, or you're ready to put together your first claim, get in touch and we'll walk you through it. You can also sign up to Tax Cloud and get started whenever you're ready.
