VATGPB10020 | Government departments and health authorities: Contracted Out Services (COS) Headings: practical advice on applying the wording in COS heading 14

From HM Revenue & Customs · VAT Government and Public Bodies

COS Heading 14 requires that a computer services system and/or software package be 'supplied to the specification of the recipient' to be eligible for recovery.

Existing guidance VATGPB10010

This heading applies to services supplied to a government department or NHS Body in its procurement of an IT system to its own specification or to specifications dictated by the government or NHS.

For an IT system, as defined in VATGBP10010, and/or software package to be supplied ‘to the specification of the recipient’, it should usually be clear and evident whether the engagement that has taken place between supplier and recipient goes beyond providing a request for a product/Terms of Reference for a service.

It is HMRC’s opinion that if the legislative intention was to allow for situations where the procuring party simply outlines its specifications at the outset, with the provider then delivering that service, there would be no need to include the ‘to the specification of the recipient’ wording, as the heading could simply read ‘Computer Services (…) including the provision of… etc.’

The wording ’to the specification of the recipient’ therefore adds an additional requirement beyond the procuring party simply setting out their requirements, otherwise it would serve no purpose. HMRC’s view of the wording is that it refers to situations where the recipient of the supply has engaged with the provider in a substantial way to develop a new computer system, or to substantially modify one that already exists – in other words, creating something that is bespoke.

The procuring body must be able to demonstrate that their IT system and/or software package is bespoke and designed to meet their individual specific needs resulting from substantial engagement with their provider.

This could include:

Evidence of additional and/or ongoing discussions that take place after the initial request to provide a final product to meet the needs of the recipient. This engagement needs to be ‘substantial’ in the sense that it should play a material role in influencing the end design and successful delivery of the end product.
Evidence of a collaborative process with the provider to design and develop solutions that are unique to the relevant body – whereby the IT system or software design is developed with the recipient, not simply on their behalf.

Examples:

Scriptswitch

In March 2018, we agreed that the purchase of ScriptSwitch software did meet the conditions for recovery under heading 14. Previously, we understood this to be standard software that had been modified. However, the developer provided further evidence that, while the original design concept addressed perceived needs and initial coding was undertaken, the software only became a viable product as a result of development through collaboration with a number of NHS bodies. The bodies agreed with the need for a solution and fed into its development so that software would provide the necessary functionality and be compatible with other NHS/GP IT systems.

Evidence included:

a history and development timeline
original design documentation
notes of meetings
email correspondence
trial notes
amended design specifications
initial sales documentation

OptimiseRX

In August 2018 we also agreed that the OptimiseRX software met the conditions for recovery under heading 14 (following a similar process to that of ScriptSwitch). The developer noticed a perceived need within the NHS and performed extensive market research. Following this initial research period they then developed the product through collaboration with multiple NHS trusts. It only became a viable product for the purposes of heading 14 once this collaborative development of the software had addressed the needs of the NHS, and which could not be implemented elsewhere without significant adaptations.

Applying the 'to the specification of the recipient' test

As explained above, the wording "to the specification of the recipient" in the heading itself means that the system or software should not only be designed and built in order to meet certain perceived needs. There must be substantial involvement by the relevant body in the supply of modification of the IT system or software beyond merely entering into a contract or agreement to provide and/or receive IT services.

For example, the body procuring the supply/supplies must have clearly played a role in shaping the development of the IT system/software package beyond simply outlining a list of requirements and waiting for the supplier to provide what they have asked for.

Evidence of substantial involvement could include the following:

records of correspondence or meetings in which discussions around the needs of the recipient and customisation / development have taken place
other documentation that indicates how the supplier has developed the IT system/ software package being provided following this additional layer of engagement to meet the needs expressed.
plans to work with the supplier to develop something suitable to meet their requirements
a project plan (or similar) that reflects these engagements any other documentation that evidences the essential work done between the parties that led to the overall IT system or software being developed successfully, such as details of tasks performed, progress reports, earlier iterations of the product/service, timescales for work access requirements, copyright licences etc
meeting minutes to reflect discussions around the development of the system/components to the Trust’s specification
any other documentation that evidences the essential work done between the parties that led to the overall IT system or software being developed successfully, such as details of tasks performed, progress reports, earlier iterations of the product/service, timescales for work access requirements, copyright licences etc

In these circumstances the IT system or software is therefore bespoke to the relevant body and meets the ‘to the specification’ test.

The above examples of evidence are not intended to be exhaustive nor are the examples in this guidance provided as a checklist, they are suggestions of possible forms of evidence you may consider. Whether or not a service has been provided ‘to the specification of the recipient’ will always depend on the individual circumstances of the procuring body and the facts surrounding the engagement between that body and the service provider. Every case will need to be considered on its own merits.

The meaning of 'integral' in the context of software licenses:

As explained in the wording of the Heading, the ‘development, delivery and support of bespoke software’ is eligible for recovery. Where software is procured that does not meet this definition, it can still be recoverable if it is ‘integral’ to a wider IT system that has been procured by the public body, if that IT system met the ‘to the specification of the recipient’ test.

'Integral' means software licenses which are essential for the IT system to continue to function, i.e. without them, it would fail to operate.

An example of an ‘integral’ license would be a license that is provided as part of a qualifying IT system when that system is procured, or direct renewals of those licenses.

We accept that there will be some friction between a license that is 'needed' for the technical purposes of the computer services system and one that is needed for the wider purposes of the relevant body. But the answer to that question should be based on the specific facts of each case.

An example of a qualifying software license is a security software license, without which the qualifying IT system could not operate. Similarly, where an update is required to that license, and without it the recipient would be prevented from operating the IT system, such upgrades of qualifying security software licenses are recoverable.

Microsoft 365

Microsoft 365 offers multiple services, apps, and software products under license.

The majority are purchased or subscribed to via different plans that can be personalised depending on a business’ needs. While each product, app and service can be combined to meet individual needs, they are not in themselves, or in combination, ‘bespoke’ software, nor do they amount to an IT system.

As they are available to purchase by any business wishing to use them, HMRC consider Microsoft 365 as ‘off the shelf’ software. Microsoft 365 software licences are therefore non-recoverable for the purpose of COS VAT.

The only instance where Microsoft 365 licences may be considered VAT recoverable is where they are supplied as part of the procurement of a qualifying IT system and are necessary for that IT system to function, and when such a licence is renewed. We expect that this will only apply in very limited circumstances.

In any other scenario, recovery would contradict the wording of the heading, which specifically excludes ‘off the shelf’ software from recovery.

Renewals and user extensions of licences

A software licence is a document that provides legally binding guidelines for the use and distribution of software.

Renewals of licences for off-the-shelf software that were procured as part of a wider supply of a qualifying IT system were intended to be covered by COS heading 14, and not just their initial purchase as part of a whole qualifying IT system.

Renewal – A renewal in this context is where the previously recoverable licence is being renewed once it expires.

If a new or renewed software licence extends the previous functionality of the IT system (amounting to an upgrade of the previous IT system) the ‘to the specification test’ will need to be reapplied and met for the licence to be considered recoverable.

User Extensions - An extension in this context is where the licence is extended in respect of the number of users that can utilise it.

Where a licence was previously recoverable, an extension of that licence to increase the number of users above what was originally covered through the initial purchase, is still VAT recoverable.

Renewals and user extensions of software licences are separate and distinct from one another and as such they need to be considered as set out above.

Both scenarios are VAT recoverable provided the software licence they relate to was originally agreed to be recoverable.