Emirates R&D Council Pre-Approval: The Complete Walkthrough

The Gatekeeper You Cannot Skip

Cabinet Decision No. 215 of 2025 created the UAE R&D tax credit. It also created a mandatory gate: the Emirates R&D Council must pre-approve your R&D projects before you can claim any credit against them.

Article 3.1.b is explicit. A Qualifying Person must "obtain pre-approval from the Emirates R&D Council for each R&D Project for which the Tax Credit is claimed." There is no alternative path. There is no workaround. There is no grandfathering for projects that started before the Council existed. If the Council has not approved your project, the Federal Tax Authority will not allow the credit against it, full stop.

For many companies, the Council application is the part of the process they least understand. This walkthrough addresses that gap.

What the Council Actually Reviews

The Emirates R&D Council is a technical review body, not a tax authority. Its job is to answer one question about each project you submit: does this actually qualify as research and experimental development under the Frascati framework.

That question breaks down into five sub-questions, which map to the five Frascati criteria:

1. Novelty. Is the work aimed at new knowledge, new products, new processes, or significant improvements that are not obvious to a competent professional in the field?

1. Creativity. Does the work involve original concepts and methods, as opposed to routine application of existing techniques?

1. Uncertainty. At the start of the project, was the outcome genuinely unknown? Was there a real risk the work would fail or produce unexpected results?

1. Systematic investigation. Was the work planned, budgeted, documented, and executed according to a clear methodology?

1. Transferability or reproducibility. Could the findings be reproduced by another competent team working from the same documentation?

The Council's review is a technical review. It is looking for projects where a reasonable expert would agree that genuine scientific or engineering uncertainty was resolved through systematic investigation. Applications written in marketing language, or applications where the technical uncertainty is implied but not stated, tend to fare poorly in any Frascati-aligned review.

What the Council Does Not Care About

Understanding what the Council reviews is useful. Understanding what the Council does not review is equally useful.

The Council does not evaluate the financial details of your claim. It does not check whether your GL categorisation is correct, whether your staff register is complete, whether your reconciliation to audited financials is clean, or whether your senior management declaration is signed. All of that is the Federal Tax Authority's job and happens in the second phase.

The Council's job is purely technical: is this actually R&D. Your Council application should therefore focus almost entirely on the technical story of each project. Keep the financial information to what the Council specifically asks for, which is usually a high-level indicative expenditure breakdown.

What Your Application Must Contain

The Council expects a structured application with the following sections:

1. Entity Information

Legal name of the entity, tax registration number, trade licence number, incorporation date, registered address, and the name and role of an authorised contact person for the application. If the entity is based in a Free Zone, specify which one and confirm the tax status (9% taxable, Top-up Tax subject, or 0% QFZP). Note that QFZPs taxed at 0% cannot claim the credit, so the Council will scrutinise this carefully.

2. Project List

A single list of all projects you intend to claim under the application. Each project should have a unique identifier, a name, a start and end date, and a one-paragraph summary. Do not combine multiple distinct research activities into a single project. Do not split a single research activity into multiple projects to game headcount thresholds. Both practices are likely to attract scrutiny under any robust Frascati-aligned review.

3. Project Narrative (five sections per project)

This is the heart of the application. For each project, you produce a structured narrative in five sections. Each section should be at least 100 words of substantive technical content. The five sections are:

Section 1: Technical Baseline. What was the state of the art when the project began? What existing products, tools, or bodies of knowledge did the team start from? What could competent professionals in the field do before this work started, and what could they not do?

Section 2: Technical Uncertainty. What specifically was unknown at the start? Why was it unknown? What made the outcome unpredictable? Why would routine engineering not have been sufficient? This section is where most applications are weakest. Avoid phrases like "it was a challenge" or "we needed to innovate." Instead, describe the specific scientific or engineering questions that did not have predictable answers.

Section 3: Hypothesis and Approach. What did the team believe might work? What experimental, investigative, or engineering methodology did they use to test that hypothesis? Include specific techniques, tools, or frameworks. If you used a pre-existing method, explain why it was applied to a novel context.

Section 4: Systematic Investigation. How was the work organised? Was there a written plan or proposal at the start? Were milestones or checkpoints defined? Who reviewed the work as it progressed? How was progress documented? Were decisions to pivot or abandon directions recorded? The Council is looking for evidence that this was planned, documented, professional R&D, not ad hoc experimentation.

Section 5: Outcomes and Transferability. What was the result? Did the work succeed, partially succeed, or fail in instructive ways? What was learned? Could another competent team reproduce the findings from the documentation? Negative results are valuable here. A project that ended with "we tried this approach and it did not work, so we documented the failure mode" is legitimate R&D.

4. Competent Professional Dossier

For each project, you must identify a competent professional who is qualified to attest that the work was R&D. This person is typically the technical lead, senior engineer, research scientist, or head of the team that executed the project.

The dossier for each competent professional contains:

• Full name and role in the entity
• Qualifications (degrees, professional certifications, years of relevant experience)
• Prior R&D experience (major projects, publications if applicable, patents if applicable)
• A signed attestation statement confirming that the professional has the expertise to evaluate the R&D nature of the project and confirms the project meets the Frascati criteria

If the person you name is in an administrative, sales, or non-technical role, their attestation is unlikely to be credible. The competent professional should have demonstrable technical expertise in the field of the project and should be willing to sign a formal attestation. Specific Council expectations on qualifications and experience should be confirmed against the Council's published guidance.

5. Indicative Expenditure Breakdown

A rough breakdown of expected qualifying expenditure by project and by Article 5 category. This is not the final claim number, it is an indicative figure to help the Council understand the scale of each project. Final numbers come in the FTA filing.

6. Supporting Documents

The Council will ask for, at minimum:

• Trade licence
• Memorandum of association or equivalent corporate constitution
• Most recent audited financial statements
• Evidence of prior R&D activity if the entity has claimed before in another jurisdiction
• For Free Zone entities, confirmation of tax status

How the Application is Reviewed

Once submitted, the Council will typically review the application in phases. A completeness check confirms that all required sections and supporting documents are present. A substantive technical review evaluates each project narrative against the Frascati criteria. For complex or novel research domains, the Council may request additional information. The Council then issues a decision per project.

Possible outcomes generally include: approved, approved with conditions, rejected, or approved in part. Applicants should prepare for the possibility of information requests and should respond promptly to any Council communication, because missed response windows can complicate or delay the decision.

Realistic Timelines

Do not plan on a short review. The Council's technical review is substantive. As the Council and its procedures are newly established under Cabinet Decision No. 215 of 2025 and Ministerial Decision No. 24 of 2026, published statistics on review turnaround are limited. Applicants should expect a meaningful review period of several weeks and should not assume a same-week turnaround.

Companies with multiple projects or novel research domains should plan on the longer end. Plan your Corporate Tax filing schedule accordingly, and build a buffer into your timeline for potential information requests.

Common Reasons for Rejection

The five most common failure modes we see in R&D tax credit applications globally, all of which apply to the UAE:

1. The narrative describes a product, not a research activity. "We built a new mobile app for our customers" is not R&D. "We investigated whether a novel client-side rendering approach could reduce latency by 40% under specific network conditions that existing frameworks do not handle" might be.

1. The technical uncertainty is implied but not stated. Vague phrases like "it was technically challenging" do not substitute for a clear statement of what was unknown and why.

1. The competent professional is under-qualified. A project lead with two years of experience attesting that complex software engineering qualifies as R&D will face scrutiny.

1. Routine work is miscategorised. Routine maintenance, bug fixes, customer-driven customisations, cosmetic updates, and commercial-driven feature requests are not R&D. Including them contaminates the application.

1. The application is all copy-paste. When five projects have identical-sounding narratives with different product names, reviewers notice. Each project needs its own specific technical story.

What to Do Before You Submit

Before you send the application to the Council, do an internal review as if you were the reviewer. Read each project narrative and ask yourself:

• Can I name the specific technical uncertainty in one sentence?
• Is the methodology described in enough detail that a competent professional could assess whether it was appropriate?
• Are the outcomes stated clearly, including any failures?
• Is the competent professional actually qualified to make the attestation?
• Does the project look like R&D, or does it look like product development with a research label?

If any answer is weak, fix it before submission. A Council rejection is not just a bad outcome for that project, it weakens the credibility of the rest of the application.

The Strategic Point

The Council pre-approval is not just a box to tick. It is the document that will protect your claim if the FTA audits you in years two through seven. An approved Council application, with a clear narrative and a credible competent professional dossier, is your first and best line of defence in any subsequent audit.

Treat the Council application as the most important piece of the claim, not an administrative nuisance. The quality of the narrative you submit now determines what happens when the FTA asks questions later.

Prepare carefully. Submit cleanly. The credit you get is only as defensible as the Council file that authorises it.

Related Articles