Blog postOctober 9, 2026

Which Cloud Bills Count Toward the R&D Credit? A Plain-English Guide for SaaS Finance Teams

TL;DR

The federal R&D credit statute lets amounts paid to another party for the right to use computers count toward the credit, but only when the computers are used in qualified research.
Development, test, staging, and experiment environments may be strong candidates. Production hosting that serves customers generally is not.
Most SaaS companies have shared accounts, so a simple tagging and allocation habit usually matters more than any single rule.

Why this question comes up for SaaS companies

For many software companies, cloud spend is the second or third largest line item after payroll. When finance teams first learn about the federal R&D credit, the natural question is whether that bill counts.

The short answer is that part of it may, depending on what the computing was used for. The credit under Section 41 of the Internal Revenue Code rewards qualified research spending, and the statute recognizes several kinds of spending: wages, supplies, contract research, and, relevant here, amounts paid to another person for the right to use computers in the conduct of qualified research. You can read the statute at Cornell Law School’s Legal Information Institute (26 U.S.C. 41).

The key phrase is “in the conduct of qualified research.” The bill is not eligible because it is a cloud bill. It is eligible, to the extent it is, because of what the compute was doing.

Start with the activity, not the invoice

Before sorting line items, it helps to remember what the credit is generally looking for: work aimed at developing or improving a product or process, which is technological in nature and involves resolving uncertainty through a process of experimentation. The regulatory framework is in Treasury Regulation 1.41-4.

That means the starting question for any cloud environment is: what qualifying work did it support? If you cannot connect an environment to a specific development project, it is harder to include it in a claim.

Environments that may be candidates

Depending on the facts, these kinds of environments may be worth reviewing:

Development and sandbox environments. Where engineers build and try new features, architectures, or integrations.
Test, staging, and CI environments. Where code is built, validated, and benchmarked against design goals.
Experiment and load-testing compute. Spinning up capacity to see whether a new architecture can hit a performance target is a classic example of testing a hypothesis.
Model training and data science workloads. Compute used to train and evaluate models for a new or improved product capability.

In each case, the stronger the link to a named development project, the easier the cost is to support.

Environments that often are not

Production hosting that serves customers. Running the live product is generally treated as delivering the service, not researching it.
Customer data storage, backups, and monitoring of the live environment. These are part of operating the business.
Corporate and administrative systems. Internal tools used for general business purposes are usually not research.
Compute for work that falls outside qualified research, such as routine maintenance or cosmetic changes.

There are gray areas. A canary release that exists mainly to test a new capability under real traffic may look different from routine production. These are the situations where the specific facts matter and a careful review is worth the time.

The contract and structure matter too

Section 41 treats computer-use payments under regulations, and those regulations, found in Treasury Regulation 1.41-2, include conditions on how such arrangements are structured. Because cloud services did not exist when much of that language was written, how it applies to a particular provider and plan can depend on the details. This is one more reason to treat cloud costs as an area for careful review rather than an automatic add.

A practical habit: tag now, allocate later

The most useful thing a SaaS finance team can do is also the least glamorous: make environments identifiable.

Use separate accounts or projects, or consistent tags, for development, test, and production.
Map major environments to the engineering projects they supported.
Keep the monthly invoices or usage reports so the amounts can be traced.
When an environment is shared, note how you would reasonably split it between research and non-research use, and apply the same method consistently.

Good tagging also helps in ordinary budgeting, so it pays off even before any credit conversation.

Don’t forget the bigger pieces

Cloud costs are often a smaller slice of a SaaS claim than engineering wages, which typically make up the largest share of qualified spending. The credit also does not require a profitable year; eligible smaller companies may be able to apply it differently, which is a separate conversation. For one example of what a software company’s claim can look like, a SaaS client of ours identified $1.1M+ in credits. Individual results vary, and every claim depends on the specific activities, documentation, and facts.

How to take a first step

You do not need to rebuild your accounting to find out where you stand. A short conversation can help you see which environments, projects, and teams are worth looking at and how much time a study would ask of your team. Strata offers a $0 initial assessment, and engagements typically take four to eight weeks, depending on how quickly information comes together. You pass the finished package to your CPA, who files the return.

Book a 15-minute review at stratataxgroup.com/contact.

Sources

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

Author

Strata R&D Tax Group