Complexity / Risks

Software is a notoriously complex area for the submission of robust and defendable R&D claims and is the main technology area where HMRC enquire into and reject (or substantially reduce the value) of claims.

The main difficulty arising is that companies developing software can spend significant resources in planning, writing, testing and debugging software yet whether part of all of these costs are eligible costs for R&D Tax Credit purposes comes down to whether the software development meets the HMRC criteria for R&D and whether that can be communicated effectively to HMRC.

With generalist accountants remaining understandably under-skilled regarding R&D claims, and very few R&D specialists also being software engineers, many software companies have either under claimed or not claimed, whilst others have incorrectly claimed without the necessary supporting evidence and would be unable to defend their claim if HMRC launched an enquiry which they can do up to six years following the submission and payment of a claim.

Many advisors and accountants incorrectly advise their clients that work spent developing bespoke software code to provide new “features and benefits” de facto qualifies as R&D. This is most definitely not the case and many claims are rejected by HMRC because the claimant (often supported by inexperienced advisors) prepares a detailed report focussing on the features and benefits of the software development rather than demonstrating the underlying advancement of science and technology required to realise these features and benefits.

In order to prepare a robust claim, it is necessary to have supporting documentation identifying the advance in technology sought by the project, the technical uncertainties that were required to be overcome to achieve the technological advance and the reasons as to why the resolution of these technical uncertainties would not be obvious to a competent professional in the field.

Additionally, the software development process with freelancers, subcontractors, agency workers, offshore developers, seconded group employees and use of third party software tools under license creates significant complications in determining historically which costs can be legitimately claimed and establishing structures to maximise future claims. This is even more complex when the software is being developed as part of a “consulting contract” where the detail of the software development contract between the parties can result in a significant difference in claim value or even whether a claim is eligible.

Add paragraph about Revenue v Capital Expenditure complexity after review of Kitt book.


The need to identify and document the ‘advance in Science and Technology’

Whilst there are numerous detailed eligibility criteria and different inspectors at the seven (not 6 now??) specialist R&D Tax units adopt their own interpretation of guidelines, there are nevertheless certain minimum technical criteria that software projects must meet in order to qualify. The legislation governing claims is broadly worded and interpretation and effective communication is key. The HMRC Guideline on Software claims (CIRD81960) sets out some basic rules for Inspectors to follow. For example:

  • The project must seek to achieve an advance in science or technology. (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.)
  • The advance in science and technology must be resolved (or attempt to be resolved in the case of a failed project) through the resolution of a technical uncertainty.
  • The resolution of the technical uncertainty should not be obvious to a professional competent in the area of software for which the claim is being made.

In order to demonstrate an advance in science / technology it is necessary to provide a state of the art review of the field at the start of the project. This is where an experienced advisor with knowledge gained from hundreds of previous claims in software as well as access to commercial patent, academic literature and VC software funding search tools can provide a detailed prior art search in order to set the baseline knowledge base for the project undertaken by the company.

Technical Uncertainty

A key aspect of the supporting technical report is to identify and document the technical uncertainties that were required for the successful completion of the project.

A typical client response is that with 100,000 lines of source code and numerous bugs there were bound to be technical uncertainties.

There is always some technical uncertainty about any major software or IT project but HMRC consider that uncertainties that can be resolved through discussions with peers or through established methods of analysis are routine design uncertainties rather than technological uncertainties and hence would not consider qualifying activity.

In order to demonstrate compliance in this area it is necessary for the supporting technical report to demonstrate how the project could not have been solved through “discussions with peers” or “established methods of analysis” – this can be quite subjective and the experience of the advisor preparing the report especially gained through advising multiple clients through an HMRC formal enquiry can be invaluable.

Difficult Technology Areas in which to claim

HMRC identifies a number of situations for which, although software development took place, it would not normally consider as eligible R&D such as:

  • The development of a new or unique software product or application does not de facto represent an advance in science or technology simply because it is software or new. This often affects claims whereby a software application is replacing a previously manual process. Such an automation of a previously manual process is not considered as qualifying R&D unless it can be argued that in order to create software to replace the manual process an advance in science and technology was solved by the resolution of a technical uncertainty which was not obvious to a competent professional.
  • Routine adaptation of an existing product or process is not qualifying R&D. This can often affect claims where a company has developed a new version of software taking the product some way forward in its application, “features and benefits”. This restriction applies even in cases where HMRC may have approved the claim based on the development of the first version of the software. This is an area where specialist advice is required to determine whether the activity undertaken constitutes “routine adaptation” or has inherent identifiable uncertainties / advancements which will bring the project into qualifying R&D.
  • Assembling components of a program to an established pattern or using routine methods for doing so is not qualifying R&D. This is where specialist guidance is required to determine whether a project required software developments which utilised “established patterns” or “routine methods” or new approaches and processes were being adopted during the development.

Areas HMRC consider unlikely to involve R&D, yet we have claimed successfully.

Some software applications or components of applications will follow established methodologies and according to HMRC will not involve scientific or technological uncertainties and so will not qualify as R&D. Examples that HMRC give 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.
  • The assembling of, 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.

We have been successful in making multiple claims in all of the above areas and so projects in these fields should not be automatically dismissed. However, it needs to be understood that projects in these areas will almost certainly be closely scrutinised by HMRC and so any claim needs to be supported by compelling explanations. This is where we add significant client value.

Fields in which we have made claims

BigData Analytics (NoSQL, Cassandra, Hadoop, MongoDB)

E-Health (Telemedicine, NHS Spine, N3 Security, Patient Records, HL7, Healthcare Apps)

Cloud Infrastructures / Deployment (Dynamic cloud deployment, hybrid cloud architectures, PaaS)

Architecture Methodologies (Service Virtualisation, Microservices, API, Real-Time Event Processing, Reactive architectures)

ERP Solutions (Optimisation, Visualisation, Business Logic Integration, Real-Time device integration)

Data Visualisation (Hypercubes, Graphical Programming Neo4J)

Data Analytics (CRM marketing optimisation, retail analytics)

Gaming (Real-time graphics, gambling regulation compliance, 3D multi-camera visualisation)

Artificial Intelligence (Neural Networks, Fuzzy Logic, Genetic Algorithms, Wweb Search)

Fintech (Financial Transaction Processing, Share compliance, FX exchange architectures, Cash collection workflow solutions, Automated secure payroll processing)

Image Processing (Defect segmentation, Classification, Machine Vision)

GIS Systems (Mobile worker optimisation, Travelling salesman type algorithms, Gazetteer Management Systems)

SEO Optimisation (Penguin Algorithm)

System Test / Automation Architectures (Fault Tree Analysis, FEMA)

Mobile Communications (Text Messaging Architectures and Bulk Mail Communications)

Mobile Apps (Media streaming, mobile worker optimisation)

Legal services (Relational databases for legal compliance)

Pharmaceutical Clinical testing / compliance (CFR21 part 11), Workflow

Wireless sensor networks (temperature, humidity and energy monitoring)

Embedded Software (PICs, TMS320C40 developments)

E-Commerce / Web Applications (Retail product visualisation, Optimisation, Faceted Search Algorithms, Customer Loyalty Algorithms, Tourist / Leisure ticketing systems, Recruitment agency software)

POS Retail and Payment Processing Solutions.

Enterprise Supply chain solutions (Workflow, communication, optimisation – retail sector)

Home Automation Solutions (Multi-media system integration)

VOIP (System Integration, Security)

WebRTC  (System Integration and Security)

Insurance (Risk assessment, loss adjustor workflow solutions).

Boundary Points

Many companies incorrectly assume that because a project contains an element of qualifying R&D that all the costs associated with the project can be claimed.  This is not the case.

HMRC consider the qualifying costs as starting at the point that the technical uncertainty was identified and ending at the point where the technical uncertainty was resolved.  In most cases HMRC would expect there to be further non-qualifying development work to be undertaken “routine commercial software development” as they like to call it before the point of commercial launch of the product.

Accurate determination of the start / end dates of the qualifying period of the project (boundary points) is thus critical in both preparing a robust and defendable claim, but also in maximising the legitimate costs that can be claimed.

This can often affect companies on making a second or subsequent claim, where having made a first successful claim they assume that just continuing on the same project would automatically result in a successful claim, not realising that as the project gets closer to / beyond first commercial exploitation examination of the boundary points is likely to come under closer scrutiny. Worse still an enquiry triggered by boundary point concerns on a subsequent claim can result in HMRC going back and investigating the earlier claims.

The exact determination of when the technical uncertainty has been resolved and when non-qualifying “routine commercial software development” commences can be quite subjective and an experienced analyst should have a number of tools in order to try to evaluate a methodology that will enable the end date to be robustly defended.

Subcontractors / External Workers

The nature of modern software development processes is such that it is rare for software to be fully developed in-house by salaried staff.  Often in-house staff are augmented by a mixture of individuals and companies that bring specific skills to bear on a project.  These external entities may be “freelancers”, agency workers, Ltd companies, personal services limited companies, offshore providers of workers, offshore development companies, “consultants” and even staff seconded or provided by another group company.

The exact nature of the legal entity engaged on the project and the nature of the contract between the parties can have a significant effect on whether the costs can be legitimately claimed.

It is a sad fact that many claims where companies have spent vast sums outsourcing software development which would otherwise qualify on a technical criteria (i.e. it represented an advance in the field over the prior art baseline knowledge, requiring the resolution of a technical uncertainty which would not be considered obvious to a competent professional in the field) fail because the mechanism by which the work was “outsourced” did not meet the specific and detailed requirements laid down by HMRC. In many of these cases a slight variation on the nature or terminology used in the contract between the parties at the start of the project could have resulted in a claim being eligible.

We strongly advise that any company embarking on a software development project where a significant expenditure will be incurred on persons not employed / paid through the company payroll seek expert professional advice in to the contractual structure between the parties prior to the commencement of incurring of the costs.

Our Software Expertise.

Software claims are sufficiently complex that they will only be prepared both technically and financially by partner level staff at May Figures.

 Our technical lead for software claims is Dr Mark Graves.  Mark has a PhD in Computer Science and spent 15 years heading up software development teams in the UK, USA and India liaising and collaborating with academics and researchers from University of Wales, Oxford University, De Montfort University and Georgia Tech in USA.  He has been on the organising committee of 3 international conferences in the field of image processing software, published numerous academic articles and was the lead editor of a Springer Verlag book on Computer Vision.  Since moving fulltime into the R&D Tax Credit field in 2010 he has prepared the technical supporting report for over 600 claims, of which over 300 are in the field of software.  Whilst no longer a hands on software engineer Mark keeps abreast of latest developments in the field by reading advanced books, academic papers and PhD dissertations and undertaking CPD courses on emerging software technologies.

Our financial lead for software claims is Julia May.  After graduating with an Engineering Science degree, Julia qualified as a Chartered Accountant / Chartered Tax Advisor with a big 4 firm specialising in international trade taxation before spending a number of years in industry working for an international geospatial software house and IT consultancy. Whilst Head of Fulfilment for a major R&D Tax consulting firm she oversaw technical and financial reports for XXXX claims and since establishing May Figures she has prepared and filed over XXXX claims.  She has significant experience of dealing with software companies who outsource development to agency workers, offshore developers and subcontractors.  She has successfully prepared claims for a number of IT Consulting firms who were previously incorrectly advised that the consultancy nature of their work would mean that they were ineligible to claim.

Both Mark and Julia have first-hand experience of advising software clients during the HMRC formal enquiry process. At our most recent HMRC enquiry (initial submission that led to the enquiry was not prepared by us) not only were we able to successfully defend a vigorous enquiry by HMRC (4.5 hour first enquiry meeting) our subsequent 60 page analysis of the prior art was sufficient for the client to actually significantly increase the claim value above their initial submission level.

Julia and Mark have never had a client claim rejected by HMRC or reduced in value on HMRC enquiry.