This part of GOV.UK is being rebuilt – find out what beta means

HMRC internal manual

Corporate Intangibles Research and Development Manual

Case Studies demonstrating R&D tax credit claims for software projects

Case Studies demonstrating R&D tax credit claims for software projects

This page provides 4 case studies showing how companies with software projects might consider whether they are eligible for making an R&D tax credit claim. The case studies are intended to be examples to show how similar companies might identify the boundaries of R&D for tax credit purposes. As high level, and fictitious, examples, the case studies cannot describe all of the factors leading to a specific sub-project being classified as qualifying or non-qualifying as R&D for tax purposes. In a fast developing sector like software, advances and technological uncertainties continually change. The same objectives may operate in a different technological context or under a different set of technological constraints, with different conclusions. However, the headings and examples provide guidance as to how each company can apply the BEIS Guidelines to its own software projects. The paragraphs referred to are within the BEIS Guidelines at CIRD81900. Further details about R&D software projects are at CIRD81960.

Case Study 1

Commercial / IT project: Migration of data and IT services to a cloud-hosted platform to provide lower total cost of ownership


  • ‘Readily Deducible’ (para 13)
  • R&D projects contained within a larger commercial software project (para 19)
  • Example of appreciable improvement (para 23)

The commercial project undertaken by Company XYZ was to achieve a lower total cost of ownership for their data, through implementing cloud-based data storage and platform & service provision.

This was to be done through a migration to a cloud-based architecture, providing IaaS, PaaS and SaaS layers.

The internal IT team had responsibility for the middleware and architectural structures to be deployed on the cloud. They settled on a hybrid cloud approach, mixing public and private cloud deployments of applications and services.

The implementation of the hybrid architecture further provided corollary business benefits in terms of data transfer audit capabilities, for meeting appropriate security standards.

  • IT work not considered to represent qualifying activity

The work undertaken in this project to identify, test and evaluate messaging systems to operate as middleware, although extending the company’s own knowledge and understanding of how these products worked, was not an overall advance in technology, so was not considered to be R&D for tax purposes. There was no technological uncertainty in terms of feasibility, or of how to implement these systems in practice (para 13), and the selection and deployment of middleware in this project does not therefore represent a technological advance in terms of overall capability or knowledge (para 6).

Work undertaken to implement and test 3rd party certification systems for secure connection authentication was not considered to represent a technological advance (para 6), as it was not addressing a technological uncertainty in terms of the feasibility of having security certificates, or their practical implementation (para 13), but was carried out for the purposes of benchmarking performance of different commercial offerings only, rather than testing of baselining overall technological capability.

Similarly, the design of system architectures for implementing guaranteed delivery of data, and for incremental data synchronisation between systems, did not present a technological uncertainty in terms of feasibility (para 13), nor was its practical implementation uncertain (para 13). Since for this project, the work does not represent a technological advance in terms of overall capability or knowledge (para 6), it was therefore not included in this claim as R&D for tax purposes.

  • R&D project within the commercial / IT project

The competent professionals within the Company were unaware of, and unable to identify, suitable approaches or methods for the practical implementation (para 13) of an IT capability for passing sensitive data between the public and private clouds without a significant negative performance effect, such as that which was known to be the case with the use of a 3rd party security validation solution.

  • Technological advance sought

The typical approach to passing data securely between systems would be to provide a shared encryption certificate validated by a 3rd party service; however this was not a suitable approach in this case, as it was known that this would introduce a significant performance overhead. (CIRD81960 section 2a, 2b).

The technological capability baseline against which the advance was measured in this case (CIRD81960  section 1a) was that although guaranteed delivery of messages and data between IT systems was available, due to the security constraints that the company faced it was not possible for the IT systems to pass security tokens between the private and public clouds as there was no shared “trust” mechanism which did not impose a significant performance penalty through having to connect to a 3rd party to provide this mechanism (CIRD81960 section 1b).

The specific technological capability advance sought was to establish how, in practice, to implement a shared security certification and trust mechanism (CIRD81960 section 1c) which did not rely on the use of a 3rd party, with the associated performance overhead (para 6).

  • Technological uncertainty faced

The specific technological uncertainty was the practical implementation of such a system without using a 3rd party security validation service. (para 13).

  • Work done to resolve the uncertainty

As there was no known or readily deducible approach to resolve the uncertainty, experimentation was necessary to ascertain whether a feasible solution could be developed. The solution needed to satisfy the necessary requirements or characteristics of modern security, including confidentiality, authentication, integrity and non-repudiation.

The company’s competent professionals implemented an internally-facing certificate authority server which was able to provide high performance security authentication. This solution was considered not to be readily deducible, given its non-trivial nature for practical implementation. (CIRD81960 section 2b)

The certification server was hosted on the public cloud, rather than the private cloud, and was subsequently licensed to the cloud provider, providing an example of an appreciable improvement to an existing product or service (para 23), as a new technological capability (para 6) for implementing secure hybrid cloud deployments. (CIRD81960 section 1c)

  • Boundaries of the R&D project within the commercial/IT project

The technological uncertainty was first identified when an implementation of the hybrid architecture using a 3rd party certification system did not provide sufficiently a performant method of authenticating connections between the private and public clouds, and the advance sought was the practical implementation of a solution which did not utilise a 3rd party (para 33).

The uncertainty was recognised as resolved when a private certificate “minting” server was implemented on the architecture and was tested to be able to reject expired and invalid certificates. (para 34 and CIRD81960 section 3)

Only work on the development and practical implementation of this security server formed the R&D for tax purposes of this claim (para 19).


Case study 2

Commercial / IT project: Identification of card fraud through big data analytics and Machine Learning/Artificial Neural Network (ML/ANN)


  • Routine uncertainty and routine analysis (paras 22 and 29)
  • Testing and prototypes (para39)

A company wanted to improve its product, which was used to detect potential card fraud in the financial sector. The previous version of the product used a complex series of rules to identify transactions which could indicate fraudulent use, and did not use ML techniques.

This project sought to produce a ML/ANN based fraud model with a lower false positive rate than would be possible with competitor solutions.

  • IT work not considered to represent qualifying activity

Determining whether supervised, semi-supervised, unsupervised or reinforcement learning, or a hybrid approach, would be suitable, or optimal, for a particular application may involve considerable experimentation, validation and testing; however unless it is directly addressing a technological uncertainty then it would not be qualifying activity. (Para 22, 26, 27c, 41, and CIRD81960 Section 3).

The identification and assessment of existing generic ML solutions for potential deployment was not considered to be qualifying activity, as it did not seek to advance overall technological knowledge or capability (para 6) but was using existing technology (para 8 & CIRD81960 Section 2).

Whilst it is essential to have data to gain insight, in this case, the determining of which data sources and what data from those sources would be valuable was not considered qualifying activity, as it involved a question of relevance of commercial data to the company’s use-case, rather than a question of advancing technological knowledge or capability (Para 6, 13, 29, 43).

The knowledge and capability gained in terms of what represented a signal of potential card fraud was not to be technological in nature, and therefore does not represent an advance in technology (Para 6) so is similarly non-qualifying.

Similarly, the aggregation of the data, the structure of the data (the “data model”) and whether signals could be identified within the data streams (the ANN “model” hypothesis of what would constitute a valid “signal”) was not considered to be qualifying activity as it involved no technological uncertainty. (Para 13, 29, 41, 43, CIRD81960 Section 2)

  • R&D project within the commercial / IT project

Within the IT project qualifying activity was considered to be carried out in the practical implementation of a structure of an ANN which could pre-select network processing “pathways” for de-selection before the ANN had even experimented with them.

  • Technological advance sought

The technological advance sought was the development of an ANN approach which pre-selected the pathways which should be calculated within it, such that, prior to a “pathway” being commenced the ANN could “decide” that it was unlikely to be of value and therefore was selected out before any processing was undertaken.

Effectively, the ANN would be able to determine whether a calculation - which could be computationally intensive and expensive - was likely to be of value before actually doing any calculation, representing a non-trivial appreciable improvement in ANN software capability. (Para 6, 23 & CIRD81960 Section 2 (1))

  • Technological uncertainty faced

The company were faced with technological uncertainty as to how, in practice, to implement an ANN which could effectively pre-select pathways which were unlikely to be commercially valuable before performing any processing on them.

For example, whilst it was feasible to organise an ANN in order to rank different processing pathways, typically each pathway must have been processed to some level in order for the ranking to take place, there was no practical, or readily deducible, way of structuring an ANN to eliminate the need to carry out this processing. (Para 13, 14, 20 & CIRD81960 Section 2 (2))

  • Work done to resolve the uncertainty

The company developed, in effect, a network of ANNs, underneath a “master” ANN, which analysed and predicted, based on its own “learning”, whether a new processing pathway was likely to meet the threshold set for identifying potential card fraud, and used this to automatically deselect less promising pathways. This provided a self-sustaining feedback loop which enabled the system to effectively reinforce its own learning.

  • Boundaries of the R&D project within the commercial/IT project

The qualifying activity commenced with the implementation of the first “master” ANN. This sought to resolve the technological uncertainty as to whether such an ANN could be implemented in practice to realise the technological capability sought. (Para 6, 13, 19 & 33)

The testing of this master ANN to “predict” the likelihood of value of a particular pathway was considered to be testing towards the resolution of the technological uncertainty. (Para 27c, 39, CIRD81960 Section 3).

Once the outcomes from the master ANN were similar to those of the company’s previous software version (Para 9d, 14), the technological uncertainty was considered to be resolved (Para 34, Example G1).

Any further work was considered to be optimisation and fine-tuning (Para 14) and hence non-qualifying (Para 26, CIRD81960 Section 1c & 3).


Case study 3

Commercial / IT project: Appreciable improvement to the underlying technology in order to improve UI (User Interface) and User Experience (UX)


  • cosmetic and aesthetic effects (para 42) in software projects

A company wanted to deliver streaming video to a variety of end-user devices with guaranteed picture integrity, but without a significant performance overhead. This would give the company’s customers an enhanced UX in terms of perceived video quality.

  • IT work not considered to represent qualifying activity

Work to develop the basic video streaming server and client was not considered qualifying as this was routine IT development activity, and involved no technological uncertainty (Para 13, CIRD81960 Section 2). Similarly, the graphic design of the responsive UI and other stylistic and aesthetic effects were not considered to be qualifying activities (Para 42).

The development of a mobile application, sharing a common code-base with wrapper software dependent upon the operating system of the end-user device, was not considered qualifying R&D activity as the methodologies and tools applied in its creation were typical of such software development. (Para 13, 14, 20, 22)

Aspects concerning the optimal balancing of processing between the client and server to avoid overstretching mobile devices’ processing and battery capacity, or producing bottlenecks in the network, were not considered qualifying R&D activities, as these were viewed as design constraints (Para 41), and so did not contribute to resolving a technological uncertainty (Para 4, 13, 27c, CIRD81960 Section 2). 

The company had to implement on-the-fly data compression and decompression. This was not considered to represent qualifying activity as it concerned the evaluation and selection of the most appropriate existing compression algorithm. (Para 8, 12, 22, 24).

Work on inserting anti-copying/anti-piracy protection mechanisms into the data was not considered qualifying (Para 43), but is a commercial consideration.

  • R&D project within the commercial / IT project

The R&D project concerns the practical implementation of a technological capability (Para 6) to guarantee that the full integrity of the image that was sent was maintained in the image that was displayed on a video stream.

  • Technological advance sought

Typically, video streams would only synchronise and checksum “key” frames, approximately one in each twenty-five transmitted, leading to the potential for image degradation between these key frames. (CIRD81960 Section 2)

The advance the company sought (Para 3, 6, CIRD81960 Section 2) was the capability to synchronise and checksum not only the key frames of a video stream, as protocols at the time of the project allowed, but also the frames in-between, such that the integrity of the whole video stream displayed would be guaranteed with no “dropped” frames.

  • Technological uncertainty faced

The technological uncertainty that the company faced (Para 13, CIRD81960 Section 2) was that the existing mechanism for synchronising a streaming video only confirmed receipt of key frames in the video feed, and there was no retry mechanism should the client not receive some data.

It was uncertain how, in practice, to implement a mechanism where the server could identify where a frame had not been acknowledged by the client and retry sending the data, whilst being aware that resending the data would take longer than was available before the next data was sent.

  • Work done to resolve the uncertainty

The company developed a server capability, using precision timing, to identify whether, should a key frame or delta not be acknowledged by the client, resending this data would “overlap” with the transmission of the next data, degrading video quality.

  • Boundaries of the R&D project within the commercial / IT project

The uncertainty was identified where the company had established that whilst in theory it should be feasible for the video streaming client to acknowledge every frame sent to it, the practical implementation of the precision-timing retry mechanism on the video server would be required (Para 33).

The uncertainty was regarded as resolved where the retry mechanism on the server had been tested (Para 27c) to the point where it was able to function as intended (Para 34) for a single video client, correctly identifying where resending data would take longer than was available before the next video frame was scheduled to be sent.


Case study 4

Commercial / IT project: The development of computer vision systems


  • Boundaries of R&D projects (para 19)
  • Cutting edge projects – when an advance is new to the field of technology (para 6)

A company wished to market a software application that could confirm whether digital images of human faces used for personal identity verification were genuine, tampered with (“Photoshopped”), or computer-generated simulated images.

  • IT work not considered to represent qualifying activity

Work on establishing the technological infrastructure for the IT platform, including the selection and evaluation of Artificial Intelligence platform and paradigm, although complex, did not involve or contribute to the resolution of technological uncertainty (Para 13) and therefore has been excluded.

Work associated with the scalability of the software application was also excluded, on the basis that the advance sought was limited to the implementation of a prototype with all the functional characteristics of the final application. That was the boundary for qualifying activity.In this case, that was the identification of the likelihood of an image being genuine, tampered with, or wholly artificial (Para 19, 33 & 34).

  • R&D project within the commercial / IT project

The R&D project centred around seeking an advance in knowledge (Para 6) whether it was feasible to develop an Artificial Neural Network (ANN) which could analyse digital images of human faces and categorise them as being genuine, tampered with, or entirely computer simulated.

  • Technological advance sought

The technological capability to identify that an image contains a human face pre-existed the work undertaken, and the principles and practice of using feature recognition to provide biometric measurements were already established (Para 20, CIRD81960 Section 2).

The technological advance sought was in the field of ANN, for the purpose of Computer Vision, developing the knowledge (Para 6) of whether it was feasible (Para 13) to develop such an ANN, to identify the likelihood of an image of a human face having been digitally tampered with or simulated. (Para 6)

  • Technological uncertainty faced

It was not known whether it was feasible (Para 13) for an ANN to be able to identify digitally altered or simulated human faces, as humans cannot in many cases discern whether a digital image is genuine or not, and thus there was no basis for the development of a hypothesis for an ANN to be trained upon.

There was similarly not any identified field of science or technology from which such a hypothesis could be trivially adapted (Para 6 & 23).

  • Work done to resolve the uncertainty

The work done involved the generation of a library of “artificial” human faces, based upon a large data set of previously captured images and applying statistical techniques to both create variations and entirely new composite “faces” for analysis and testing of the ANN.

The commercial project did not achieve its goal, however what was established by the R&D project (Para 19) was that although the ANN was able to identify that an image of a face was significantly similar to another face using existing techniques and methods (Para 23), the cause of the similarity or difference (and hence the indication that a picture had been tampered with or artificially generated) could not be identified.

  • Boundaries of the R&D project within the commercial/IT project

The R&D project began when the company identified the technological uncertainty that there was no basis for the development of a hypothesis so commenced work to resolve this (Para 13, 19, 23 & 33).

In ascertaining the start of the R&D project, consideration was given to the extent that sourcing of data from third parties, and the generation of image data specifically for analysis by the ANN, directly contributing to the resolution of a technological uncertainty related to  seeking a technological advance. (Para 27).

The project effectively ended at the point where work to resolve the technological uncertainty ceased with the knowledge that it was not feasible to differentiate between natural variation and similarity in human faces, so that the capability sought was not feasible. (Para 6, 19, 33 & 34).