R&D funding for Software

Software projects may qualify for R&D tax relief where they seek an advance in computer science or information technology and involve technological uncertainty that a competent professional could not readily resolve.

Developing a new platform, application or feature is not enough by itself. The important questions are what underlying technological capability the project sought to improve, why established software, frameworks or methods were insufficient, and how the team attempted to resolve the uncertainty.

A company does not have to sell software to undertake software R&D. Qualifying work may arise when software is the subject of the technological advance, when it is developed for internal use, or when software is created or adapted solely as a tool for direct use in a wider qualifying R&D project.

‍

Software R&D at a glance

Information and communication businesses represented approximately 26% of UK R&D tax relief claims and 21% of the total relief claimed in HMRC’s provisional analysis for the 2023–24 tax year.

These figures cover the broader information and communication industry rather than software alone. HMRC also cautions that a claimant’s registered industry code may not reflect the sector in which its R&D was undertaken. The statistics predate the full effect of the merged R&D expenditure credit scheme and Enhanced R&D Intensive Support, which apply to accounting periods beginning on or after 1 April 2024.

What is software R&D?

Software development forms part of computer science and information technology and can fall within the definition of R&D for tax purposes.

HMRC identifies two principal ways in which expenditure on creating software can relate to qualifying R&D:

1. Software is created or adapted solely for direct use in a wider qualifying R&D project. The software does not necessarily need to advance computer science independently where it directly supports the resolution of uncertainty in another field.
2. Developing the software is itself the objective of the R&D project. In this case, the project must seek an advance in computer science or information technology and address technological uncertainty.

It does not matter whether the resulting software is intended to be used internally, licensed to customers or sold. The commercial delivery model does not determine whether the underlying development qualifies.

Software R&D may arise in areas such as:

• Distributed systems
• Data architecture
• Cloud and edge computing
• Cybersecurity and cryptography
• Algorithms
• Systems interoperability
• Real-time processing
• Computer vision
• Internet of Things
• Augmented and virtual reality
• High-performance computing
• Artificial intelligence and machine learning

The presence of one of these technologies does not establish eligibility. The project must still meet the advance-and-uncertainty test.

Can software projects qualify for R&D tax relief?

A software project may qualify where it seeks an advance in underlying technological capability and requires systematic work to resolve uncertainty that could not be readily addressed using publicly available knowledge and established methods.

A strong software eligibility assessment should explain four things.

1. The field of technology

Identify the specific field or subfield involved.

“Software development” is normally too broad. A more useful description could refer to distributed computing, database architecture, cryptography, computer vision, fault-tolerant systems or another clearly defined area.

2. The advance sought

The project must seek an advance in overall technological knowledge or capability, not merely an improvement to the company’s own product.

Examples might include:

• Increasing the scale at which a defined operation can be performed
• Developing a materially different system architecture
• Extending a framework beyond its intended capability
• Achieving a non-trivial improvement in resilience, security or processing efficiency
• Combining technologies where the successful method is not readily deducible

The advance concerns the underlying technology rather than the commercial product, user feature or business model.

3. The technological uncertainty

The company should explain why a competent professional could not readily determine whether the required result was achievable or how it could be achieved.

Software uncertainty can arise around:

• Scalability
• Latency
• Availability
• Fault tolerance
• Data consistency
• Concurrency
• Interoperability
• Security
• Processing efficiency
• Performance under memory, compute or connectivity constraints

A project is not qualifying merely because it is complex, expensive or time-consuming.

4. The work undertaken

The claim should show how the team investigated the uncertainty through activities such as technical analysis, architecture design, experimental development, algorithm design, prototyping, performance testing, failure simulation and comparative testing.

Routine feature development should be separated from the work that directly contributed to resolving the technological uncertainty. HMRC’s software guidance emphasises that only the qualifying parts of a wider commercial project should be treated as R&D.

What could qualifying R&D look like in software?

The following examples are indicators rather than an automatic eligibility list.

HMRC recognises that integrating standard technologies can sometimes qualify where a competent professional cannot readily deduce how the components should be combined to achieve the intended function. Simply having many components, dependencies or interfaces is not enough.

What software work normally does not qualify?

Work is less likely to qualify where it applies established knowledge or focuses primarily on commercial functionality.

Examples include:

• Developing a standard website or mobile application
• Implementing ordinary product features
• Routine API integration
• Configuring commercial software
• Applying an established framework
• User-interface and visual design
• Routine database development
• Data migration using known methods
• Deployment and release activity
• User acceptance testing
• Routine bug fixing
• Maintenance and customer support
• Commercial requirements gathering
• Cosmetic and usability improvements

Testing should be assessed according to its purpose. Testing that feeds results back into experimental development may form part of the R&D. Confirmatory testing undertaken after the technological uncertainty has been resolved should normally be excluded.

HMRC similarly treats deployment and release activity as generally taking place after uncertainty has been resolved, while routine maintenance and minor fault fixing fall outside the R&D boundary unless a new technological uncertainty emerges.

Why the technological baseline changes quickly in software

A problem that involved technological uncertainty several years ago may now be readily resolvable through an established framework, managed cloud service, open-source library or commercial API.

The technological baseline must therefore be established for the period in which the work was undertaken. It is not enough to say that the company had never developed the functionality before.

A credible assessment should consider what was publicly available at the time, including:

• Open-source and commercial products
• Framework and library capabilities
• Cloud-provider services
• Published architectural patterns
• Technical documentation
• Standards and protocols
• Relevant academic or industry research
• Known limitations within the field

The competent professional should explain which available approaches were considered and why they could not readily achieve the intended result.

HMRC expressly notes that software projects which met the R&D definition in an earlier period may not qualify now because technological capability has advanced and previous uncertainties have become readily resolvable.

Can AI and generative-AI development qualify?

Using an existing model, API or commercial AI service does not automatically create qualifying R&D.

A stronger case may exist where a project seeks a material advance in underlying technological capability and requires experimentation to resolve uncertainty, for example:

• Reducing inference latency or compute demand beyond established methods
• Operating reliably under unusual memory, connectivity or edge-computing constraints
• Developing materially new model-evaluation or orchestration methods
• Resolving non-routine uncertainty around privacy, security or reliability
• Integrating models into a larger system where established architectures cannot meet the required performance
• Developing a new computer-vision or classification method where available techniques cannot achieve the necessary accuracy and efficiency

Prompt testing, model selection, retrieval configuration and routine API integration are less likely to qualify by themselves. The claim should identify the technological limitation rather than relying on the fact that artificial intelligence was used.

Kene’s existing AI guide applies the same advance-and-uncertainty test to AI projects and distinguishes genuine technological work from the use of pre-trained models and third-party tools.

Software R&D costs that need particular care

Kene’s qualifying-costs guide explains the full statutory cost categories. Software companies should pay particular attention to the following areas.

Data-licence and cloud-computing costs can qualify under the current schemes where they are employed in activities that directly contribute to resolving scientific or technological uncertainty. Costs attributable only to qualifying indirect activities do not qualify within these categories.

Capitalised software development

Capitalising software-development expenditure in the accounts does not automatically prevent or permit an R&D tax claim.

The accounting treatment is not conclusive. The expenditure must be allowable as a deduction in calculating taxable trading profits, and capital expenditure for tax purposes is excluded from the R&D tax relief schemes. Major internal platform developments and acquired software rights may therefore require a separate tax analysis.

‍

Customer-funded and contracted software development

Software agencies, consultancies, platform providers and technical contractors frequently develop systems for customers. The right to claim should not be assumed from who wrote the code or paid the developers.

Under the current contracted-out R&D rules, the assessment considers the contract and surrounding circumstances. The customer may be able to claim where it intended or contemplated that R&D of the relevant type would be undertaken when it entered into the arrangement.

A supplier may have its own claim where it took the initiative to perform separate R&D that the customer did not intend or contemplate, for example, where an unexpected technological problem emerged while delivering the contracted work.

Relevant questions include:

• What did the customer intend to purchase?
• Was R&D of the relevant type contemplated when the contract was agreed?
• Did the technological problem arise only after development began?
• Which company took the initiative to undertake the additional R&D?
• Was that work separate from the activity contemplated by the customer?
• What do the specification, statements of work and correspondence show?
• Was the contract later varied to include the R&D?

Control of the technical decisions, ownership of source code and financial risk can provide supporting context, but none of those factors is the complete test by itself.

Overseas development teams

Restrictions apply to qualifying payments for overseas contractors and externally provided workers under the current schemes.

A limited exception may apply where necessary conditions for the R&D exist overseas, are not present in the UK and would be wholly unreasonable for the company to replicate here. Lower development costs and the availability of software engineers overseas are not sufficient reasons on their own.

For each overseas team or supplier, retain evidence of:

• Where the development activity was physically undertaken
• The role performed
• Why that location was necessary
• Which UK alternatives were considered
• Whether an exception is being relied upon

HMRC’s own examples distinguish between overseas work required by particular regulatory or operating conditions and work moved abroad merely because suitable engineers are cheaper or easier to recruit.

How to build a credible software R&D case

A strong claim should answer five software-specific questions.

1. What could competent professionals already do?

Describe the public technological baseline at the start of the project. Compare the proposed capability with established frameworks, software products, APIs, algorithms and architectural patterns, not merely with the company’s previous software.

2. What underlying capability was being advanced?

Describe the improvement in computer science or information technology.

Launching a platform, replacing a legacy system or creating a new customer feature is a commercial objective. The claim should identify the underlying performance, architecture, security, data or interoperability capability being advanced.

3. Why were established methods insufficient?

Identify the principal approaches considered and explain their limitations.

A statement such as “no suitable product existed” is rarely enough. The relevant question is why available technologies could not readily be adapted or combined to achieve the intended result.

4. What work addressed the uncertainty?

Connect the uncertainty to architecture decisions, prototypes, experimental code, algorithms, load tests, failure tests, benchmarks and unsuccessful approaches.

Useful records may include:

• Architecture diagrams
• Technical specifications
• Decision records
• Development tickets
• Code and version histories
• Test results and performance benchmarks
• Security and failure-testing records
• Incident reports
• Research notes
• Meeting records
• Project and cloud-cost data

A large repository or ticket history does not prove that all recorded development was R&D. The records should show what was uncertain, what was tested and what the team learned.

5. When did the R&D end?

Identify when the uncertainty was resolved or when work to resolve it stopped.

Deployment, routine feature development, customer onboarding, ordinary maintenance and confirmatory testing after that point should generally be excluded.

Common weaknesses in software claims

Software claims are often weakened by:

• Describing a product rather than a technological advance
• Defining the field only as “software development”
• Comparing the project with the company’s previous version
• Treating project complexity as technological uncertainty
• Claiming routine configuration or integration
• Including deployment and ordinary user acceptance testing
• Failing to explain why standard methods were insufficient
• Using broad staff percentages without supporting logic
• Treating an entire product roadmap as one R&D project

Which scheme and filing rules apply?

For accounting periods beginning on or after 1 April 2024, claims generally fall under the merged R&D expenditure credit scheme or, for qualifying loss-making R&D-intensive SMEs, Enhanced R&D Intensive Support (ERIS).

Software companies should nevertheless check whether claim notification is required, protect the applicable claim deadline and submit the Additional Information Form in the correct sequence.

‍

Funding routes for software innovation

Software companies may be able to access grants, procurement contracts, collaborative programmes or innovation finance.

What makes a strong software funding case?

A competitive software application should explain:

• The technical or operational problem being addressed
• What is materially different from available products and methods
• The technical risk that remains
• The development, testing and validation work required
• Why the project team can deliver it
• How data, cybersecurity, regulation and intellectual property will be managed
• Who will buy or adopt the resulting product
• How the business will fund its own contribution and commercialisation
• What UK economic or societal value the project will create

A new interface, ordinary software feature or speculative application of a fashionable technology is unlikely to create a strong case by itself. Projects may also involve parallel development and integration with corresponding hard tech solutions e.g. for advanced manufacturing.

Patent Box for software companies

Patent Box may be relevant where a software company owns or exclusively licenses a qualifying patent covering a computer-implemented invention and earns profits by exploiting that technology.

Computer programs “as such” are not patentable. However, implementing an otherwise patentable invention in software does not prevent protection. A computer-implemented invention that provides a new technical solution to a technical problem may therefore qualify for a patent.

Potentially relevant income may arise from:

• Selling or downloading patented software
• Licensing patented software
• Selling hardware or systems incorporating the patented software
• Providing qualifying software updates
• Charging for a service that uses patented technology

HMRC’s software examples distinguish qualifying software income from non-qualifying service elements. For example, income from patented downloaded software or qualifying updates can be relevant, while ordinary telephone support may need to be separated.

For SaaS and cloud providers, customers may receive a service rather than purchase or license the software itself. In that situation, the ordinary Patent Box income categories may not apply directly, but the notional-royalty provisions can sometimes bring an appropriate part of the service income into the calculation.

Patent Box applies an effective 10% Corporation Tax rate to relevant qualifying profits, not to total revenue or every profit made by a business holding a patent. The company must meet the ownership or exclusive-licence and development conditions, elect into the regime, identify the relevant IP income and complete the Patent Box profit calculation.

Software businesses should map the opportunity early:

Patent → protected technical functionality → product or service → customer contract → income and costs → underlying R&D

This is particularly important where subscriptions combine software, updates, implementation, support and other services.

‍

Regulation can shape the technical problem

Software development may be affected by data protection, online-safety, accessibility, cybersecurity and sector-specific regulation.

Depending on the product, relevant requirements can include:

• UK GDPR and the Data Protection Act 2018
• The Online Safety Act 2023
• Security requirements for consumer connectable products
• Public-sector website and mobile-app accessibility rules
• Financial-services, healthcare or other regulated-market requirements

The UK GDPR requires data protection to be considered from the design stage and throughout a system or product’s lifecycle. The Online Safety Act imposes duties on regulated user-to-user and search services, while the UK’s consumer-connectable-product regime includes baseline security requirements for products within scope.

Compliance work does not automatically qualify as R&D. Qualifying activity may arise where meeting a requirement creates a genuine technological uncertainty, for example, developing a privacy-preserving architecture that maintains a required level of performance where established methods cannot achieve both objectives.

This section provides a high-level regulatory overview rather than legal, data-protection or product-compliance advice.

Worked example: a resilient real-time event-processing platform

A SaaS company needed to process high volumes of events across several regions while maintaining low latency, consistent ordering and reliable recovery following network interruptions.

The baseline

Available managed queues and established architectural patterns could satisfy individual requirements, but testing indicated that they could not readily achieve the required combination of latency, ordering, deduplication and recovery performance.

The advance sought

The company sought to develop an appreciably improved distributed event-processing capability able to maintain the required performance and consistency under failure conditions.

The technological uncertainties

The development team could not readily determine:

• How to partition workloads without creating unacceptable ordering errors
• Whether duplicate events could be removed within the latency constraint
• How the system should recover after regional or network failure
• Whether consistency could be maintained without excessive compute or memory use
• Which architecture could deliver stable performance as event volume increased

Work undertaken

The team built and compared several architectures, developed alternative partitioning and deduplication methods, performed load and fault-injection testing, analysed unsuccessful approaches and repeatedly modified the system.

Potentially qualifying costs

These could include relevant developer and architect time, experimental cloud-computing capacity, directly used development tools and eligible external specialist work.

Costs outside the claim

Routine user-interface development, production hosting after the uncertainty was resolved, ordinary deployment, customer onboarding, marketing and confirmatory user acceptance testing would generally sit outside the qualifying project.

Eligibility would depend on the actual technological baseline, evidence and expenditure, not merely on describing the system as scalable or cloud-based.

Software R&D in practice: Itec Systems

Itec Systems develops Itris, a proprietary recruitment-software platform used by organisations in the UK and internationally.

The company had previously considered making an R&D claim but was uncertain about how the definition applied to its software development. Kene worked with the team to identify relevant projects, understand the underlying technological activity and connect that work with the associated expenditure.

Results depend on each company’s projects, expenditure and tax position, so this outcome should not be treated as representative of another software business.

How Kene supports software companies

A credible software claim needs to connect the technical work with the tax calculation.

At Kene, we work with technical, product and finance teams to:

• Identify the projects containing genuine technological uncertainty
• Establish the relevant public technological baseline
• Separate qualifying development from ordinary product work
• Review developer time, cloud, data, tools and external development costs
• Assess customer contracts and overseas teams
• Build technical and financial evidence from existing records
• Identify relevant grants, procurement routes and innovation finance
• Assess whether patented software may create a Patent Box opportunity

The aim is a joined-up funding position that reflects what the business actually developed and can support with evidence to maximise the funding opportuntities.

‍

Frequently asked questions

Does developing new software qualify for R&D tax relief?

Not automatically. The project must seek an advance in computer science or information technology and involve technological uncertainty that a competent professional could not readily resolve.

Can SaaS development qualify?

Yes. Whether software is delivered through a subscription, licence, download or internal platform does not determine eligibility. The underlying development must still meet the R&D definition.

Does integrating APIs qualify?

Routine API integration is unlikely to qualify. An integration project may contain R&D where established APIs, protocols or architectural methods cannot achieve the required result and the system interaction creates genuine technological uncertainty.

Does bug fixing qualify?

Routine debugging and maintenance do not normally qualify. Investigating a defect may form part of R&D where it directly contributes to understanding and resolving an underlying technological uncertainty.

Can cloud-computing costs be included?

Potentially. Cloud expenditure may qualify where it is employed in activities that directly contribute to resolving the uncertainty. Routine production hosting and ordinary customer infrastructure should be excluded.

Can outsourced developers be included?

The treatment depends on the contract, whether the customer intended or contemplated the R&D, whether the supplier undertook separate R&D, the relationship between the parties and where the activity was performed.

Can an unsuccessful software project qualify?

Yes. The project does not need to succeed, but the company must still show that it sought a qualifying technological advance and undertook work to resolve genuine uncertainty.

Can AI projects qualify?

They may qualify where the project advances underlying technological capability and resolves non-routine uncertainty. Using a pre-trained model, commercial API or established AI tool is not sufficient by itself.

Can software qualify for Patent Box?

Possibly. The business must own or exclusively license a qualifying patent covering a computer-implemented invention, satisfy the development conditions and earn relevant profit from exploiting the patented technology.

Can grant-funded software development also qualify for R&D tax relief?

Potentially, but the grant and tax regimes have different definitions and cost rules. The grant budget should not simply be copied into the R&D tax calculation. Each activity and cost should be assessed under the relevant rules.