Boost your cashflow by claiming R&D Tax Credits

Tax Legislation defines Research and Development in Section 766 TCA 97 as follows

Research and development activities mean systematic, investigative or experimental activities in a field of science or technology, being one or more of the following—

(i)basic research, namely, experimental or theoretical work undertaken primarily to acquire new scientific or technical knowledge without a specific practical application in view,

(ii)applied research, namely, work undertaken in order to gain scientific or technical knowledge and directed towards a specific practical application, or

(iii)experimental development, namely, work undertaken which draws on scientific or technical knowledge or practical experience for the purpose of achieving technological advancement and which is directed at producing new, or improving existing, materials, products, devices, processes, systems or services including incremental improvements thereto: but activities will not be research and development activities unless they, (I)seek to achieve scientific or technological advancement, and (II)involve the resolution of scientific or technological uncertainty;

Revenue interprets legislation and issues guidance around what they feel is the appropriate classification of R&D, and additionally what costs, rules and regulations apply.  Revenue’s interpretation of R&D in the context of Software development is as follows. 

Revenue’s description of Software Development

The OECD Frascati Manual states “for software development to be classified as R&D its completion must be dependent on the development of a scientific and/or technical advance and the aim of the project must be the resolution of a scientific and/or technical uncertainty on a systematic basis.”

Advances and Resolution of Uncertainty: Software development is no different from any other industry in that it is essential that claimant companies keep aware of developments in their field to ensure that activity for which the credit is claimed is directed at genuine advances. 

Subject to that caveat, scientific or technological uncertainty may arise at various points throughout a development life-cycle including:

• Development of mathematical models or algorithms to achieve the desired functionality goal(s);
• Translating such models or algorithms into code and ensuring that the desired goal(s) can be achieved;
• Ensuring that the application/process/tool developed will continue to function in different scale environments;
• Ensuring that the application/process/tool developed will function across a range of platforms;
• Ensuring that the application/process/tool developed will integrate as intended with other applications/systems.

Within a typical software development cycle, there will also be features that do not constitute qualifying R&D activity such as:

• User acceptance testing designed to satisfy users as to the accuracy and completeness of the product rather than to test feasibility or capacity;
• Development work aimed at packaging a product for a market where no scientific or technological uncertainty exists; or Inclusion of features or functionality where no scientific or technological uncertainty exists.
• Undertaking routine analysis, copying, upgrading or adaptation of an existing product, process, service or material would not be considered to be R&D activities.

It is important for claimant companies to identify not only those developments that result from qualifying activity but also the phases of the software development life-cycle that are qualifying activities.

In Short – Yes, but not all development within an Agile development process can be claimed as R&D.

While software development methodologies continue to evolve and are often highly iterative in nature, they continue to contain certain key elements such as design, build and test. Qualifying activity must be systematic in nature as well as achieving advances.

Agile development methodologies such as Scrum and similar techniques, while not exhibiting the linear nature of a traditional software lifecycle, are systematic in nature.

In agile development methodologies, qualifying and non-qualifying activity may take place simultaneously in a manner that makes them more difficult to separate. In these circumstances, project managers should apportion the staffing and other costs associated with each element of development in a manner that appropriately reflects the balance of effort expended on qualifying and non-qualifying activity