If your agency builds custom integrations between software platforms, you might be leaving money on the table. The kind of work that frustrates your developers, the "this should work but it doesn't" debugging, the proprietary APIs with undocumented behaviour, the data transformation problems that keep your senior dev up at night. That is precisely the kind of work HMRC expects to see in a legitimate R&D claim.
Most agency founders assume R&D tax credits are for pharmaceutical companies or aerospace engineers. They picture labs and white coats. But the legislation is broader than that. It covers any project that seeks to resolve scientific or technological uncertainty. And in the context of a digital agency, that uncertainty often shows up in bespoke integration work.
This article is about when a bespoke integration R&D agency claim works, when it doesn't, and how to structure your claim so it survives HMRC scrutiny.
What Qualifies as R&D in an Integration Project
HMRC uses a specific definition of R&D for tax purposes. It is not about whether your team worked hard. It is about whether they faced a technical challenge that could not be resolved by applying standard industry practice.
The relevant criteria come from the BEIS (Department for Business, Energy and Industrial Strategy) guidelines. To qualify, your project must:
- Seek to achieve an advance in science or technology
- Face scientific or technological uncertainty at the outset
- Attempt to resolve that uncertainty through systematic investigation
- Result in a resolution that was not readily deducible by a competent professional in the field
For an integration project, the "advance" does not need to be world-changing. It just needs to be an advance for your field. If you are connecting a legacy CRM system with a modern ecommerce platform, and the standard connectors fail because the CRM uses a proprietary data structure with no public documentation, the work to build a working integration from scratch could qualify.
The Line Between Routine Integration and R&D
Not every integration qualifies. If you are using standard APIs with published documentation, following the vendor's integration guide, and the work is something any competent developer could replicate, that is routine development. It is not R&D.
The line gets crossed when you encounter genuine technical uncertainty. Examples include:
- An API that behaves inconsistently across different data volumes or transaction types
- A proprietary system with no public documentation where you must reverse-engineer the data format
- Data transformation requirements that exceed the capabilities of existing middleware tools
- Performance constraints that require novel caching or queuing architectures
- Security requirements that conflict with the platform's intended data flow
A 12-person digital agency in Bristol we worked with spent three months building a custom integration between a niche property management system and a CRM platform. The PMS vendor had no public API. The data export was a flat file with undocumented fields. The team had to analyse thousands of records, identify patterns, and build a parser that could handle edge cases the vendor had never documented. That is R&D.
Common Integration Scenarios That Qualify
Let me give you some concrete examples from agency work we have seen qualify successfully.
Legacy System Integration
A PR agency needed to connect a 15-year-old media monitoring database with a modern reporting dashboard. The database used a proprietary binary format. No off-the-shelf connector existed. The development team had to reverse-engineer the data structure, build a custom extraction tool, and design a transformation layer that could handle the database's inconsistent date formats and character encoding issues. That work qualified for R&D relief.
An advertising agency was building a campaign management platform that needed to pull data from Google Ads, Facebook Ads, LinkedIn, TikTok, and a dozen smaller ad networks. Each platform had different data schemas, different refresh rates, and different authentication protocols. The team had to build a unified data model and a synchronisation engine that could handle partial failures, rate limiting, and inconsistent data quality across all sources. That systematic work to resolve the technical uncertainty qualified.
A creative agency working with a luxury retail client needed to integrate a bespoke inventory management system with Shopify Plus. The inventory system used a non-standard XML schema that included nested elements the Shopify API could not accept. The team built a custom middleware layer that transformed the XML into Shopify-compatible JSON, handled stock-level reconciliation, and managed error recovery when either system was unavailable. The technical challenge was in the data transformation and error handling logic, which went beyond standard integration patterns.
What Does Not Qualify
Let me save you some time and HMRC correspondence. The following do not qualify:
- Installing and configuring a standard plugin or connector
- Following a vendor's published integration guide step by step
- Customising the user interface of an existing integration
- Building a simple data export/import using CSV files
- Any work that a competent developer could complete without experimentation
The key test is: did your team face uncertainty that required systematic investigation to resolve? If the answer is no, you do not have a claim.
How to Document Your Integration R&D Work
Documentation is where most agency R&D claims fall apart. HMRC will ask for evidence that technical uncertainty existed and that you attempted to resolve it systematically. Without documentation, your claim is a guess. And HMRC does not accept guesses.
Here is what you need to capture for each qualifying project:
Project Records
Keep a running log of the technical challenges encountered during the integration build. This does not need to be formal. A Slack channel, a Trello board, or a Google Doc updated weekly by your lead developer is fine. What matters is contemporaneous evidence that shows what you were trying to solve and when.
For example: "Week 3: The PMS API returns a 500 error when we send orders with more than 15 line items. Vendor support says this is a known issue but cannot give a fix date. We are testing alternative payload structures to work around it." That is evidence of technical uncertainty.
Technical Notes
Capture the approaches you tried and why they failed. HMRC wants to see that you went through a genuine process of elimination. A note that says "tried batch processing, failed due to API rate limits. Tried parallel processing, failed due to race conditions. Solved with queue-based architecture using Redis" tells a clear story of systematic investigation.
Time Tracking
You need to separate qualifying R&D time from routine development time. If your developers use a time tracking tool like Harvest or Toggl, create a specific project code for R&D work. If you use Xero Projects or QuickBooks Time, tag qualifying hours separately. The key is that you can show HMRC exactly how many hours went into resolving technical uncertainty.
Cost Records
For an SME R&D claim, qualifying costs include:
- Staff costs (salaries, employer NI, pension contributions) for the time spent on qualifying work
- Software licenses directly used in the R&D (e.g., development tools, testing environments)
- Subcontractor costs (subject to the 65% rule for externally provided workers)
- Consumables (cloud hosting, API credits, testing data)
You need to be able to identify these costs separately from your general operational spend. A good chart of accounts with specific R&D cost codes makes this straightforward.
The Numbers: What a Claim Looks Like
Let me give you a worked example. A 15-person digital agency in Manchester's Northern Quarter spends six months building a custom integration between a client's legacy ERP system and a modern ecommerce platform. The qualifying R&D work takes 400 hours across two senior developers.
Staff costs for that 400 hours: £28,000 (salary plus employer NI and pension). Software licenses and cloud hosting directly attributable to the R&D: £3,200. Subcontractor costs for a specialist data architect: £12,000 (65% of this qualifies, so £7,800).
Total qualifying expenditure: £39,000. Under the SME scheme, the enhanced deduction is 186% of that figure, giving a total deduction of £72,540. If the agency is paying 19% corporation tax on profits up to £50k, the tax saving is approximately £13,783. If the agency is loss-making, it can surrender the loss for a cash credit of up to 14.5% of the enhanced expenditure, which would give a cash payment of approximately £10,518.
Those numbers are real. That is not theoretical. That is cash back in your business or tax you do not pay.
Common Mistakes Agency Founders Make
I see the same errors repeatedly. Here are the ones to avoid.
Claiming for Client-Funded Work
If your client paid you to build the integration, you cannot claim R&D tax credits on the costs. The relief is for the company bearing the financial risk of the R&D. If the client is paying you regardless of outcome, the risk sits with them, not you. There are exceptions for subsidised expenditure, but the general rule is: if the client paid for it, you cannot claim it.
The exception is where you are building the integration as part of your own product development, not a client project. If you build a reusable integration framework that you then license to multiple clients, the development costs may qualify.
Not Separating R&D Time from BAU
HMRC will ask for a breakdown of qualifying time versus business-as-usual time. If your developers spend 40% of their week on R&D and 60% on routine client work, you need to show that split. A single time code that lumps everything together will not work.
Ignoring the Subsidised Expenditure Rules
If you receive a grant, a subsidy, or a client payment specifically for the R&D work, the subsidised expenditure rules can reduce or eliminate your claim. This is complex territory. If your project has any external funding, speak to your accountant before filing.
Claiming for Work That Failed
This one surprises people. Failed projects can qualify for R&D. The test is whether you faced technical uncertainty, not whether you resolved it. If you spent six months trying to build an integration that ultimately proved impossible with the available technology, that work can still qualify. The key is documentation showing what you tried and why it failed.
How to Prepare a Claim
If you think your agency has qualifying integration work, here is the process we recommend.
- Review your project list from the last two accounting periods. Identify any integration projects that involved custom builds, undocumented APIs, proprietary data formats, or performance challenges that required novel solutions.
- Interview your lead developers. Ask them which projects required genuine problem-solving. What kept them up at night? What did they have to experiment with before finding a solution? Their answers will tell you where the R&D is.
- Gather contemporaneous documentation. Pull together time logs, technical notes, Slack archives, and any written records that show the technical challenges and the approaches tried.
- Calculate qualifying costs. Work with your accountant to identify the staff time, software, and subcontractor costs that relate directly to the qualifying work.
- Prepare a technical report. This is the document that explains to HMRC what the technical uncertainty was, how you approached it, and what the outcome was. A good technical report is the difference between a smooth claim and an HMRC enquiry.
- Submit the claim with your corporation tax return. The claim is made on the CT600 form, with supporting calculations in the computation.
As specialist agency accountants working exclusively with agency founders, we see R&D claims come through our doors in two states: well-documented and defensible, or thrown together at year-end with no supporting evidence. The former gets you a tax saving. The latter gets you an HMRC letter asking for more information.
If your agency builds bespoke integrations and you have not considered an R&D claim, you are probably leaving money on the table. The key is to start documenting the technical challenges now, while the work is fresh in your developers' minds, rather than trying to reconstruct it eighteen months later when HMRC asks.
For more on how R&D tax credits apply to agency work, read our guide on tax and compliance for agencies. If you want to discuss whether your integration work qualifies, get in touch.
Need specialist accounting for your agency?
We work exclusively with agency founders. Book a free call to talk through your tax position, salary structure, or any finance question. No jargon, no hard sell.
