R&D tax relief for SaaS companies depends on the technical work, not the business label. A new feature, an ambitious roadmap or a difficult implementation is not automatically a qualifying project. Start with the advance sought and the uncertainty the team tried to resolve.
This guide focuses on software eligibility and evidence. For accounting periods, schemes, calculations and filing steps, read R&D tax credits: eligibility and claim requirements.
Government guidance checked on 23 October 2026. Eligibility and filing obligations depend on the company, relevant dates and facts.
Describe the technical project, not the product pitch
The government’s R&D definition guidelines focus on an advance in science or technology and uncertainty that a competent professional cannot readily resolve. Commercial novelty and progress in the company’s own knowledge are not sufficient by themselves.
A useful starting document separates the product goal from the technical question. “Customers need a faster dashboard” describes a commercial objective. The engineering assessment must explain the underlying capability, existing approaches, technical constraints and investigation required.
A practical technical assessment record
| Question | Evidence to assemble |
|---|---|
| What capability existed? | Relevant public knowledge, existing architecture and established approaches considered. |
| What advance was sought? | A specific technical objective with a measurable description of the intended capability. |
| What was uncertain? | The problem the competent professional could not readily resolve and why. |
| What work addressed it? | Experiments, tests, prototypes, analysis, failed approaches and decisions. |
| When did the work change? | A dated record of investigation, resolution, abandonment or movement into routine delivery. |
This is a practical evidence structure, not a government checklist or an automatic eligibility decision. Ask the technical lead to explain the work in plain terms and retain the supporting detail for review.
Separate investigation from routine delivery
A SaaS roadmap may contain research, ordinary engineering, support, design and commercial tasks. Do not label the whole roadmap as R&D because one workstream involved uncertainty. Record how the relevant project and activities were identified, including work that falls outside them.
Routine configuration, known implementation methods and standard integrations need to be distinguished from work addressing a qualifying uncertainty. The assessment depends on the actual circumstances, including what was readily available to a competent professional.
Illustrative software scenarios
Scenario A: a team changes a dashboard layout and connects an established payment API using documented methods. The cost and effort alone do not establish qualifying R&D. The assessment would need a relevant technical advance and uncertainty, not just a new customer feature.
Scenario B: a team investigates a specific processing constraint after established approaches fail under its technical requirements. Keep the baseline, alternatives, test results and professional assessment. Those facts may justify further eligibility review, but this example does not declare the project eligible.
The same discipline applies to AI. Distinguish using an available model from investigating a technical capability that meets the relevant definition. A product’s AI branding is not evidence for a claim.
Connect the technical file with finance records
Once the relevant activities and dates have been assessed, map people, costs and supporting records to them. A project code, payroll allocation or cloud invoice needs an explanation of what the amount relates to and how it was calculated.
Refer to HMRC’s qualifying expenditure guidance for the categories and conditions. Separate production hosting, routine support and other activity from proposed qualifying costs. Review contracted work and overseas costs rather than assuming the same treatment applies to every supplier.
Keep a usable evidence trail
- Ask the technical lead to record the problem and baseline while the work is fresh.
- Link experiments and decisions to the technical question, not just the release name.
- Retain evidence of failed approaches as well as successful outcomes.
- Document the basis for time and cost allocations.
- Reconcile project dates and costs to the claim schedules.
- Record unresolved questions before any claim is submitted.
Do not invent a technical narrative after the event or treat every ticket marked “innovation” as evidence. A clear record should allow the reviewer to understand what the team attempted, why it was uncertain and where the work stopped being investigative.
Frequently asked questions
Does a SaaS business automatically qualify for R&D tax relief?
No. The technical project must meet the relevant R&D definition, and the company, costs and claim process must also satisfy the applicable rules. The SaaS label, subscription revenue or use of modern technology does not prove eligibility.
Does a difficult software project count as R&D?
Difficulty alone is insufficient. Explain the advance sought, the scientific or technological uncertainty and why a competent professional could not readily resolve it using available knowledge. Separate that work from commercial and routine delivery problems.
Can work using AI or third-party APIs qualify?
Not automatically. Record the specific technical advance and uncertainty, the existing capability considered and the investigative work performed. Using an AI tool or integrating standard components does not itself establish qualifying R&D.
What evidence should the engineering team keep?
Useful evidence can include a dated technical baseline, investigation notes, experiments, tests, failed approaches, technical decisions and a record of who assessed the work. The file should explain what happened rather than relying only on feature tickets or a marketing description.
Can we claim all developer salaries or cloud spending?
No. Review eligible cost categories and allocate amounts to qualifying activities using supportable records. Routine delivery, production and other non-qualifying work must be separated. The treatment of each cost depends on the applicable rules.
Does an unsuccessful project fail the R&D test?
Not simply because it failed. The technical assessment concerns the work undertaken and the relevant definition, not only a successful commercial launch. Costs and procedural eligibility still require separate review.
Where do the scheme and filing rules fit?
Technical eligibility is only one part of a claim. Use our R&D tax credits guide to review accounting-period rules, scheme selection, claim notification and additional information, then confirm the company’s position with the appropriate adviser.
Get the evidence organised before claiming
Consult EFC can discuss the available finance records and the scope of claim-readiness support. Technical assessment, tax calculations and filing responsibilities must be agreed expressly. Discuss your requirements. For the wider reporting function, see fractional CFO support for SaaS businesses.
About the author: Kishen Patel ACA, founder of Consult EFC. View the ICAEW member profile.
Not sure where your business stands right now?
Book a free 30-minute call with Kish. Bring your numbers, your questions, or just your situation. You will leave with a clearer picture than you arrived with.
Book a Free Strategy Call
Over 12 years across Big Four audit, Investment Banking, and corporate advisory. Kish works with SaaS founders, tech companies, and ambitious UK SMEs from £1M to £50M in revenue on fundraising, valuations, exit planning, and financial strategy. ICAEW regulated. Big Four trained. Based in London.