The IRS Four-Part Test for R&D

To qualify for the federal R&D tax credit under IRC Section 41, each activity must satisfy all four parts of the IRS test. This isn't a subjective judgment — each criterion has specific regulatory meaning defined in Treasury Regulation §1.41-4. Understanding these criteria is essential for both claiming the credit and defending it in an audit.

The research must be undertaken to create a new or improved business component — meaning a product, process, computer software, technique, formula, or invention. The improvement must relate to function, performance, reliability, or quality.

Software example: Building a new API endpoint that processes data faster than the previous approach qualifies. Fixing a simple typo in documentation does not — it doesn't improve function, performance, reliability, or quality.

Key point: "Improved" is broadly defined. You don't need a breakthrough — incremental improvements count if they involve the other three criteria.

At the outset of the activity, there must be uncertainty about the capability or method for developing or improving the business component, or the appropriate design of the component.

The three types of uncertainty: - Capability uncertainty: Can it be done at all? - Methodology uncertainty: How should it be done? - Design uncertainty: What's the right architecture?

Software example: "We need to process 10M events per day with sub-100ms latency, and we're not sure if our current architecture can handle it." That's technological uncertainty. Choosing between two well-known frameworks with documented performance characteristics is not.

The taxpayer must engage in a systematic process designed to evaluate one or more alternatives to achieve a result where the method is uncertain. This can include modeling, simulation, systematic trial and error, or other methods.

Software example: A/B testing different caching strategies to find one that meets latency requirements is experimentation. Building multiple prototype architectures and benchmarking them qualifies. Following a tutorial to implement a known solution does not.

The IRS looks for evidence of alternatives considered, tests run, and iterations made — which is exactly the kind of evidence that commit histories and branch strategies provide.

The research must fundamentally rely on principles of engineering, physical sciences, biological sciences, or computer science. Business, management, social science, arts, and humanities research does not qualify.

Software example: Almost all software development is technological in nature by definition — it relies on computer science. This is usually the easiest criterion to satisfy for engineering teams.

Activities that fail this test: market research, UI color preference surveys (pure aesthetics), business process changes that don't involve technology.

Each qualifying activity must pass all four parts. In practice, most software development work passes Parts 1 and 4 easily. The key questions are usually around Parts 2 and 3:

• Was there genuine uncertainty? (Not just "I hadn't done it before," but "it wasn't clear if or how it could work.")
• Did you experiment? (Try different approaches, benchmark, iterate on design?)

Documentation is critical. The IRS doesn't take your word for it — they want contemporaneous evidence that these criteria were met at the time the work was performed.