Search for “R&D tax credit software” and you'll run into two different conversations at once. One asks whether software development qualifies for the federal R&D tax credit. The other asks which software tool should help you claim it.

While tools are crucial for tracking and filing your claims, the first question is where this conversation actually needs to start. It comes up far more often for founders, CTOs, and engineering leaders looking into the R&D tax credit. The encouraging news is that many software companies perform qualifying research without realizing it.

The IRS has detailed rules for software development, including a separate standard for software built primarily for internal business operations. If your software company is still in the learning stages of this process, first have a look at our Developer’s Guide to R&D Development for Software Teams and the IRS’ Four-Part test. For a broader understanding of what Qualified Research Expenses (QREs) are, start with our overview, The R&D Tax Credit Qualified Expenses Guide.

This guide walks through what qualifies, what usually doesn't, where internal-use software changes the analysis, and how software companies should claim the credit under the current post-One Big Beautiful Bill Act (OBBBA) rules:

  • Does software development qualify for the R&D tax credit?
  • What software activities qualify (and which don’t)?
  • How can internal-use software (IUS) qualify through the ‘High-Threshold of Innovation Test’?
  • What are software R&D expenses (QREs) for software companies?
  • Do you need R&D tax credit software to claim it?
  • How do software companies claim the credit in 2026?
  • Where to go next

Does Software Development Qualify for the R&D Tax Credit?

Yes, software development can qualify for the R&D tax credit when it meets the IRS's four-part test under IRC Section 41. Qualifying work involves resolving technical uncertainty through a process of experimentation while developing or improving software functionality, performance, reliability, or quality. One of the biggest misconceptions about the credit is that software has to be groundbreaking. It doesn't.

The IRS applies the same four-part test to software that it applies to other qualified research. The work must:

  1. Seek to develop or improve a business component
  2. Rely on principles of computer science or another hard science
  3. Involve technical uncertainty
  4. Use a process of experimentation to evaluate potential solutions.

The IRS also applies that test separately to each business component rather than treating an entire engineering organization as one project. For software companies, that often looks familiar:

  • Your engineering team debates two database architectures because neither clearly solves a performance bottleneck.
  • Developers prototype different synchronization methods before choosing one.
  • The team builds several authentication approaches before settling on a secure implementation.

These examples are experiments and easier to distinguish as QREs. By contrast, writing routine configuration code after every major technical decision has already been made usually doesn't satisfy the same standard.

If your company already follows an engineering workflow with design documents, architecture reviews, sprint planning, and testing records, you may already create much of the evidence needed to support qualifying projects.

What Software Activities Qualify (and Which Don't)?

Qualifying software work usually involves solving technical problems through experimentation. Developing new algorithms, designing system architecture, improving scalability, building APIs, and strengthening security can qualify. Routine bug fixes, cosmetic interface updates, simple configuration work, and ordinary maintenance generally do not.

Founders often ask a simpler question: “Can my developers' work count?” The easiest way to think about it is whether engineers needed to evaluate competing technical approaches to resolve uncertainty:

Often qualifies

Usually doesn't qualify

Designing a new system architecture

Cosmetic UI updates

Building a new recommendation algorithm

Routine bug fixes after commercial release

Creating APIs that solve technical integration challenges

Simple configuration work

Improving application scalability through experimentation

Data entry or content migration

Developing new authentication or security methods

Ordinary maintenance and support

Performance optimization requiring technical alternatives

Customer-specific adaptations without new technical uncertainty

 

You may notice here that testing appears on both sides of the broader software lifecycle. Testing can qualify when engineers use it to evaluate competing technical approaches. However, testing usually does not qualify when it simply verifies that finished software works as intended after the technical uncertainty has already been resolved. The IRS specifically excludes research conducted after commercial production from the credit, including certain debugging activities that occur after production begins.

Software examples that often qualify

Imagine a SaaS company rebuilding its search engine. The team evaluates several indexing strategies, benchmarks performance under different workloads, and changes the underlying architecture before finding an acceptable solution. That project often looks much stronger than a routine update that simply adds another filter to an existing search page.

Another common example involves cloud infrastructure. Suppose engineers redesign distributed caching because current latency prevents customer growth. They test several caching approaches before settling on one. The technical uncertainty matters more than whether another company has solved a similar problem elsewhere.

Software examples that usually don't qualify

Some work falls into excluded categories even when talented developers perform it. The IRS points to activities such as adapting existing software to one customer's requirements, duplicating existing functionality, conducting routine studies, and performing certain post-production work as excluded activities.

The distinction between these helps explain why engineering payroll rarely becomes 100% qualified research expense. The project usually contains both qualifying and non-qualifying work.

Internal-Use Software: The Qualification Most Guides Skip Over

Software developed primarily for your own internal operations faces a stricter standard than software built for customers. Internal-use software must satisfy the normal qualified-research rules and the IRS's “high threshold of innovation” test, which requires innovation, significant economic risk, and no commercially available alternative that meets the same need.

This is where software companies often get surprised, either by its existence or by the additional rules. Treasury Regulation Section 1.41-4(c)(6) defines internal-use software as software developed primarily for general and administrative functions that support the business. Some examples include financial management systems, human resources software, and support-service applications built mainly for internal operations.

For a real world example of successful tax credit qualification, look at independent bookpublisher, Microcosm Publishing. With Arvo’s services, they discovered that their software development and data systems work were easy R&D tax credit wins.

To qualify, internal-use software has to clear another test:

The High Threshold of Innovation

Requirement

What it means

Innovative

The software delivers a substantial and economically significant improvement

Significant economic risk

The company commits substantial resources while facing real technical uncertainty about recovering those costs

Not commercially available

Comparable software cannot simply be purchased, leased, or licensed for the intended purpose without meaningful modification

 

The rules with dual-function software

Many modern SaaS products blur the line between customer-facing and internal software. The IRS calls this dual-function software (DFS), and the regulations presume this software is IUS unless the company identifies the portion that serves third parties.

An e-commerce platform is a great example of DFS. Customers browse products and place orders through the same system that employees use to manage inventory and fulfill shipments.That customer-facing subset avoids the high-threshold test, while the remaining internal portion still has to satisfy it.

The IRS even provides a safe harbor that can allow taxpayers, under specific conditions, to include 25% of certain remaining dual-function software expenses after identifying third-party functionality.

Let’s go over some common scenarios and what will likely result:

  • Software sold or licensed to customers

    • Usually not internal-use software

  • Software that lets customers interact with your platform

    • Often treated as non-IUS

  • Software intended mainly for HR, accounting, or internal operations

    • Internal-use software rules usually apply

  • Software that contains both customer-facing and internal features

    • Analyze it as dual-function software

Software R&D Expenses That Actually Count

For software companies, qualified research expenses (QREs) usually begin with wages paid to developers, engineers, and technical managers working on qualifying projects. Certain contract research costs and some cloud-computing expenses used directly in development or testing can also qualify when they relate to eligible research activities.

Wages usually drive the largest share of the credit for SaaS companies. That said, engineers rarely spend every hour on qualifying work. Time spent resolving technical uncertainty looks different from customer support, production maintenance, recruiting interviews, or administrative meetings.

Rather than reproducing every QRE rule and example here, this article focuses on software-specific questions. Arvo's Complete Guide to Qualified Research Expenses covers the broader expense rules in more detail.

Do You Need R&D Tax Credit Software to Claim It?

R&D tax credit software can make documentation and calculations faster, but software alone cannot decide whether your projects qualify. The strongest approach combines technology with tax professionals and technical reviewers who understand software development, especially when internal-use software or complex engineering work enters the picture.

This is where the search term changes meaning: some readers want to know whether software qualifies, while others want software that prepares the claim. The market now includes platforms that automate time tracking, expense collection, project mapping, and documentation. These are tools that can solve real problems, but they also have their limits. Let’s compare some pros and cons for different approaches:

Software-only versus hybrid support

Approach

Best for

Watch out for

Software-only platform

Organized companies with straightforward projects

May miss technical nuances like internal-use software

Traditional accounting firm

Businesses with experienced tax advisors

May lack software-development expertise

Hybrid platform + experts

Pre-revenue, growth-stage, or enterprise businesses

Unclear data security practices, experts that are hard to reach, or unclear audit support

 

Expert judgement is often required to bridge gaps in documentation and its significance. A platform can organize Jira tickets, payroll records, Github activity, and project information, but it cannot automatically determine whether a disputed architecture decision satisfied the process-of-experimentation standard.

For software companies, the strongest workflow usually connects engineering documentation with tax analysis instead of treating the R&D credit as purely an accounting exercise. That's the gap Arvo aims to fill.

Rather than replacing engineering documentation, Arvo's approach combines technology with tax professionals and technical reviewers who understand software projects, internal-use software rules, and the documentation the IRS expects. Preparing an R&D study normally takes weeks, but our accelerator model cuts the process by 80% using a direct connection to Github or Jira, surfacing qualifying projects, and employing ready-to-go narratives that are overseen by human experts.

Startups looking specifically at software tools can also see our Startup R&D Tax Credit guide for a more focused discussion of early-stage workflows. We also offer consulting for Startups and SMBs looking to capture the maximum and make the most of their R&D Tax Credits.

How Software Companies Claim the Credit in 2026

Software companies claim the federal R&D credit on Form 6765, and the filing process changed for recent tax years. Current rules include expanded business-component reporting for many taxpayers, restored current deductions for domestic research under Section 174A, and payroll tax opportunities for qualified startups.

The filing process now involves more detail than many older guides describe:

1. Form 6765 changed

For many taxpayers, Form 6765 now requires more business-component reporting than previous versions. The IRS's expanded Section G reporting asks taxpayers to classify software business components (including internal-use software, dual-function software, and non-IUS categories where applicable).

Note that this change makes project organization extremely important before tax season arrives.

2. Section 174A changed the deduction picture

The One Big Beautiful Bill Act (OBBBA) that passed in 2025 restored current deductions for domestic research expenditures through Section 174A for tax years beginning after December 31, 2024. Software companies should revisit this treatment under the new rules.

3. Startups still have a payroll-tax path

Qualified small businesses may elect to apply up to $500,000 of research credit against eligible employer payroll taxes, subject to IRS qualification rules and filing requirements. For companies with little income-tax liability, that can turn engineering work into earlier cash-flow benefits.

4. Documentation still matters most

The IRS's software guidance repeatedly emphasizes evaluating actual development activities rather than relying on labels alone. Well-functioning software teams already create many useful records such as architecture documents, sprint planning, design reviews, technical specifications, testing records, etc. The stronger those records connect engineering work to technical uncertainty and experimentation, the easier they become to support during the credit process.

Turn Your Software Development Into a Tax Credit

Many software companies already perform qualifying R&D without realizing it. The biggest opportunities often come from documenting engineering work correctly, understanding the internal-use software rules, and connecting development activity to the tax requirements before filing Form 6765.

If your company develops customer-facing software, builds complex infrastructure, improves scalability, or tackles difficult engineering challenges, it's worth evaluating those projects before assuming they don't qualify.

Arvo's R&D team helps software companies connect engineering work with the tax rules, document qualifying projects, calculate the credit, and prepare Form 6765 under the current post-OBBBA rules. With our services, you utilize a combination of human experts and software that works as an automated evidence engine to build your study so that you can claim credits 80% quicker than traditional prep.

If you're wondering what your development work could be worth, start with an assessment or use the Arvo R&D Tax Credit Calculator once the software-development preset becomes available.