Knowledge hub > Spotlight on software considerations in R&D
Reviewed by Clive Flood, Chief Operating Officer | June 2023.
Distinguishing between routine software development and compliant R&D activities 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 software development can’t qualify as it is not ‘white coat’ stuff… both scenarios are of course incorrect.
Having prepared a large number of software development R&D tax 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 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 solutions or technologies. 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 is the advance being sought, the technological uncertainty around the project, and the boundaries of R&D, specifically:
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 matters is the technological input, rather than the commercial output, so we’d consider the following:
R&D begins when work to resolve the scientific or technological uncertainty starts, and ends when that uncertainty is resolved, or when work to resolve it ceases.
So, bearing all this in mind, common features in a software project are:
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.
