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 elect under §41(h) to apply the credit against employer payroll tax, up to $500,000 per year for tax years beginning after December 31, 2022 - so a company with no income tax liability can still take cash. The mechanics are in how startups turn the R&D credit into payroll-tax cash.
• 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, applied per business component. An activity qualifies when it meets all four:

1. Permitted purpose - the work aims to develop or improve the functionality, performance, reliability, or quality of a product or process (here, your software).
2. Technological in nature - it relies on principles of computer science or engineering.
3. Elimination of uncertainty - at the outset, you did not know whether you could achieve the result, or how, or what the design should be.
4. 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. For a longer walk through each part and where it breaks, read the four-part test in plain English.

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. Research after the component is ready for commercial sale or use is excluded outright (§41(d)(4)(A)).
• Adaptation and duplication - adapting an existing component to a particular customer’s requirement, or reproducing one from a physical examination or plans, without technical change (§41(d)(4)(B), (C)).
• Research performed outside the United States (§41(d)(4)(F)). This is a location test, not a nationality test: an offshore engineering team’s work is out, wherever the company is based.
• Funded research - and this is the exclusion most likely to catch a SaaS agency or contract development shop. Under §41(d)(4)(H), work funded by a grant, a contract, or another person is excluded where you do not retain substantial rights in the results and do not bear the economic risk of failure. Fixed-price contracts with retained IP often survive; time-and-materials builds where the customer owns everything and pays regardless of outcome often do not. The answer is in the contract, so read the contract before you build the claim.
• Internal-use software - software developed primarily for your own internal administrative functions faces an additional high threshold of innovation test (§41(d)(4)(E) and the §1.41-4 regulations), with exceptions for software developed for use in an activity that itself constitutes qualified research or in a production process. Treat internal tooling as a question, not an assumption.

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 - generally 65% of amounts paid to another person for qualified research performed on your behalf (§41(b)(3)(A)). Two things people get wrong here. First, the test is where the research is performed, not the contractor’s nationality: the research has to be performed in the United States to escape the §41(d)(4)(F) exclusion. Second, you must retain substantial rights in the results and bear the economic risk, or the work is funded research to you as well. A higher 75% rate applies to payments to a qualified research consortium (§41(b)(3)(C)), and a 100% rate applies to certain energy research payments.

A note worth repeating: under 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 - see what Section 174A means for your 2025 taxes. For the credit fundamentals across industries, see our R&D tax credit overview and the qualified research expenses page.

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, component by component. Done right, the credit turns risk your team is already taking into a dollar-for-dollar reduction in tax. When you are ready for the substantiation side, read what examiners actually ask for.

Sources

• IRC §41 - Credit for increasing research activities and IRC §174A (U.S. House, Office of the Law Revision Counsel)
• Treas. Reg. §1.41-4 - Qualified research (Cornell LII)
• IRS - Research credit
• IRS - About Form 6765 and the Instructions for Form 6765