R&D Tax Credits for Retail

Retail is a field which often gets overlooked for R&D Tax Credits as often the most visible aspect of the company is the front-end process of selling goods to customers. However, to allow this to happen most large retails, and many smaller retailers are continuously developing new software and integrating legacy & third-party technologies in unproven ways. These are the types of project that typically meet the R&D Tax Relief eligibility criteria.

For a Retail project to qualify for R&D Tax Credits, it must adhere to specific guidelines that have been defined by the UK Department for Business, Energy & Industrial Strategy (BEIS).

The R&D eligibility criteria apply to all fields of Science and Technology rather than just Retail or Software Development projects, which means that they are quite abstract and sometimes hard to directly map to the types of projects occurring within Retail. They state:

Retail is a type of business sector, rather than a Technological (or Scientific) sector, which means that the Scientific or Technological Advance the Advance must be relative to the current industry baseline within Software Development. Referencing 'Technological' rather than 'Functional' issues is where a significant proportion of retail companies go wrong with their claims, as they see Retail Technology as the industry baseline and incorrectly assume that being able to do a new type of functionality (e.g. a more flexible planogram system) would tick the Advance box. Hence, the Advance can't be that the company is applying Technology to a business / functional purpose - it must be a Scientific or Technological Advance.

Achieving an Advance relative to the industry sounds like a tough hurdle when most competent professionals first hear it. However, that is not always the case that it is an insurmountable hurdle. Companies developing a new planogram functionality are also in many cases developing new algorithms to support the Technology. So the Technological Advance may the development of robust algorithms which are more flexible and robust than were previously possible (specific details would be required).

The Uncertainty would be where the competent professional/s are uncertain how to achieve the Technological solution in practice.

For example, it may be that there are several ways to achieve the security of the new software, but they may have different knock-on consequences for the performance, stability and extensibility of the platform. How to design and develop a solution that takes into account these would bring about the Uncertainty.

The project for R&D Tax purposes starts at the same time as work to resolve the Technological Uncertainty and ends when the Technological Uncertainty finishes.

This definition means that any initial function specification of the project would not typically qualify (which is most often the case in a waterfall style environment but can get a little greyer in an agile development environment). However, once the Technological parts of the project start (e.g. architecture or development) this would often be seen as the start of the claim period. Until the team has resolved the Technological Uncertainty, you can include any development, testing, setup of test environments or project management (which could be in a system test, a performance test or UAT environment, or in some rare cases in production itself). After addressing the Uncertainty of the Project, other costs should be excluded, including support and maintenance of the end product.