R&D Tax Credits for Wholesale

Wholesale can be overlooked for R&D Tax Credits when companies regard the work as BAU (business as usual). Typically this may be when the Technological details of Wholesale projects are not visible outside of the core R&D teams.

We have found that often Wholesalers are developing new software and integrating their existing (often legacy) software with third-party technologies. Where this is an extension to the Technology itself (rather than a configuration of software to business requirements), such projects frequently meet the R&D Tax Relief eligibility criteria.

For a Wholesale software development project to qualify as R&D for tax purposes, it must adhere to the specific eligibility guidelines that have been defined by the UK Department for Business, Energy & Industrial Strategy (BEIS).

The eligibility criteria apply to all fields of Science and Technology (so are quite general, rather than being specifically targeted at Wholesale, or even just software development, R&D).

Once you are familiar with the basis of the requirements, this article will put them into more content for Wholesale R&D claims.

The first requirement is that the project must seek to achieve an Advance in Science or Technology in the field. The wholesale is a business 'field', rather than a 'Technological' one, meaning that Wholesale Technology needs to be advancing software. Advancing 'Software' in general sounds like a high-hurdle at first thought, but when you get into the details, it is most often a lower hurdle to satisfy than is first expected. It is worth mentioning that this is often a source of problems for a large number of wholesale claims (as they often articulate the functional rather than Technological aspects of the project).

It could be that the company is developing a new fleet management integration to support logistics. If this is merely configuring two third-party systems to 'talk' to each other, then it is unlikely to qualify. However, where the company is developing new algorithms and ETL (extract, transform, load) to enable high volume, low latency message transfer, which is more flexible and robust than comparable integrations then this would potentially transition the project into an R&D tax project.

The second requirement is that the project must be Technologically uncertain. That is that it is challenging, how to achieve the Technological solution (not the functional solution).

For example, it may be that there are several ways to achieve the security requirements of the new software, but each way may have different knock-on consequences for the Technology (such as performance and stability). It may be that how to design and develop a solution (considering these) would hence bring about the Uncertainty on a 'wholesale' project.

Companies can include any time (or costs) that was required to overcome Technological Uncertainty. On a Wholesale project, this could be the architecture, development, testing, and project management of a new system. It is not possible to include the initial business requirements of a project (before work has started to resolve Uncertainty) or routine production support (after the Uncertainty has ended).