If your e-commerce agency builds headless commerce solutions, you could be leaving thousands of pounds on the table. The headless commerce r&d tax credit is a genuine relief that many agency founders overlook, simply because they don't realise their day-to-day technical work qualifies.

HMRC's R&D tax relief scheme is not just for pharmaceutical companies or aerospace engineers. It applies to any business that undertakes projects seeking to resolve scientific or technological uncertainty. For e-commerce agencies building headless architectures, that uncertainty shows up more often than you might think.

This post covers what qualifies, what doesn't, and how to structure your claim so HMRC doesn't push back.

What Is Headless Commerce, Really?

Headless commerce separates the front-end presentation layer from the back-end commerce functionality. Instead of a monolithic platform like a standard Shopify or Magento setup, the front-end communicates with the back-end via APIs.

This gives agencies and their clients freedom. You can build a React front-end that pulls product data, cart logic, and checkout flows from a headless CMS or commerce engine like CommerceTools, BigCommerce, or a custom-built solution.

The result is faster page loads, better omnichannel experiences, and the ability to update the front-end without touching the back-end. But it also introduces genuine technical challenges that HMRC recognises as qualifying R&D activity.

Does Building a Headless Commerce Site Qualify for R&D?

The short answer: it depends on what you're doing. Simply installing a headless CMS and connecting it to a standard Shopify storefront does not qualify. That's routine integration work, not R&D.

But if you're solving problems that no standard documentation or off-the-shelf solution can address, you're likely in qualifying territory. HMRC looks for projects where you had to overcome technical uncertainty by designing new processes, adapting existing technology in a novel way, or creating bespoke solutions to problems that aren't widely documented.

Let's look at some real scenarios.

Scenario 1: Custom API Orchestration Layer

Your client wants a headless setup that pulls inventory from three separate warehouses, each using a different ERP system. The standard API connectors don't handle real-time inventory reconciliation across disparate systems. You build a custom orchestration layer that normalises data formats, handles latency, and resolves conflicts when two systems report different stock levels.

This qualifies. You faced technological uncertainty around data normalisation, latency management, and conflict resolution. No off-the-shelf solution existed. You designed a novel approach.

Scenario 2: Optimising Core Web Vitals on a Headless Site

Your headless build passes Lighthouse audits but still fails Google's Core Web Vitals on mobile. You spend weeks optimising server-side rendering, implementing predictive prefetching, and building a custom caching layer that respects session data. Standard caching plugins don't work because your architecture is decoupled.

This qualifies. The uncertainty was around achieving specific performance thresholds in a decoupled environment where standard solutions failed. You developed a novel caching and rendering strategy.

Scenario 3: Integrating a Headless CMS with a Legacy ERP

Your client runs a 15-year-old ERP system that was never designed for headless commerce. You build a middleware layer that translates between modern GraphQL APIs and the ERP's proprietary protocol, handling data transformation, error handling, and idempotency. The ERP vendor offers no support for this integration.

This qualifies. You resolved technological uncertainty around protocol translation and data integrity in a constrained environment.

Scenario 4: Standard Headless Setup with No Novelty

You install a headless CMS, connect it to a standard payment gateway, and build a React front-end using a well-documented starter kit. Everything works as documented. No custom solutions were needed.

This does not qualify. There was no technological uncertainty. You followed established patterns.

What HMRC Looks For in Headless Commerce R&D Claims

HMRC's R&D teams have become more sophisticated. They know the difference between genuine technical innovation and routine development. For a headless commerce r&d tax credit claim to succeed, you need to demonstrate three things:

  • Technological uncertainty: You didn't know at the start whether the solution was achievable within the constraints. Standard approaches didn't work.
  • Systematic resolution: You didn't guess. You tested hypotheses, iterated, and documented what you tried.
  • Competent professional: A skilled developer in your field would also have been uncertain. If any competent developer could have solved it with standard tools, it's not R&D.

This last point trips up many agency founders. You might think "any good developer could have figured that out." But if the solution required novel thinking, custom code, and genuine problem-solving, it qualifies. HMRC's test is whether the outcome was not readily deducible by a competent professional working in the field.

What Doesn't Qualify

Let's be clear about what HMRC will reject. Routine work, even if technically complex, does not qualify if it follows established patterns. Examples include:

  • Installing and configuring a headless CMS like Contentful or Strapi using their standard documentation
  • Building a standard e-commerce front-end in React or Vue using established component libraries
  • Integrating standard payment gateways like Stripe or PayPal using their SDKs
  • Migrating from one monolithic platform to another without novel technical challenges
  • Performance optimisation that uses standard caching plugins or CDN configurations

HMRC also excludes work that is purely commercial or aesthetic. If you're making a site look better or converting better, that's marketing, not R&D. The qualifying work must be technological in nature.

How to Structure Your Claim

If you're an e-commerce agency claiming R&D tax credits for headless commerce work, structure your claim around specific projects. Don't claim a blanket percentage of your development costs. HMRC expects project-level detail.

For each qualifying project, document:

  • The technical uncertainty you faced at the start
  • The standard approaches you tried and why they failed
  • The novel solution you developed
  • The time spent by each team member on qualifying activities
  • The costs incurred (salaries, subcontractors, software, consumables)

Use project management tools like Jira or Trello to track time against specific R&D tasks. Keep Slack threads, code commits, and design documents that show the iterative process. HMRC can ask for this evidence, and having it ready makes your claim much stronger.

The Numbers: What Could Your Agency Claim?

Let's work through a realistic example. A 10-person e-commerce agency in Manchester Northern Quarter builds a headless commerce solution for a retail client. The project runs for four months. Three developers and one project manager work on qualifying activities.

Qualifying costs:

  • Developer salaries (including employer NI and pension): £63,400
  • Project manager time on R&D coordination: £14,700
  • Subcontractor costs for specialised API work: £22,100
  • Software licenses directly used in the R&D: £3,800

Total qualifying expenditure: £104,000

Under the SME R&D scheme, the enhanced deduction is 186% of qualifying costs. That gives you an additional deduction of £104,000 x 86% = £89,440. If your agency is profitable and paying corporation tax at 19%, that extra deduction saves you £89,440 x 19% = £16,994 in tax.

If your agency is loss-making, you can surrender the loss for a payable tax credit of up to 10% of the surrenderable loss. That's real cash in your bank account.

For a 10-person agency, a single qualifying project can yield £15,000 to £20,000 in tax savings or cash. Over a year with multiple qualifying projects, that adds up quickly.

Common Mistakes E-commerce Agencies Make

We've seen agencies make the same mistakes repeatedly. Avoid these:

Claiming for routine maintenance. Bug fixes, security patches, and standard updates are not R&D. Only claim for projects where genuine uncertainty existed.

Including non-qualifying work in the same project. If your headless build includes both qualifying API work and standard front-end development, separate the costs. Claim only the qualifying portion.

Not documenting uncertainty. HMRC wants to see what you didn't know and how you figured it out. If you don't have records, your claim is weak.

Claiming for work that's already been funded. If the client paid you for the R&D work, you can still claim. But if the client received a grant or subsidy specifically for the R&D, that complicates things. Check with your accountant.

Assuming headless work always qualifies. It doesn't. Be honest about which projects genuinely involved technological uncertainty. HMRC can and does investigate claims.

How to Start the Process

If you think your e-commerce agency has qualifying headless commerce R&D, start by reviewing your last 12 months of projects. Look for the ones where your team spent significant time solving problems that had no obvious solution.

Talk to your lead developers. Ask them: "Which projects had you scratching your head? Where did standard approaches fail?" Those are your qualifying projects.

Then, work with an accountant who understands both R&D tax credits and the agency world. As ICAEW qualified accountants, we've helped agencies claim over £2M in R&D tax credits. We know how to structure claims that HMRC accepts.

If you're unsure whether a specific project qualifies, get in touch. We'll review it with you. The initial conversation costs nothing, and it might uncover thousands in relief you didn't know existed.

The Bottom Line

Headless commerce work often qualifies for R&D tax credits, but only when it involves genuine technological uncertainty. Don't claim for routine builds. Do claim for the hard problems your team solved.

The headless commerce r&d tax credit is a legitimate relief for e-commerce agencies doing genuinely innovative work. If you're building custom API layers, solving performance problems in decoupled architectures, or integrating systems that weren't designed to work together, you should be claiming.

Get your documentation in order. Separate qualifying from non-qualifying work. And talk to an accountant who knows what they're doing.

Your agency's innovation should pay off in more ways than one.