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

TL;DR

• The federal R&D tax credit isn't just for labs and hardware. Software companies solving genuine technical problems often qualify, and the work usually happens in your normal sprint cycle.
• Whether an activity qualifies turns on the IRS four-part test, not on whether you shipped something novel to the whole industry. The standard is uncertainty your team had to resolve, not a patent.
• Eligibility depends on the specific activities, documentation, and facts. A short, no-cost assessment can tell you where you actually stand before you spend time chasing it.

Ask a SaaS founder whether their company does "research and development" and you'll often get a shrug. Research sounds like white coats and labs. But your engineers spent the last two quarters wrestling a flaky data pipeline into reliability, rebuilding an auth system to scale past a breaking point, and testing three architectures before one held up under load. Under the federal R&D tax credit, that kind of work may be exactly what the credit was written for. A lot of software companies leave it on the table simply because nobody told them development counts.

What the federal R&D credit actually covers

The credit comes from Section 41 of the Internal Revenue Code, with the qualifying-activity rules detailed in Treasury Regulation 1.41-4 (ecfr.gov). It's a federal incentive for businesses that work to develop or improve products, processes, or software through technical problem-solving. It is not limited to inventing something new to the world. Improving your own product in ways that require resolving technical uncertainty can count.

To qualify, an activity generally has to pass the IRS four-part test:

1. Technological in nature. The work relies on principles of computer science, engineering, or another hard science. For software teams, this is usually the easy part.
2. Permitted purpose. It aims to create or improve the functionality, performance, reliability, or quality of a product, process, or piece of software.
3. Technical uncertainty. At the outset, your team didn't know whether it could achieve the result, or how, or what the right design would be. You had to figure it out.
4. Process of experimentation. You worked through that uncertainty systematically: evaluating alternatives, prototyping, testing, and iterating toward a solution.

The four-part test is the whole game. Meeting it depends on the specific activities, documentation, and facts of how your team works, which is why two companies building similar features can land in different places.

What qualifying activity often looks like for software companies

In a SaaS or software business, qualifying work is often hiding in plain sight inside the normal build cycle. Depending on the facts, activities that may qualify include:

• Designing and developing new application features where the technical approach wasn't obvious going in.
• Architecting systems to handle scale, throughput, or latency requirements your prior design couldn't meet.
• Developing or substantially improving algorithms, data models, or processing pipelines.
• Building and testing integrations across systems where compatibility or performance was genuinely uncertain.
• Experimenting with new frameworks, infrastructure, or approaches to solve a performance or reliability problem.
• Developing software to automate or improve an internal process where the path wasn't a known, off-the-shelf solution.

One Strata client in the software space, enterprise supplier-management platform Graphite Connect, identified more than $1.1M in federal R&D credits across qualifying development work. Individual results vary based on each company's activities, spend, and documentation, and a figure like that reflects one company's specific facts, not a typical outcome.

What usually does NOT qualify

Being honest about the limits protects you if your return is ever examined. Work that typically does not qualify includes:

• Routine bug fixes, maintenance, and minor updates that don't involve resolving technical uncertainty.
• Cosmetic or purely aesthetic UI changes with no underlying technical problem.
• Configuring, customizing, or deploying off-the-shelf software using known methods.
• Content creation, copywriting, and marketing work.
• Market research, A/B testing of pricing or messaging, and other non-technical business activity.
• Work performed after a product is in commercial production and the uncertainty has been resolved.
• Reverse-engineering or simply duplicating an existing product without your own process of experimentation.

The dividing line is usually technical uncertainty and experimentation. If your team genuinely didn't know whether or how something could be done and had to work it out, that activity is far more likely to be in scope. If it was a known, routine task, it generally isn't.

How to figure out where you stand

You don't need to map every sprint to the four-part test on your own. The practical first step is a no-cost assessment: a specialist looks at what your team actually built over the year, identifies which activities may qualify, and gives you an honest read before you invest any time or money. Strata's approach is to maximize the credit you're entitled to while keeping the documentation defensible, so the claim holds up if the IRS ever asks. Most engagements run a typical 4 to 8 weeks from kickoff, depending on the complexity of the work and how your records are organized.

FAQ

We're pre-profit and not paying much in income tax. Is the credit still worth it?
It can be. Qualifying small businesses may be able to apply a portion of the R&D credit against payroll taxes rather than income tax, which matters for early-stage companies that aren't yet profitable. Whether you qualify depends on your specific facts, so it's worth checking.

Do we need a patent or something truly novel to the industry?
No. The standard is whether the work was technologically uncertain and required a process of experimentation for your team, not whether it was new to the world. Improving your own software in technically uncertain ways can qualify.

Does work done by offshore or contract developers count?
The rules treat in-house and contracted research differently, and where the work is performed matters. Qualified research generally must be performed within the United States, and contractor costs are treated under specific rules. A specialist can sort out which of your costs may be eligible.

What documentation will we need?
Generally, records that tie technical work to the four-part test: project descriptions, technical specs, version control and ticket history, and time or payroll records showing who worked on what. Good engineering hygiene often doubles as good credit documentation, and part of the assessment is identifying what you already have.

Ready to find out what your development work may be worth? Start with a no-cost assessment at stratataxgroup.com/contact.

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