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: A project to improve API performance may satisfy this element when it is part of a qualifying process of experimentation. A simple documentation typo normally would not. The full four-part test and any exclusions still apply.

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: A team may face uncertainty about whether a particular architecture can meet a stated throughput and latency target. The taxpayer should retain the facts that show the uncertainty and alternatives evaluated, rather than relying on a label alone.

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: Modeling, prototyping, benchmarking, or systematic trial and error can be relevant evidence when they evaluate alternatives to resolve uncertainty. Reusing a known implementation may not show that process.

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: Software work may rely on computer-science principles, but that element does not establish the other parts of the test or override statutory exclusions.

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

Each claimed activity must be evaluated against all four elements for the relevant business component. In many software reviews, the evidence around uncertainty and experimentation is especially important:

• 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.