What Qualifies as R&D Under UAE Tax Law

The Problem with R&D Claims

Most companies approaching R&D tax incentives make the same mistake: they start by looking at what they spent money on, then try to justify why it counts as R&D. This is backwards. It leads to weak claims, rejected applications, and in some cases, penalties for overclaiming.

The right approach starts with understanding what R&D actually means under the law. Not what it means colloquially, not what your marketing team calls innovation, but the specific technical definition that tax authorities use worldwide.

That definition comes from the OECD Frascati Manual, and the UAE has adopted it wholesale.

Why the Frascati Manual Matters

The Frascati Manual isn't new. First published in 1963, it's been the international standard for measuring R&D activity for over sixty years. When the UAE Ministry of Finance designed the R&D tax incentive, they didn't reinvent the wheel. They adopted Frascati criteria directly.

This matters for two reasons. First, it means there's substantial international precedent for what does and doesn't qualify. Tax authorities in the UK, Australia, Canada, and dozens of other countries use the same framework. The body of case law and guidance is extensive. Second, it means the UAE is unlikely to accept creative interpretations that wouldn't fly elsewhere.

The Frascati Manual defines R&D through five criteria. All five must be present for an activity to qualify.

The Five Criteria, Examined

Novelty: More Than Just New to You

The novelty requirement trips up more companies than any other. The standard is not whether something is new to the world. It's whether your work aims to develop new knowledge or apply existing knowledge in a new way.

The subtlety here is important. You don't need to be inventing something that's never existed anywhere. But you do need to be doing something that requires you to figure things out, not just implement known solutions.

Consider two scenarios. A company builds a standard e-commerce platform using React and a typical backend stack. They're building something new to them, but they're following established patterns with known outcomes. This isn't novel under Frascati.

Now consider a company building a recommendation engine for a niche market where existing solutions don't work well. They need to develop their own approach because off-the-shelf algorithms perform poorly on their data. The outcome is uncertain. They're creating knowledge that didn't exist before, even if only within their organization. This is novel.

The practical test: if you could have outsourced this work to any competent contractor who would have known exactly how to approach it, it probably lacks novelty. If you had to figure things out yourself because no one else had solved this particular problem, you're in better territory.

Creativity: Original Thought Required

Creativity in the Frascati sense isn't about artistic expression. It's about original thinking applied to technical problems.

The distinction matters because much technical work is skilled but not creative. A senior engineer configuring a complex system is doing difficult work that requires expertise. But if they're applying established methods to achieve predictable outcomes, there's no creativity in the Frascati sense.

Creative R&D involves coming up with approaches that didn't exist before. It might mean combining techniques in novel ways, developing new methods to address specific constraints, or finding original solutions to problems that standard approaches can't solve.

One useful heuristic: did you try multiple approaches because you weren't sure which would work? Did you develop something that you couldn't have fully specified at the outset? Did the solution emerge through a process of experimentation rather than implementation? If yes, creativity was likely present.

Uncertainty: The Core of R&D

Technical uncertainty is the heart of R&D. Without it, you're just doing engineering.

But uncertainty is frequently misunderstood. The uncertainty must be technical or scientific, not commercial or managerial. Not knowing if a project will be profitable isn't uncertainty that qualifies. Not knowing if customers will adopt a product isn't qualifying uncertainty. Not knowing if you'll finish on schedule isn't qualifying uncertainty.

Qualifying uncertainty sounds like this: We don't know if this approach will achieve the accuracy we need. We don't know if this architecture can handle the load requirements. We don't know if this material will perform under these conditions. We don't know if this algorithm will converge.

The uncertainty must exist at the project's outset and must be resolvable only through R&D activities. If the answer could have been found by consulting an expert or reading documentation, the uncertainty wasn't sufficient.

This criterion eliminates most routine software development. Building features with established frameworks, integrating systems using documented APIs, scaling applications using known patterns, all of this involves challenges, but not technical uncertainty in the Frascati sense. You know the approaches will work; the questions are about time and resources, not feasibility.

Systematic: Documentation Matters

R&D must be conducted systematically. This means planned activities with proper records.

The good news is that this doesn't require academic-style documentation. You don't need research papers or formal protocols. What you need is evidence that work was conducted in an organized manner with records of what you did and what you learned.

In practice, this means:

• Project descriptions that explain what problem you were trying to solve. Not marketing language about innovation, but technical descriptions of the challenge.
• Records of approaches tried, including failures. Failed experiments are valuable evidence because they demonstrate genuine uncertainty and systematic investigation.
• Documentation of results and conclusions. What did you learn? Did the approach work? If not, why not?
• Time records showing who worked on what. You'll need to substantiate the costs you're claiming, and that requires knowing how much time people spent on qualifying activities.

Many companies already have this documentation in their issue trackers, code repositories, and project management tools. The task is often organizing existing records rather than creating new ones.

Transferable: Knowledge That Could Be Shared

The final criterion requires that results be potentially transferable or reproducible. This doesn't mean you must publish your findings or share them with anyone. It means the work must produce knowledge that could, in principle, be communicated to others.

This criterion excludes work that's purely intuitive or that can't be articulated. If your engineer solved a problem but can't explain how, that's not R&D. If the solution depended entirely on one person's tacit knowledge and couldn't be documented or reproduced by others, it doesn't qualify.

In practice, most legitimate R&D meets this criterion naturally. If you conducted systematic work to address technical uncertainty, you can generally document what you did and what you learned.

What Gets Excluded

The Frascati Manual explicitly excludes several categories of activity. Understanding these exclusions prevents wasted effort on ineligible claims.

Routine engineering doesn't qualify, even when technically sophisticated. Building systems using established methods, maintaining existing products, and implementing standard solutions all fall outside R&D.

Quality control and standard testing are excluded. Running test suites, performing QA, and validating that systems meet specifications isn't R&D. Exception: developing new testing methodologies might qualify if it involves genuine technical uncertainty.

Market research and business analysis never qualify, regardless of technical sophistication. Understanding customer needs, analyzing market data, and validating product-market fit are business activities.

Legal and administrative work is excluded, including patent applications, regulatory compliance, and contract negotiation. These might support R&D but aren't R&D themselves.

Aesthetic and style changes don't qualify. Redesigning a user interface, updating visual design, and improving user experience through design changes aren't R&D unless they involve solving technical problems with uncertain solutions.

Software: The Complicated Case

Software development occupies a grey zone that causes endless confusion. Most software development doesn't qualify as R&D. But some absolutely does, and software companies that understand the distinction can make substantial claims.

The question isn't whether you're writing code. It's whether that code development involves technical uncertainty that requires systematic investigation to resolve.

Building a web application with established frameworks isn't R&D. You might face challenges, but they're engineering challenges with known solutions. The uncertainty is about time and resources, not technical feasibility.

Developing new algorithms because existing approaches don't work for your problem likely is R&D. If you need to create new methods because standard techniques fail, you're doing research.

The line often falls at the algorithm level. Using existing algorithms to build applications isn't R&D. Developing or significantly adapting algorithms to solve problems where no adequate solution exists can be R&D.

Some examples that typically qualify:

• Machine learning work where you develop new model architectures, training approaches, or applications for domains where existing models perform poorly.
• Performance engineering where standard optimization techniques are insufficient and you need to develop new approaches.
• Systems that operate under constraints where established architectures don't work, requiring novel designs.
• Security research developing new protections against emerging threats, not implementing existing security measures.

Examples that typically don't qualify:

• Building applications using standard frameworks, even complex ones.
• Integrating systems using documented APIs.
• Scaling applications using known patterns.
• Implementing features with established approaches.

Preparing Your Claim

If you believe your work qualifies, start documenting now. Don't wait until you're preparing the claim to reconstruct what happened.

For each potential R&D project, maintain ongoing records of:

• The technical problem you're addressing. Be specific about what challenge you're trying to solve.
• Why existing solutions are inadequate. What did you try that didn't work? Why did you need to develop something new?
• The approaches you investigated. What methods did you consider? What did you try? What were the results?
• The uncertainty you faced. What didn't you know at the outset? What questions were you trying to answer?
• What you learned. Whether the project succeeded or failed, what knowledge did you generate?

This documentation serves two purposes. First, it forces clarity about whether work actually qualifies. If you struggle to articulate the technical uncertainty, that's a signal. Second, it provides the evidence you'll need to support your claim.

The Stakes

The UAE R&D tax incentive offers 30-50% back on qualifying expenditure. For companies with genuine R&D activities, that's a significant benefit. But the incentive exists to encourage real research and development, not to subsidize routine business activities.

Claims that stretch the definition invite scrutiny. The Federal Tax Authority will examine claims, and companies that overclaim risk penalties beyond just denied deductions. The reputational cost of a rejected claim matters too.

The right approach is honest self-assessment using Frascati criteria. Some of your work will qualify. Much of it probably won't. Claiming what legitimately qualifies, with proper documentation, is both more sustainable and more likely to succeed than aggressive claims built on wishful thinking.

Related Articles