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

HMRC internal manual

Corporate Intangibles Research and Development Manual

R&D tax relief: conditions to be satisfied: BIS Guidelines (formerly DTI Guidelines) (2004) - application to software

There are two ways in which expenditure on the creation of software can be R&D within the DTI guidelines. References to paragraphs in the sections below are to the paragraphs in the 2004 DTI guidelines (CIRD81900).

1) Software that is used as a tool in a larger R&D project

Where software is developed as a tool for direct use in a larger R&D project, then development of the software will qualify as R&D. An example might be data handling software needed to record and monitor the results of the R&D. The software need not of itself involve a specific advance in science or technology - if it directly contributes to a larger R&D project it will qualify as R&D (para4). The question of what is the R&D project is addressed at para19.

Top of page

2) Development of software as the goal of the R&D project

The following guidance relates to software projects.

The guidelines apply to a software project in the same way as they apply in any other project.

  • The project must seek to achieve an advance in science or technology (para3).
  • The activities that directly contribute to achieving the advance through the resolution of scientific or technological uncertainty are R&D (para4).
  • There must be an advance in overall knowledge or capability in a field of science or technology, not just the company’s own state of knowledge or capability alone (para6).
  • The development of a software product does not represent an advance in science or technology simply because it is software (para8).
  • Routine adaptation of an existing product or process is not R&D (para12).
  • Assembling components of a program to an established pattern or using routine methods for doing so is not R&D (para29).
  • Combining standard technologies can be R&D if a competent professional in the field can’t readily deduce how the separate components should be combined to have the intended function (para30).

Most software projects will be intended to result in a product to be either used in house, licensed or sold.

The project may be to produce a product for use in the arts, humanities and social sciences (including economics). Such projects would only qualify as R&D projects to the extent that they are seeking to advance knowledge through the resolution of scientific or technological uncertainty. This is because of the general exclusion of the arts, humanities and social sciences (including economics) in the DTI guidelines on the meaning of R&D.

Software projects and system uncertainty

It may be claimed that there are always system uncertainties involved with software. It is true that there is always some uncertainty about anything. But uncertainties that can be resolved through discussions with peers or through established methods of analysis are routine design uncertainties rather than technological uncertainties. Technical problems that have been overcome in previous projects on similar operating systems, or computer architecture, are not technological uncertainties.

Where the aim of a project goes further than resolving scientific and technological uncertainties the project as a whole will not qualify as R&D, but there may be elements in the project that do qualify as R&D. Most projects for the development of a commercial product will go further than resolving technological uncertainties and so will not qualify as R&D in their entirety.

Projects unlikely to involve R&D

Some software applications or components of applications will normally follow established methodologies and not involve scientific or technological uncertainties and so not qualify as R&D, examples are:

  • The handling of interactions with users. This covers areas such as development of data entry procedures and user interfaces.
  • The visual presentation of information to users.
  • Creating software that replicates an established paper procedure, possibly building in best practices. The fact that a previously manual task has been automated does not by itself make it R&D.
  • The assembling, carrying out routine operations on, and the presenting of, data.
  • Using standard methods of encryption, security verification and data integrity testing.
  • Creation of websites or software using tools designed for that purpose.

However where these contribute directly to a larger R&D project they would not be excluded from the larger project.

Software projects likely to be R&D

  • Developing new operating systems or languages.
  • Creating new search engines using materially new search methods.
  • Resolving conflicts within hardware or software, where the existence of a problem area and the absence of a known solution have been documented.
  • Creating new or more efficient algorithms whose improvements depend on previously untried techniques.
  • Creating new encryption or security techniques that do not follow established methodologies.

An indication of the type of questions to be asked in considering whether a project or a component of a project is R&D is contained in CIRD80520; these questions apply to software projects as well as to other projects. Examination of the records relating to the nature of the project CIRD80550 is likely to be helpful in cases of doubt.

Software as capital expenditure

It is possible that a software project, despite being an R&D project, will not qualify for R&D tax relief because the expenditure is capital for tax purposes. This is dealt with at CIRD81700.