The software underpinning RDRelief was sold to one of the big-4 professional service firms in 2018. Consequently, the brand is no longer in operation.
R&D Tax Advisors are invited to find out more about the Inspired.tax claim preparation software.
Otherwise, please feel free to continue to browse this website for useful information regarding claiming R&D Tax Credits in the UK. However, beware that none of the information has been updated since 2018.
Software Development is one of the backbones of the R&D Tax Credits tax relief. In addition to specialist software development companies, most large (and many SME) companies also have a software development function, which in many cases are undertaking highly eligible R&D activities.
This is illustrated by that fact that our team have supported software based R&D Tax Credit claims for companies in the following industries: Finance (FinTech and Insurance), Retail, Utilities, Video Games, Wholesale, Logistics, Construction, Health, Agriculture, Legal & Professional Services, Real Estate, Telecoms, Digital Marketing, Sports Betting and Hospitality (to name a few).
The following briefing is provided within the RD Relief portal for each of your technical users that are assessing software development projects.
Assessing whether a software project qualifies for R&D Tax Credits can often be tricky, as the criteria the project need to adhere to (the R&D Tax Credits guidelines are known as the BEIS guidelines) are very generic and apply to many industries from pharmaceuticals to chemical engineering. This briefing will help put the guidelines into more context and help you to assess which projects will be eligible and which costs on the eligible projects will be claimable.
The Scientific or Technological Advance requires that the software development is moving forward from the current industry baseline. This means that the Advance must be relative to the industry not just that the company is doing something that they have not done before. Alternatively, the company can't just be applying Technology for which there is already a publicly available reference. However, if another company has developed a similar capability (e.g. low latency persistence for a trading framework) and you are seeking to also develop something similar, but you do so without their knowledge or capability, then your claim will be just as valid as theirs.
Furthermore, within Software Development, competent professionals often think in terms of business requirements (e.g. develop a new search function tailored to a certain data type). This, however, would not be ticking the Technological Advance box, as HMRC would view this as a business or functional rather than a Technological Advance. In many cases, there will be a Technological Advance behind the functional Advance, e.g. that the competent professionals needed to rewrite a certain legacy algorithm to be able to achieve higher 10% lower response times.
As an example, software development projects that seek to create new systems architectures, rewrite complex underlying data access layers or those that appreciably improve underlying algorithms within a codebase of a system, where there was no standard solution, would typically be seen as seeking a Technological Advance.
However, projects concerning the configuration of off-the-shelf solutions according to known principles, or projects that seek to improve the look and feel of user interfaces would not typically be seen as seeking a Technological Advance.
Technological Uncertainty within a software development project can be where the competent professional does not know whether the development of the software is Technologically feasible. However, this is not very common, as more frequently the Uncertainty concerns the best way to achieve the Advance in practice (as in software it is more common to know that an Advance would be achievable, but not how to actually achieve it).
There are many forms of Technological Uncertainty that occur on a software development project. For example, it may be uncertain whether or not it is even possible to achieve the non-functional requirements of the project, such as the performance and scalability.
There may be a number of different potential Technological options, such as architecture patterns, software languages, and design principles, and it may uncertain which, if any, of the options, would be most suitable to achieve the solution.
Alternatively, there may be systems Uncertainty, whereas it is uncertain how various APIs, frameworks, legacy packages can be integrated to form the new solution.
Software Development Activities that can be Included
The R&D guidelines state that an R&D Tax Credits projectstarts when work to overcome Technological Uncertainty commences and the project ends when work to resolve the Technological Uncertainty ceases.
The start of a software development project may involve, a business analyst identifying the requirements for the Technology.
This would be seen as identifying a business problem, rather than working to resolve Uncertainty and would typically be excluded from the claim. As soon as someone works to design the solution, and thus commences work to overcome Technological Uncertainty, then the R&D claim period would start.
The qualifying activities on a software project would typically include architecture, development, project management, testing, setup of development and test environments - where these are required to overcome and verify that the Technological Uncertainty has been resolved.
General people management, support of live environments, simple bug fixes (and routine maintenance), documentation for users (rather than core project technical documentation) are examples of activities that are not typically contributing to the resolution of Technological Uncertainty. Hence these should typically be excluded from a claim.