R&D Tax Credits - Qualifying Activities in Software Development

R&D tax credits are a government incentive designed to incentivise UK companies to invest in innovation.

Your company may have identified that you meet the criteria for a qualifying project, but it’s important to consider that not all of the work undertaken as part of that project will be eligible for inclusion as part of the R&D tax credit claim.

In order to qualify for R&D tax credits, there are several boundaries that must be applied to distinguish those activities that contribute to the development of technological solutions from wider commercial activities.

What are qualifying activities in R&D?

Qualifying activities are essentially all of the undertakings that contribute to resolving the technological uncertainties that may be encountered when seeking to achieve scientific or technological advances in your project.

The activities may directly contribute to the problem-solving work e.g. writing scripts for tools/routines/integrations; or indirectly contribute to the problem-solving work e.g. training required to gain a skill set to support an R&D project. 

Furthermore, the activities do not need to be R&D in nature in their own right; administering programs of testing, for example, or building certain components of a system that is known but are required to support or facilitate work on areas of scientific or technological changes and growth.

Qualifying project versus qualifying activities

A project is defined by Oxford Dictionary as “a planned piece of work that is designed to find information about something, to produce something new, or to improve something existing.”

It is important that a business takes great care when defining a project for an R&D tax claim. It is crucial to focus on the underlying technical goals the business aspires to achieve that underpin the wider commercial aims. 

At this point, businesses should evaluate whether each technical goal should be put forward to HMRC as an R&D project in its own right; or whether they form a collection of sub-projects that collaboratively contribute to an overarching purpose or outcome from a scientific or technology perspective. This would mean that the project is defined at a higher level to cover all of the technical goals. 

As mentioned, qualifying activities are all actions, tasks, programs, events, meetings etc. that together facilitate the evolution of the R&D project. Whilst there is always a commercial justification for embarking on a project in business, qualifying R&D projects are borne out of problems or unavailability of solutions in achieving the commercial goals. R&D projects are therefore defined differently and will have a specific purpose centred around growth in knowledge and/or capabilities within a field of science or technology.

Why is it so important to determine qualifying activities?

It is vital that businesses understand how to determine qualifying activities as ultimately they form the basis to identify and calculate qualifying expenditure. 

Qualifying expenditure determines the ultimate value of your R&D tax relief claim that is incorporated into the company tax computation to deliver corporation tax savings (R&D tax relief) and/or a payable cash credit (R&D tax credit). A number of conditions apply to the calculation of qualifying expenditure.

The biggest cost category within a software development claim is by far attributable to the individuals doing the work – this can be either direct in-house resource (staffing costs) or externally bought in resource (sub-contractors/agencies/borrowing from group companies). 

Properly understanding and applying qualifying activities boundaries is used as a basis for the analysis of qualifying time spent by personnel working on the R&D project. The qualifying time analyses are ultimately converted to a percentage to allocate salary or invoiced costs (depending on the cost category) to each qualifying project based on the involvement of people in each of the qualifying activities.

So, you’ll see that misunderstandings over the boundaries of what qualifies, or a lack of confidence in making the right decisions in this regard, means that companies will either miss out on the value they are entitled to, or potentially overclaim! 

Businesses must be mindful that working out what’s in or out when it comes to your R&D claim is not easy, and this is especially so when it comes to software development. 

How to identify qualifying activities in software development

Software development sets in motion an abundance of unknowns as complexities emerge and multiply across schedules of works. 

The nuances and multidimensional interdependencies of activities performed by all contributors within a software development project life cycle makes it extremely challenging for companies to identify and segment with clarity and accuracy what is and isn’t eligible for R&D tax relief.

The below diagram portrays a high-level overview of the key phases in a typical project lifecycle. This is used to draw out some of the key aspects to consider when analysing the qualifying activities and associated time spent on these by the people involved in the R&D project.

Every software development company runs a slightly different collection of activities – some more granular, some made up of shorter sprints, or involvement of different contributors at different stages. However, the key considerations remain the same.

Based on the diagram above, the phases are considered below to provide guidance around what kind of activities are eligible for inclusion and which activities should be excluded. Where activities are intertwined, a judgement call must be made by the right person within your organisation (with support from others doing the work where necessary) to allocate time on a just and reasonable basis).

The right person will be a “competent professional”, meaning they have the relevant technical credentials and involvement in the project work to make robust judgement when it comes to qualifying activities and time involvement.

It is worth noting the importance of getting the right person within your organisation on board to liaise with your R&D tax adviser throughout the entire process of technical information gathering and collaborating on how to structure the qualifying time analysis exercise. 

Larger organisations have many layers of project managers, each with a slightly different role in driving aspects of the interconnected development components forward. Choose the project manager with the best balance of oversight across all roles (vertically and horizontally, internal/external resource working relationships), and in-depth knowledge of contributor involvement as this will produce the most robust and accurate outcomes from this important exercise. 

Concept

Include: 

• The setting of the technological requirements underpinning the commercial goals for functionality and features that are not readily available or capable of being put in place "as is” without further engineering to craft a viable solution.
• Scoping of the project in terms of identifying the gaps between available or emerging technologies and potential development options to evolve or iterate technical capabilities from where they are at, to where you want to get to. 
• This could be influenced by legacy components to be integrated with, switched between or ran alongside. 
• The emergence of new coding languages or modern platforms that are fundamentally different could also feature where there is a lack of publicly available knowledge or experience in how to incorporate/migrate to these or there are significant incompatibilities to be overcome. 

Exclude:

• Business requirement gathering by subject matter experts and business analysts. 
• Researching existing technologies/software components for potential compatibilities at the outset where the intention is to use them “as is”.
• Market research in terms of customer behaviour. 
• Design aesthetics to the extent these will not impact on the underlying technical solutions to be developed i.e. where new capabilities are not required to deliver rendering aspects, page/visualisation layouts for data metrics etc.
• Design aesthetics to the extent these will not impact on the underlying technical solutions to be developed i.e. where new capabilities are not required to deliver rendering aspects, page/visualisation layouts for data metrics etc.

Inception

Include:

• Designing the project architecture, resource planning, setting the development road map. 
• Liaison with key contributors to input into the technical areas of development that will deliver the sought-after growth around tangible or intangible outcomes such as functionality, performance, user experience, user interface, data handling, legal, security, third party specialists to support in-house resource etc. Note it is the technical changes to leverage the outcomes that counts, not the outcomes in and of themselves.
• Development of tooling or programmes to aid with development/testing.

Exclude:

• Activities that are too far removed from supporting the technical work to seek out new or improved knowledge/capabilities required for the development of the technical solutions that are currently unresolved in your industry. 

Iteration

Include: 

• Attempts to turn the designs/concept/interdependencies into viable and functional code without adverse consequences.
• This is your series of sprints to focus on using technologies and applying technological principles to make technological changes. 
• It’s about the pain points and frustrations of the challenges you face in seeking a solution where there are no readily available methods/results/clarifications/tried and trodden paths.
• It is all the activities that collectively contribute to solving that challenge, whether or not they are R&D in their own right. 
• The key thing is complexity due to technicalities in coding failures not complexity attributable to volumes and variables to "manage or incorporate” alone. You must be able to distinguish between something being challenging simply because there are a large number of variables, interdependencies or components that takes time to knit together, but where you are using known approaches; compared to scale and volume being the reason giving rise to new or improved knowledge and capabilities technically through the creation of progressive protocols/tools/sophistication in processing etc.

Exclude:

• Routine methods, minor bug fixing, tweaks to system components/code. 
• Plug and play integrations with no challenges around data flows/end-pointss/extending the third-party software.
• Using only inherent knowledge and capabilities that are established and known in your industry to attain the deliverable.

Testing

Include:

• Inevitably this will take place throughout the entirety of the sprint phases/iterations. 
• It is the purpose that needs to be considered. Testing needs to feed back into the development work, not validate that it definitely works properly once the technological uncertainties have been resolved, include: 

Non-functional testing that happens throughout the development such as unit testing on software code, or early development integration tests in development environments feeding back into solving technological uncertainties. 

System integration testing as long as it is not solely confirmatory.

Exclude:

• Non-functional testing at later stages of R&D performed for confirmatory purposes that does not feed back into the design or development iterations. 
• Functional testing such as user acceptance testing which focuses on testing the functionality rather than underlying issues which are resolved, or focus on the look and feel of the solution which do not contribute to R&D.

Deployment

Exclude:

• This phase is non-qualifying as this happens at the point the software/system is transferred to the production environment after uncertainties have been resolved. 
• If a problem arises and the project goes back into development, then you will be back into the iteration and testing cycles.
• Therefore, exclude deployment to the production environment, routine bug fixing, and tweaks post go live.

A final take away

A general thought to keep in mind when considering all the above for your R&D tax claim: is there significant system uncertainty that cannot be solved without meaningful improvements realised through technological changes? 

This means that if you know the system components, you know how to put them together and are certain of the outcome - then this is not R&D. However, if you know the components, and how to put them together but are not certain of the outcome and other approaches/methods etc. are likely required, then depending on the significance of what you do in your work, this is where and how you could be advancing knowledge and capabilities. 

It is not just about creating new components in system building, it is also about how to make things work together, synergistically. The outcome, or the overarching system created by collectively bringing all aspects together (integrations with endpoints, reach, scale, tools, processing effectiveness and efficiencies, logic, speeds, error mitigation etc. etc.) is greater than any single capability alone.

The technology stacks considered together with how coding languages are adopted/applied, and how the technological aspects that support the functionality and features sought are used, evolved, and customised to become better than their "out-of-the-box" versions is what counts. 

Compatibility with wider legacy systems and the transition to modern ways of doing things must be challenging technically speaking, for example you cannot simply switch over without establishing new knowledge and making significant technological changes to bridge gaps and extend from there. It's about substantially enabling technologies that support the outcomes sought working together to create something that goes beyond existing capabilities. 

As noted previously, complexity arising purely because of scale making things time consuming will not be R&D if all work can be done within baseline capabilities of the technologies employed. When referring to complexity, the guidelines for R&D mean something is technically challenging such that the problem-solving work forges new or improved technical knowledge and capabilities by reference to your industry as a whole - not just your company’s state of knowledge. 

As a business you must be able to benchmark the technology gaps and clearly explain this in a way a lay person can understand, showcasing how difficult it is to achieve in practice. Things advance quickly in IT and software development so be sure to add context to reassure HMRC why the solution was not available when you did your work.

Supporting you with your R&D claim

If a lack of understanding means that you are not confident in making an R&D tax relief/credit claim, then you could be leaving money on the table that is available to support your development work. 

If you’d like to discuss a potential R&D project, book a call to explore your eligibility and start your tax claim journey.