Which Parts of Your SaaS Roadmap Qualify for the R&D Credit (and Which Do Not)

TL;DR

• The federal R&D credit does not care whether your product is impressive. It cares whether specific development work set out to resolve a technical uncertainty through experimentation. Much of a SaaS roadmap does that; a meaningful share does not.
• Software you build to sell, license, or let customers interact with is generally not "internal use software," which means it is evaluated under the standard four-part test rather than a stricter one. Internal tools for your own finance, HR, or admin functions face a higher bar.
• The practical move is to sort your roadmap by the nature of the problem, not by the size of the feature. A small change that required real experimentation can qualify; a large launch that was mostly configuration may not.

The credit rewards a kind of work, not a kind of company

The research credit under IRC Section 41 is a federal incentive for companies that spend money trying to make something technically better and are not sure at the outset how to get there. Software companies are among its most natural users, because building software is a constant sequence of "we think this will work, let's find out." But that does not mean every hour of engineering time counts. The regulations at Treasury Regulation 1.41-4 (eCFR) apply a four-part test to each piece of work, and the honest answer for most SaaS companies is that some of the roadmap clears it and some does not.

Here is the test, briefly, applied to software:

1. Permitted purpose. The work must be intended to create or improve a product, process, or software component in terms of function, performance, reliability, or quality. Most feature and platform work satisfies this. Work aimed purely at style, cosmetics, or seasonal design changes generally does not.
2. Technological in nature. The work must rely on principles of computer science, engineering, or the physical sciences. Software development inherently does.
3. Elimination of uncertainty. At the start, your team must have been uncertain about capability (can we do this at all), method (how do we do it), or appropriate design. This is the test that trims the roadmap the most.
4. Process of experimentation. Substantially all of the activity must involve evaluating alternatives: modeling, prototyping, testing, iterating. Under the regulations, this is measured against the work itself, not against whether the result was novel to the world. A failed approach that was abandoned still counts as experimentation.

The "substantially all" standard in the regulation is generally applied at the 80 percent level, and there is a "shrinking-back" provision that lets you apply the test to a smaller component when the whole product does not qualify but a subsystem does. That last point matters for SaaS: even if a release as a whole is mostly routine, the search engine, the sync layer, or the permissions model inside it can be evaluated on its own.

Sorting the roadmap: what tends to qualify

Depending on the specific activities, documentation, and facts, the following categories of SaaS work are often strong candidates:

New capabilities with an unsolved technical path. Building a real-time collaboration engine, a recommendation model, a rules engine that has to handle edge cases your competitors' products choke on. If the team wrote design docs debating approaches, built spikes, and threw one away, that is the pattern the credit is looking for.

Architecture and scale work. Re-platforming from a monolith to services, redesigning a data model to handle 100x load, building multi-tenant isolation where the standard patterns did not fit your data. The uncertainty is often about performance and reliability rather than function, and the regulations explicitly include both.

Integrations that required more than reading the docs. Connecting to a well-documented API by following the vendor's guide is usually not R&D. Building an integration layer that has to reconcile conflicting data models, handle unreliable third-party behavior, or achieve latency the vendor never promised often is.

Security, performance, and reliability engineering. Work to reduce p99 latency, eliminate a class of race conditions, or design an encryption scheme for a specific compliance need can qualify when the approach was uncertain at the outset.

Refactoring, sometimes. This is a gray area. Refactoring done to enable a new capability, or to resolve a performance or reliability problem with an uncertain solution, can be part of a qualifying project. Refactoring for code hygiene alone generally is not.

What tends not to qualify

Section 41(d)(4) lists specific exclusions, and several land squarely on common SaaS work:

• Configuration and adaptation. Setting up an existing tool, adapting a product to a particular customer's requirements without new technical uncertainty, or standing up infrastructure using vendor defaults.
• Routine bug fixes and maintenance. Fixing a known defect with a known fix, dependency upgrades, routine patching. Debugging can be part of experimentation when the cause is unknown and the investigation is real, but ordinary maintenance is excluded.
• UI polish and cosmetic changes. Restyling, rebranding, layout tweaks, copy changes. If the uncertainty is about what users will prefer rather than whether the software can do it, that is market research, which is excluded.
• Work after commercial release, in most cases. Once the uncertainty is resolved and the feature is in production, ongoing support is generally outside the credit unless a new technical problem arises.
• Surveys, studies, and management activities. Product discovery interviews, competitive research, and project management overhead are excluded as such, although wages for people who directly supervise or support qualifying technical work can be included under Section 41(b).

The general principle: ask what the team did not know at the start, and what they did to find out. If the answer is "we knew how, we just had to do it," the work is probably not qualified research, regardless of how much engineering time it consumed.

The distinction most SaaS founders have never heard of: internal use software

Here is where SaaS companies get a structural advantage that many do not realize they have.

Software developed primarily for a company's own general and administrative functions (finance, HR, and support services like internal data processing) is treated as "internal use software" and has to pass an additional "high threshold of innovation" test on top of the four-part test. That extra test requires showing the software is innovative in a measurable economic sense, involves significant economic risk, and is not commercially available. It is a demanding standard, and it is one reason R&D claims for back-office tooling are harder to support.

The 2016 final regulations (Treasury Decision 9786, published in the Federal Register and now part of Treasury Regulation 1.41-4(c)(6)) draw the line clearly. Software is not internal use if it was developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or to enable the company to interact with third parties or let third parties initiate functions or review data on the company's system. The regulations give the example of a cloud-based provider building enterprise application software for customers to access online, and conclude it is not internal use. That is the definition of a SaaS product.

Two practical consequences:

Your product is evaluated under the normal test. The core platform, customer-facing features, the API you expose, the customer portal, the mobile app. All of this is judged under the standard four-part test, not the elevated one. The determination is made based on your intent at the beginning of development, so testing the product internally before launch does not make it internal use.

Your internal tools are a separate question. The billing automation your finance team uses, the internal admin dashboard, the custom HRIS integration. These are presumed internal use and face the higher bar. Some may still qualify, but the analysis is different and the documentation needs to be stronger.

There is also a middle category the regulations call "dual function software," built both for internal G&A use and for interaction with third parties. It is presumed internal use, but if you can identify the subset of the software that only serves third-party interaction, that subset is evaluated under the normal rules. Where a dual-function remainder still exists, a safe harbor allows 25 percent of its qualified research expenses to be included, provided third-party use is reasonably anticipated to be at least 10 percent of total use and the work otherwise qualifies. A support-ticketing system that customers submit into and your team works from is a common example.

A practical way to triage before you talk to anyone

You do not need a specialist to do a first pass. Pull last year's roadmap, or whatever list your engineering team uses to track completed projects, and sort the projects into three buckets:

• Likely qualifying: you can name the technical uncertainty and describe at least two approaches that were considered or tried.
• Likely not: the work was configuration, cosmetic, or a known fix; or the uncertainty was about market fit rather than technical feasibility.
• Unsure: the work was substantial and technical but you cannot immediately articulate what was uncertain.

The third bucket is usually where a specialist earns their keep. It is also where the shrinking-back rule matters, because a large project that looks routine overall often contains a smaller piece that clearly qualifies.

For a sense of scale, one Strata SaaS client identified more than $1.1M in credits across a multi-year study. Individual results vary depending on the specific activities, documentation, and facts.

What happens next

If your roadmap has a meaningful "likely qualifying" bucket and you have never claimed the credit, a $0 initial assessment is the low-commitment way to find out what a claim might look like. Strata uses a structured, guided process designed so that most of the work sits with our team, and we work directly with your CPA so the credit and its supporting documentation land together at filing time. Typical turnaround is in the range of 4 to 8 weeks, depending on how quickly information comes together. The credit is claimed on IRS Form 6765, and a qualifying small business may be able to apply a portion of it against payroll tax rather than income tax, which can matter for pre-profit companies. You can start at stratataxgroup.com/contact.

Primary sources referenced in this post: Treasury Regulation 1.41-4 (eCFR), Treasury Decision 9786 on internal use software (Federal Register), and IRS Form 6765 (IRS.gov).

This post is for informational purposes only and does not constitute tax or legal advice. Consult a qualified tax professional regarding your specific circumstances.