Software R&D tax claims and the importance of the BEIS guidelines

As a little reminder to start the New Year and given the increased scrutiny of R&D tax relief claims by HMRC, we have put together a brief guide to help you ascertain whether a valid R&D tax credit claim for software development can be made.

The BEIS guidelines set out the requirements for R&D tax relief and we’ve intentionally used text excerpts from the BEIS guidelines in this article to provide as much clarity as possible. Many R&D advisers put their own spin on what constitutes qualifying R&D but this article quotes directly from the guidelines which HMRC use to determine if a project qualifies. 

Who can claim?

Software development usually takes place either because a company is developing software to sell or is building software to help their business run more efficiently. Companies will typically be undertaking qualifying R&D activities if they seek to overcome a technological uncertainty over the course of the project.

What is the key to making claim?

Development involving the use of existing technology with minimal improvements or technical challenges, would not qualify for R&D tax relief. Such work would include simple configurations, routine development work or straightforward integrations of off-the-shelf products. 

However, where businesses are creating, utilising, amalgamating or significantly extending technologies in an improved and innovative way, it will often mean qualifying R&D is taking place. A key question to the developers would be “is the company resolving software uncertainties and challenges that have not yet been overcome by a competent professional in the field?” 

The R&D tax relief scheme is very much geared around the technology on which the software is built, more than the actual commercial or end user features of the product. It is therefore important to demonstrate the complexity of the software build from a programmer’s perspective. For example, a slick end-user feature may be attractive from an aesthetic perspective, but if there was no complexity involved in its creation, its creation is unlikely to constitute qualifying R&D activity. Routine projects that do not require any advance in capability or the resolution of technical challenges are therefore not qualifying. 

Claims need to focus on the underlying technology utilised within the development of a product/process rather than just the product/process itself. This could be by developing a new, novel software application to include, for example, the development of machine learning algorithms to improve the speed and efficiency of a system. It might involve the optimisation, re-architecting, or integration of different technologies that did not already interoperate in order to provide a solution to a task which had no alternative. 

Have you read the BEIS guidelines? 

HMRC routinely challenge R&D tax relief claims on the assumption that the qualifying criteria for the relief have not been met. HMRC will also ask companies if they are familiar with the BEIS guidelines during an enquiry. It is therefore essential that all claimant companies understand what is qualifying R&D, as per the BEIS guidelines. 

The definition of qualifying research and development for software is summarised below. This information is taken from the BEIS guidelines which are outlined at HMRC’s R&D tax relief technical manual. Full details can be found here 

A summary of the definition of qualifying R&D in the BEIS guidelines

The words ‘research and development’ are frequently used in the software sector, and care should be taken not to assume that a commercial project fully aligns with the definition of R&D set out in the BEIS Guidelines.

Advance in Technology

An advance in science or technology means an advance in overall knowledge or capability in a field of science or technology, not a company’s own state of knowledge or capability alone. The advance may also be an appreciable improvement to an application of software provided these changes or adaptations to the scientific or technological characteristics would be generally acknowledged by a competent professional as a genuine non-trivial improvement.

The competent professional for the company’s R&D project should be able to explain how the company’s R&D project is new in, or is an appreciable improvement to, that field of science or technology relative to that which is available in the public domain.

It is the underlying technology in which an advance is made rather than the commercial output or outcome. For example, a project involving customisation of existing software which materially affects underlying science or technology can be R&D. However, it is unlikely that customisation such as configuring existing software to a company’s own requirements would be qualifying R&D because it is generally already within the capability of the existing software. 

Combining standard technologies, such as integrating platforms, can be R&D if a competent professional in the field can’t readily deduce how the separate components should be combined to have the intended function. The implementation of a novel algorithm that represents a significant increase in overall capability in the area of software can also be R&D. 

Technological Uncertainties

HMRC require companies to demonstrate how the improvements to the software were made, the difficulties they faced and how the problems were overcome. In addition, why the solutions sought were not readily available is also a key consideration. HMRC look at the degree of complexity and problem solving involved in writing software. For example, can the answer be found within open publications, meaning that any reasonably competent developer would resolve the issues without much difficulty?  

Many new products have software interfaces ready to use out of the box, but others require developers to update or redesign interfaces with more advanced technologies such as software-defined networking, automation and AI. It is the latter rather than the former which are more likely to involve qualifying R&D. 

Identifying the technological uncertainties of a project are crucial to understanding whether or not a project qualifies. Technological uncertainties are not simply ‘business as usual’ challenges that many software projects will involve. 

They must be uncertainties which call into question the technological feasibility of a project and they must not be something which a competent software professional could easily resolve. 

Examples of technological uncertainties could be:

  • Developing new or improved data architectures that cannot be achieved with readily deducible solutions, e.g. pushing beyond the boundaries of existing readily available database engines.
  • Extending software frameworks (e.g. software development kits, or software libraries) beyond their original design, where knowledge how to extend these was not available or readily deducible at the time.
  • Attempting to partially or fully solve a technological uncertainty that is documented as a known subject of research by computer scientists (e.g. there are relevant and contemporaneous research papers on that specific scientific or technological issue).

The Boundaries of R&D

Most projects for the development of a commercial product will go further than resolving technological uncertainties and so will not qualify as R&D in their entirety so it is important to identify the projects within the commercial project that do qualify as R&D. 

R&D begins when work to resolve the scientific or technological uncertainty starts and ends when that uncertainty is resolved or work to resolve it ceases. The company should identify the boundaries of the R&D project which should encompass all activities that collectively serve to resolve scientific or technological uncertainty associated with achieving the advance. Software development project(s) may therefore need to be identified as smaller R&D projects within a larger commercial project. 

Typical examples of qualifying software development

  • Bringing large cumbersome, legacy systems up to date where there is little to no documentation available.
  • Implementing complex, bespoke functionality into off the shelf technology.
  • Integrating multiple disparate systems to operate seamlessly and efficiently.
  • Developing a platform that enables data to be automatically extracted from several sites and analysed using intelligent algorithms.
  • Development of dynamic pricing functions which links price to demand.
  • Integrating legacy systems with modern technologies through the development of complex algorithms.
  • Overcoming issues of compatibility, stability, scalability, security and interoperability where routine or conventional methodology cannot be followed.
  • Complex communications e.g. combining mobile and static technologies, structured and non-structured data, multiple operating systems etc.
  • Use of cutting-edge technologies with minimal amounts of history or documentation, often meaning there are no precedents to work from and iterative development must take place.
  • The use of machine learning algorithms to improve upon existing processes.
  • The development of blockchain technology to improve security and speed of transactions.
  • Developing Internet of Things platforms and utilising this data in a complex manner.
  • Implementation of AI into wider systems to better understand or complete tasks. 

Typical examples of non-qualifying projects

  • The handling of interactions with users. This covers areas such as development of data entry procedures and user interfaces.
  • The visual presentation of information to users.
  • Using standard methods of encryption, security verification and data integrity testing.
  • Creation of websites or software using tools designed for that purpose.
  • Routine adaptation of an existing product or process.
  • Assembling components of a program to an established pattern or using routine methods for doing so is not R&D.
  • Tweaking a system to make minor changes to fit a business requirement.

Why use a specialist?

Many potential software R&D tax credit claims are not even attempted, because companies are understandably reluctant to spend significant amounts of time and money with no guarantee of success.  In addition, companies can’t always expect their accountant to have the specialist technical knowledge required to draw the boundaries between R&D and non-R&D activity. 

Companies that do submit R&D tax credit claims themselves, or use a non-specialist R&D adviser, often do not identify all their qualifying expenditure. At the other end of the spectrum, non-qualifying projects (or aspects of a project) are often claimed, resulting in lengthy HMRC enquiries.

R&D related tax enquiries are on the increase, particularly where claims are based on software development projects. It’s therefore essential that claims are accurately prepared to minimise the risk of enquiries and potential tax penalties. 


We have been making claims in this area for years and have recently enlisted specialist technical talent in this area. James Smith joined the team in 2021 as one of our expert software sector specialists. James has a degree in Computer Science and has programmed in several software languages. He has already provided invaluable advice to many YesTax clients. 

Maybe now is the time to review your current claims process.

YesTax. Positively Better.