R&D Tax Credits for SaaS Companies: What Actually Qualifies

Software companies are some of the most R&D-intensive businesses in the economy, yet many of them chronically under-claim the federal R&D tax credit — or skip it entirely. The work clearly involves research and experimentation, but the credit feels like something for people in lab coats, the qualification rules sound vague, and engineering teams are busy shipping. The result is that a credit explicitly designed to reward technical risk-taking goes unused by the companies taking the most technical risk.

This post walks through why SaaS underclaims, how ordinary engineering work maps to the qualification rules, and which costs actually count.

Why SaaS chronically underclaims

A few patterns show up again and again:

“We’re not doing research, we’re just building product.” The statutory test does not require novel-to-the-world science. It asks whether you faced and resolved technical uncertainty. Building a feature your team has never built, in a way your team had to figure out, can qualify.
The work isn’t documented as research. Engineering happens in tickets, pull requests, and design docs — not in a research log. The activity qualifies; it just was not labeled that way.
Founders assume they’re too small or pre-profit. Qualified small businesses can apply the credit against payroll tax, up to $500,000 per year, so even a company with no income tax liability can benefit.
The prior accountant never asked. Many general tax preparers do not probe engineering work in any depth, so the credit simply never comes up.

For a fuller picture of how the credit applies to software businesses, see our SaaS and software industry page.

Mapping engineering work to the four-part test

The R&D credit under IRC Section 41 uses a four-part test. An activity qualifies when it meets all four:

Permitted purpose — the work aims to develop or improve the functionality, performance, reliability, or quality of a product or process (here, your software).
Technological in nature — it relies on principles of computer science or engineering.
Elimination of uncertainty — at the outset, you did not know whether you could achieve the result, or how, or what the design should be.
Process of experimentation — you evaluated alternatives through iteration, prototyping, testing, or modeling, with substantially all of the activity involving such a process.

Most real engineering projects clear this bar more easily than teams expect. When you spike two architectures, benchmark them, and pick the one that scales — that is a process of experimentation aimed at improving performance, grounded in computer science, resolving uncertainty you genuinely had at the start. All four parts, satisfied by a normal sprint.

What qualifies

Common SaaS work that frequently meets the test:

New features and functionality where the implementation path was not obvious and required design and iteration.
New or re-architected systems — migrating to microservices, redesigning a data model, rebuilding a core service for reliability.
Algorithms — search, ranking, recommendation, pricing, matching, optimization, anything where you tuned and tested approaches.
AI/ML development — model selection, feature engineering, training pipelines, evaluation, and the experimentation that comes with it.
Scalability and performance — re-engineering for load, reducing latency, sharding, caching strategies, and the testing to prove they work.
Security engineering — designing and validating authentication, authorization, encryption, and threat-mitigation approaches where the right design was uncertain.
Integrations — building against poorly documented or evolving third-party systems where significant technical problem-solving was required.

What doesn’t qualify

It is just as important to know the boundaries:

Routine maintenance and bug fixes that do not involve resolving genuine technical uncertainty.
Pure configuration — standing up an off-the-shelf tool by following its documented setup, with no experimentation.
Cosmetic or routine UI changes with no underlying technical problem-solving.
Work after uncertainty is resolved — once you know the design works, scaling out the rote remainder is generally not qualified.
Adaptation and duplication — straightforwardly copying an existing solution to a new context without technical change.

Drawing this line carefully is what makes a study both defensible and accurate. Over-claiming routine work undermines a study as much as under-claiming the real research does.

Which costs count (QREs)

Once you have identified qualifying activities, the credit is computed on qualified research expenses (QREs). For software companies the relevant categories are:

Wages for qualified services — the portion of compensation for employees who perform the research, directly supervise it, or directly support it. For most SaaS companies, engineering payroll is the largest QRE by far.
Supplies consumed in the research process. This is smaller for software than for, say, manufacturing, but not always zero.
Computer and cloud rental — costs of renting or leasing computers used in research, recognized under Section 41(b)(2)(A)(iii). For SaaS, this is where cloud and compute spend tied to development, testing, and training workloads can come in — a category that is easy to overlook precisely because it is so routine.
Contract research — 65% of amounts paid to U.S. contractors performing qualified research on your behalf. If you use domestic contract engineers or development shops, a substantial share of that spend can count.

A note worth repeating: under the new Section 174A, domestic software development costs are explicitly eligible for immediate expensing for tax years beginning after December 31, 2024. The deduction and the credit are separate benefits, and a well-run software company should be capturing both. For the credit fundamentals across industries, see our R&D tax credit overview.

The takeaway

If your engineers spend their days designing systems, choosing between technical approaches, and finding out through testing whether something works, you are almost certainly doing qualifying research. The hard part is not the engineering — it is connecting that work to the statutory test with the documentation an examiner expects. Done right, the credit turns risk your team is already taking into a dollar-for-dollar reduction in tax.