Example R&D Tax Claim for an Insurance Company

This article will provide an example of a successful R&D Tax Credit Claim for the development of software for an insurance provider. As with all kinds of R&D projects, the RD Relief online claim portal can help clients easily prepare Insurance R&D claims in the cloud.

We have assumed that the reader has a basic understanding of the R&D eligibility criteria (Technological Advance and Uncertainty).

A Large national supplier of insurance products - employing approximately several thousand individuals in the UK. These figures meant that the company did not qualify for the SME R&D regime and so the claim was to be under the RDEC regime.

Over many years the company had developed and extended their (now legacy) software estate. This 'monolithic' architecture had become cumbersome and very difficult to maintain.

During the claim period, there were two streams of development.

Different teams within the company undertook these streams of development.

The team assessed that the re-architecture of the platform into a micro-service based architecture was adhering to the BEIS guidelines. The assessment process viewed the project as being a significant technological shift to develop fundamentally new knowledge about how the team could split the specific legacy monolithic technology into smaller micro-service based components. How to achieve such an extensive architectural re-design, without adversely affecting the underlying stability of the platform brought about the Technological Uncertainty required to classify this as a project that qualifies as R&D for Tax Purposes

It was slightly more tricky to assess whether the other work to extend and maintain the existing legacy systems would be eligible as R&D for Tax purposes. Although the team furthered the internal technology, it was challenging to assess whether it was appreciably improved relative to the industry baseline of technology.

To overcome this complexity, we went to the next level of detail and discussed each of the individual capabilities developed. This process found that some of the new features developed were indeed seeking a technological advance (and were technologically uncertain) while others were not. Ultimately this resulted in this workstream having a lower overall eligibility % than the architecture shift project - but this was widely expected and understood.

Time spent by each of the two teams to design, develop, test and project manage the Project (or sub-projects) qualified as under the RDEC regime. The time required to identify initial functional requirements, in addition to the time spent by the support team maintaining the legacy system in production were not includable.