R&D Tax Credit for Software Development

Last reviewed October 14, 2026

Software development is one of the most common — and most underutilized — areas of qualifying activity for the federal R&D tax credit under IRC Section 41. If your company builds software and faces technical challenges that require experimentation, you are likely leaving money on the table.

This page explains which software development activities qualify, what expenses you can include, and how the credit calculation works for software companies.

Why software development qualifies

The IRS applies a four-part test to determine whether an activity constitutes qualified research. Software development frequently satisfies all four parts:

• Permitted purpose. The work must aim to create a new or improved business component — a product, process, technique, formula, or invention. Building new software features, redesigning system architecture, or developing proprietary algorithms all serve a permitted purpose.
• Technological in nature. The work must rely on principles of engineering, computer science, or another hard science. Software development is inherently technological — it draws on computer science, mathematics, and engineering disciplines.
• Technical uncertainty. At the outset, there must be uncertainty about the capability, method, or design. This does not mean the project must be groundbreaking research — it means the developer does not know in advance whether a particular approach will work, how to achieve a specific performance target, or what the optimal architecture will be.
• Process of experimentation. The developer must evaluate alternatives through modeling, simulation, systematic trial and error, or other methodical approaches. Iterative development cycles where engineers test hypotheses, benchmark approaches, and refine designs all count.

Most software companies already work this way. The challenge is not whether you qualify — it is identifying and documenting the specific activities that meet the test.

Qualifying software development activities

The following types of work commonly satisfy the four-part test:

• New feature development — Building functionality that did not previously exist, where the development team faces uncertainty about architecture, performance, or feasibility.
• Architecture redesign — Reworking system architecture to achieve scalability, reliability, or performance goals that the existing design cannot meet.
• Algorithm development — Creating or significantly improving algorithms for search, recommendation, optimization, data processing, or machine learning.
• Performance optimization — Engineering work to reduce latency, improve throughput, or lower resource consumption when the path to achieving targets is uncertain.
• Platform migrations — Moving systems between technology stacks, cloud providers, or database engines when the migration involves significant technical uncertainty.
• API development — Designing and building APIs that must handle complex data transformations, authentication schemes, or integration requirements where the approach is not straightforward.
• Database engineering — Designing data models, query optimization strategies, or storage architectures to handle new requirements around scale, speed, or data complexity.
• DevOps and infrastructure automation — Building deployment pipelines, infrastructure-as-code systems, or monitoring frameworks that require solving novel technical problems.
• Security engineering — Developing new authentication systems, encryption implementations, or threat-detection mechanisms that involve technical uncertainty in their design or effectiveness.

Real-world examples

These scenarios illustrate how the four-part test applies to everyday software development work:

• A SaaS company rebuilding its search engine to handle 10x query volume while maintaining sub-200ms response times. The team evaluated multiple indexing strategies, tested different caching architectures, and benchmarked several query optimization approaches before arriving at a solution.
• A fintech startup developing a real-time fraud detection system that must process thousands of transactions per second with low false-positive rates. The engineers experimented with multiple machine-learning models and feature-engineering approaches.
• An e-commerce platform migrating from a monolithic application to a microservices architecture. The team faced uncertainty about service boundaries, inter-service communication patterns, and data consistency strategies.
• A healthcare technology company building a HIPAA-compliant data pipeline that must process and de-identify patient records at scale. The engineers evaluated several encryption and tokenization approaches to meet both performance and compliance requirements.

Activities that do not qualify

Not all software work meets the four-part test. The following activities typically fall outside qualified research:

• Routine maintenance and updates — Applying patches, updating dependencies, or performing standard system upkeep.
• Bug fixes without technical uncertainty — Fixing defects where the root cause and solution are readily identifiable using standard debugging techniques.
• UI reskinning and cosmetic changes — Changing colors, fonts, layouts, or visual styling without underlying technical challenges.
• Data entry and content management — Adding, editing, or migrating content within existing systems.
• Testing without experimentation — Running tests that verify known functionality rather than evaluating uncertain technical approaches.
• Installing or configuring third-party software — Setting up off-the-shelf tools, SaaS products, or open-source libraries without substantial customization.

Qualifying expenses for software companies

Once you identify qualifying activities, the next step is determining which expenses are eligible as qualified research expenses (QREs):

Developer wages (W-2 employees)

W-2 wages paid to software engineers, architects, data scientists, DevOps engineers, and other technical staff who perform, directly supervise, or directly support qualified research. If an employee splits time between qualifying and non-qualifying work, only the qualifying portion of their wages is included.

Contractor payments (65% rule)

Payments to US-based contractors performing qualified research on your behalf are included at 65% of the amount paid. The contractor must be doing work that meets the four-part test, and your company must retain substantial rights to the results.

Cloud infrastructure used during R&D

Cloud compute, storage, and networking costs consumed during qualified research activities can qualify as supply expenses. This includes development and staging environments, CI/CD pipeline compute, load-testing infrastructure, and machine-learning training runs — as long as the resources are used for R&D rather than production.

Development tools and licenses consumed

Costs for software tools, platforms, and licenses used directly in qualified research can qualify as supply expenses when they are consumed in the research process. Examples include specialized testing tools, profiling software, and cloud-based development environments.

How TaxCredit4U helps software companies

TaxCredit4U is a self-service platform built to make the R&D tax credit accessible to software companies of all sizes. Here is how it works:

• Guided project entry. You enter your R&D projects, describe the technical uncertainties involved, and specify the employees and costs associated with each project. The platform walks you through exactly what information is needed.
• Credit method questionnaire. The platform guides you through a questionnaire to determine whether your company should use the Alternative Simplified Credit (ASC), the Regular Research Credit (RRC), or both — and calculates each method so you can compare.
• IRS-ready documentation. TaxCredit4U generates a complete study report with project narratives, expense breakdowns, and the calculations needed to support your Form 6765 filing.
• CPA review. Every study is reviewed by an R&D tax credit specialist before delivery, so you can file with confidence.

The entire process is completed online. There are no lengthy consulting engagements, no percentage-of-credit fees, and no surprise costs.

Frequently asked questions

Does fixing bugs count as R&D?

Only if the fix involves genuine technical uncertainty. A straightforward bug fix where the solution is readily apparent does not qualify. However, if a bug reveals a deeper architectural problem that requires evaluating multiple uncertain approaches or developing a novel solution, that investigative work can qualify as R&D.

Can cloud hosting costs qualify as R&D expenses?

Yes. Cloud infrastructure costs — such as compute instances, storage, and networking — can qualify as supply expenses under IRC Section 41(b)(2) when they are directly tied to qualified research activities. The key requirement is that the cloud resources must be consumed or used during the R&D process itself, not for production workloads.

Do offshore developers qualify for the R&D tax credit?

No. The R&D tax credit under IRC Section 41 applies only to research activities performed within the United States. Wages paid to developers working outside the US — whether employees or contractors — do not count as qualified research expenses, regardless of where the company is headquartered.

What documentation do software companies need for the R&D tax credit?

Software companies should maintain git commit histories, sprint and project management records (Jira, Linear, etc.), architecture decision records, design documents, time tracking data showing hours spent on qualifying activities, and any internal documentation of technical challenges and the alternatives evaluated. Contemporaneous records are always stronger than reconstructed ones.