Spotlight on software considerations in R&D

Defining software development is one of the most challenging areas for R&D advisers and HMRC alike.

The question that needs to be addressed is: “What are the eligible R&D activities that fall within the specific R&D legislation?”

Misunderstanding the definition of “eligible R&D activities” means getting the answer wrong, with the result that some companies either underclaim or overclaim for R&D.

Some companies think that all software development is R&D, whilst others think that the software development can’t qualify as it is not ‘white coat’ stuff… both scenarios are of course incorrect.

Because of this confusion, HMRC recently created a subcommittee to carry out a detailed review of the guidance on software development. As a member of the main HMRC R&D Consultative Committee, we strongly believe that this is a crucial step.

Having prepared a large number of successful software development R&D claims for our clients – ranging from FTSE 250 companies with turnovers over £3700m to new start-up companies with little turnover - we know from experience that a clear and full understanding of the R&D legislation and software development is key to making a successful claim. 

Many of our software development R&D claims are for companies for whom software development is not their main trade. However, they need to develop new and improved data architectures that can’t be achieved with readily deducible solutions – they’re often pushing beyond the boundaries of existing readily available database engines. For the purposes of a claim, it doesn’t matter whether the software project is intended to result in a product to be used in-house, licensed or sold.

So, when determining whether a company qualifies for a claim, it’s not the type of business that’s important. In fact, all you need to consider when identifying any R&D project are the advance being sought, the technological uncertainty around the project, and the boundaries of R&D, specifically:

1. What advance in science or technology is this project seeking to achieve?

An advance means an advance in overall knowledge or capability, not a company’s own state of knowledge or capability alone.  The advance may be a genuinely appreciable improvement to an application of software, provided it’s not simply a trivial change.

       So the kind of questions we’d consider would be:

• What is the baseline in technology that any advance is being measure against? – i.e. what is the technology that is in existence at the time, rather than what is the commercial output
• What was the gap in technological knowledge or capability which made the R&D project necessary? – integrating platforms can qualify as R&D, while routine adaptation of an existing product or process does not
• What technological changes have been made in seeking a technological advance or attempted advance? – making an appreciable improvement to an existing process, material, device, product or service so it can be used in a new or appreciably improved way will qualify as R&D

2)  What are the scientific or technological uncertainties?

What matters is the technological input, rather than the commercial output, so we’d consider the following:

• Accurate identification of the challenges
• What was it about the technology/computer science that made it uncertain whether software could be made to do what the company wanted it to do? 

 3) Project boundaries

R&D begins when work to resolve the scientific or technological uncertainly starts, and ends when that uncertainty is resolve, or when work to resolve it ceases. 

So, bearing all this in mind, common features in a software project are:

• Requirement-gathering for technological uncertainties: technical requirement analysis, where specific technological questions are related to resolving scientific or technological uncertainties, would qualify for R&D.

• Planning: some planning activities, such as planning for the R&D elements of the project, qualify as R&D; however, planning associated with non-R&D elements of the project such as financial, marketing and legal aspects do not

• Analysis, design and development: the technical analysis, design, development and testing activities needed to directly resolve the scientific or technological uncertainties are R&D and may be included; however analysis, design, development and testing that do not contribute to resolving scientific or technical uncertainties are not R&D and need to be excluded

• Testing: to be included in an R&D project the purpose of the testing work should be to feed back into the development - not to validate that it definitely works properly once the technological uncertainties have been resolved  

• Non-functional testing: when non-functional tests are performed for confirmatory reasons and do not feedback to the design or development stages of R&D, these should be excluded

• Functional testing: types of testing which focus on testing the functionality (rather than underlying issues which are resolved) and which do not contribute to R&D should be excluded

• Deployment: generally, after the uncertainty is resolved, any transfer of the software to production should be excluded

• Maintenance: minor fault-fixing where no technological uncertainties arise are not R&D and therefore should be excluded; however, during maintenance new problems may emerge that may require R&D to recommence through the life-cycle stages of the software development

Some examples of qualifying R&D software development:

• Extending software frameworks (e.g. software development kits, or software libraries) beyond their original design, where knowledge of 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).

Business requirement-gathering or routine analysis of commercial requirements does not qualify as R&D. This is because routine adaptation of existing off-the-shelf products, and assembling software components to an established pattern, is not considered to be an advance.

Powered by Froala Editor