What is system uncertainty for R&D tax relief purposes?

To determine whether work undertaken qualifies for R&D tax relief, it must meet 3 overarching criteria - a project, an advance in science or technology and evidence of scientific or technological uncertainty that must be resolved to achieve that advance. This is taken from the definition on the meaning of research and development for tax purposes per the Business, Energy and Industrial Strategy ("BEIS") guidelines.

This article takes a closer look at scientific or technological uncertainty in software development - in particular focusing on system uncertainty. Understandings around the concept is brought out by way of an example.

What is scientific or technological uncertainty?

The BEIS guidelines state:

"Scientific or technological uncertainty exists when knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, is not readily available or deducible by a competent professional working in the field. This includes system uncertainty.

Scientific or technological uncertainty will often arise from turning something that has already been established as scientifically feasible into a cost-effective, reliable and reproducible process, material device, product or service."

What is system uncertainty?

The BEIS guidelines state:

"System uncertainty is scientific or technological uncertainty that results from the complexity of a system rather than uncertainty about how its individual components behave. For example, in electronic devices, the characteristics of individual components or chips are fixed, but there can still be uncertainty about the best way to combine those components to achieve the overall effect. However, assembling a number of components (or software sub-programs) to an established pattern, or following routine methods for doing so, involves little or no scientific or technological uncertainty.

Similarly, work on combining standard technologies, devices, and/or processes can involve scientific or technological uncertainty even if the principles for their integration are well known. There will be scientific or technological uncertainty if a competent professional working in the field cannot readily deduce how the separate components or sub-systems should be combined to have the intended function."

So what does this mean?

In software development, integration pieces can require a huge R&D investment from software engineers. When it comes to making the call on whether technological uncertainty is present, software engineers (AKA competent professionals for the purpose of this tax relief), often initially confuse the concept they are assessing - looking to the significance of the commercial concept which is not necessarily new, instead of looking at the significance of the technology concepts underpinning the road map to realise the commercial concept (solution intent).

And further, industry experts working on the projects initially confuse what aspects of the technology concepts they are assessing against the 3 pillars of eligibility, including technological uncertainty. Struggling mostly with the concept of system uncertainty because of the need to separate the fact that it is known how to put components together from the unknowns of establishing new and enriched patterns in integration pieces.

The best way to explain this, is through an example.

Example of what to look for to assess technological uncertainty

Background & context

Consider a retailer that wishes to move away from proprietary systems development to leverage modern, bleeding edge technologies via the concept of headless commerce.

Headless commerce has game changing commercial benefits but is not entered into lightly because it is far from quick and easy to establish. Unlike monolithic eCommerce solutions, the headless concept is not provided as a joined up, readly to go system. Headless as a concept is underpinned by MACH principles and supported by MACH compatible components developed by third party product owners. The concept offers choice in terms of these third-party software products (micro services) and APIs compatible with those, but how these various software components are linked to the backend processes is not done for you.

The key to being able to operate in a headless architecture is that the backend systems (such as order management, content management, commerce, and product information etc.), have robust application programming interfaces (APIs) that allow every function an application can achieve to be performed.  This is not a given as functionality and features in APIs are limited.  

Processing requirements must be orchestrated through linking automations design (data transferred as messages to trigger catalysts of actions) that create the precise business process outcomes needed, and in the way a business needs the processes to be performed.

APIs provide an endpoint for data that is communicated – they can be created to pull or modify data. APIs facilitate communication between different components within the system.  Webhooks are a subset of APIs that are designed and created to automatically send data in response to a specific event, without any request from another software.  They can only send information.

In a headless architecture, because the frontend is decoupled from the backend, an API/webhook infrastructure must be designed to create a system.  None of the frontend third-party software or API components can function as a system in isolation.  Processes need to be created to handle the data in terms of how it passes between frontend components and the backend systems.  Whilst APIs will be provided with standard automations over data to support the technical capabilities of the frontend software components, these will not always deliver all wanted extract transform load (“ETL”) automations of an enterprise or stage the data in the way a business requires for its legacy backend systems to process.

To implement a headless architecture, the legacy monolith architecture must be broken down, to separate the backend.  A concept known as decoupling.  Once decoupled, the system cannot work until new messaging sequences are built to bring the backend and frontend components of the system together again, albeit asynchronously and with greater inherent complexities because there are now more components on the frontend.

The focus of qualifying R&D work

To implement a headless architecture and leverage more transformative modern technologies, an enterprise needs to create a network of webhook proxy systems (a proxy system acts like an external middleware) because the frontend systems are not directly coupled with the backend systems – they will be linked via the newly designed proxy system.  

The frontend system will be configured to send its webhooks to a middleware system, where the integrations codebase for sought after ETL requirements will be designed. The middleware needs to ingest or consume multiple frontend services(e.g. payment notifications, email, new users etc.) and can be designed with specific capabilities.  It requires clear distinctions to be made between different webhook origins and types within the designed codebase.

Once the webhook payloads (transmitted data forming part of a message) are obtained, logic needs to be determined and deployed through the code base – e.g. aggregation, state machine logic (i.e. payment charge succeeded)to deal with a set or expected set of webhooks before sending a transformed payload out to a backend system.  These are not just replicated webhooks with different end points but are an enriched set of capabilities to extract and build out new data structures to suit the needs of a business.

Baseline capabilities

• Headless platforms do not include many built in features and functionalities “out-of-the-box”.  An integrations engineer would need to select the frontend components and then bring them together, so they function as part of a wider system.  Orchestrating this would require a proprietary network of interdependencies to be created using webhooks and webhook proxies between system components selected- seeking new and duplicating legacy interactions between these in a fundamentally different way.
• Headless platforms as a concept are fragmented since the advantages are achieved through separating the front and back ends of the eCommerce platform.  Headless platforms are inherently more complex to establish than conventional monolithic platforms because there become numerous services and applications to accommodate and knit together to operate a headless commerce platform. The possibilities in terms of frontend component selections are vast and growing, giving rise to high uniqueness in terms of choices of bundles to seek to tie together with the backend.  This, taken together with equally unique processing protocols for an enterprise means not every problem is encountered by other eCommerce retailers and there is little information in the public domain or product owner trouble shooting that answers specific issues encountered. It is not a given that the integrations can be set up between the backend ecosystem and the new headless platform.
• Adopting a headless commerce solution will give each enterprise unique challenges.  This is because developers must attempt to pull apart many of the existing and long-standing processes that comprise fulfilment in the legacy monolith architecture.  There is no knowledge baseline for integrating enterprise specific processes in a decoupled system.  Blind spots are inevitable and there are unknowns around which processes might break when making technological changes.

System uncertainty

System uncertainty is high – a software engineer knows the micro service components they wish to leverage. There is information around the configurations of the compatible third-partyAPIs. The software engineer knows how to establish a webhook and build out an automated webhook proxy.

But -

• How to engineer the messaging within and across sets of proxies to stage and build out payloads is not known;
• How to weave together all data processing elements across a decoupled and fragmented frontend with the backend systems is not known.  
• It is not possible to reuse methods established in the legacy monolith platform because the headless platform functions in a fundamentally different way.
• New methods, patterns and capabilities must be established through iterative cycles of planned development sprints.

3 Pillars of eligibility

Remember that for work to qualify, it must meet all 3 pillars of eligibility - technological uncertainty is just one of these pillars. The work must represent a project that seeks and advance through the resolution of technological uncertainty.

For more information on eligibility criteria you can filter resources under the "R&D eligibility" category for relevant insights and downloads.

Think you have an R&D claim?

Understanding the nuances of tax legislation when it comes to R&D tax relief can be hard. If you hit a road bump in preparations, get in touch.

If you’d like to discuss a potential R&D project, book a call to explore your eligibility and start your tax claim journey.

You can understand more around the reason why many businesses value an exploratory call here.

Time to reflect

If you're not sure what to do next, want time to reflect and time to get to know me as an R&D adviser, you can subscribe to my newsletter to received insights and deepen your understanding of this valuable tax relief.

It's none invasive and you can unsubscribe at anytime.

You can subscribe to my newsletter here.