What Counts as Qualified Research? The §41 Four-Part Test

Most SaaS founders assume the R&D tax credit is for people in lab coats. It is not. The federal credit under §41 is built around a single gate called the four-part test, and a surprising amount of ordinary product engineering passes it. The challenge is not the work. It is knowing how the IRS defines "qualified research" and being able to show that your activities fit. Here is the test in plain language, applied to software. The Four-Part Test The test is applied to a specific activity tied to a "business component," which is the product, process, software, technique, or formula you are trying to develop or improve. To count as qualified research, that activity has to clear all four gates below. Miss one, and the activity does not qualify.Permitted purpose. The work has to aim at developing a new or improved business component, meaning its function, performance, reliability, or quality. In SaaS terms, that is a new feature, a faster system, or a new product capability. Technological in nature. The work has to fundamentally rely on the principles of a hard science. For software, that means computer science and software engineering. Product engineering clears this gate easily. Elimination of uncertainty. At the outset, you were uncertain about something specific: whether you could achieve the result (capability), how to achieve it (method), or what the right design was. If your team already knew the answer when they started, there was no uncertainty to eliminate. Process of experimentation. You evaluated one or more alternatives through a systematic process: modeling, simulation, prototyping, systematic trial and error, or testing against requirements. This is where everyday engineering practice tends to shine.The crucial point is that all four parts focus on what your engineers faced and did during the work, not on whether the project ultimately succeeded. Failed experiments can still qualify. So can features that shipped late or got scrapped entirely. What This Looks Like in a SaaS Codebase Translating the statute into engineering terms makes it concrete. Activities that often qualify include:Designing a new architecture when you are not sure the chosen approach will scale or perform. Building novel algorithms where the right design is not obvious up front, such as a matching engine, a recommendation system, or a pricing model. Training or developing machine learning models where the outcome and approach are genuinely uncertain. Performance and scalability work where you test competing approaches to hit latency or throughput targets. Hard integrations where compatibility, data consistency, or reliability are real open questions at the start.What ties these together is that the team faced a technical question they could not answer from off-the-shelf knowledge and worked through alternatives to resolve it. What Usually Does Not Qualify Knowing the exclusions is just as important, because claiming work that does not qualify weakens the credible parts of a claim. Activities that generally fail the test include:Routine bug fixes and ordinary maintenance. Cosmetic or purely visual UI changes. Content creation and copy updates. Market research, customer surveys, and most marketing work. Work performed after a product is commercially released, where the uncertainty has already been resolved. Research funded by someone else, where you do not bear the financial risk or retain rights to the results.These tend to fail on the uncertainty or experimentation gates, or they fall outside what the credit is meant to reward. Where a given project sits is fact-dependent, so confirm the specifics with a CPA for your situation. The Founder Takeaway The headline for most SaaS teams is encouraging: ordinary engineering performed under genuine technical uncertainty usually qualifies. The work does not have to be groundbreaking or first-of-its-kind. It has to involve a real question your team did not already know how to answer, approached through experimentation. In practice, most SaaS teams do more qualifying work than they realize. The reason it gets missed is that the four-part test is conceptual, and connecting it to specific activities and the costs behind them takes deliberate effort. That mapping, tying real engineering work to each of the four gates, is exactly the substantiation work TaxUpside helps SaaS teams produce. This is general information, not tax advice. Whether a particular activity qualifies depends entirely on your facts, so confirm with a qualified CPA before relying on any of it.