This page provides concrete examples of technical uncertainty in software development for the R&D tax credit. The elimination-of-uncertainty element of qualified research asks whether the work was intended to eliminate a technical uncertainty about the capability, method, or appropriate design of a business component. This page illustrates the concept with software-specific examples. It is educational and is not individualized advice. For the underlying framework, see our page on elimination of uncertainty.
Three Types of Technical Uncertainty
Under the Treasury Regulations (§1.41-4), uncertainty exists if the information available to the taxpayer does not establish the capability or method for developing or improving the business component, or the appropriate design. Three types of uncertainty are relevant:
- Capability uncertainty — whether the software can achieve a desired result at all.
- Method uncertainty — how to achieve the desired result, even if the result is known to be achievable.
- Appropriate-design uncertainty — what the software should look like or how it should be configured.
Example 1: Capability Uncertainty
A company is developing a new search algorithm and is uncertain whether any available approach can achieve the required search accuracy across a new type of data. The uncertainty is about capability — whether the search can be achieved at the required accuracy at all.
Example 2: Method Uncertainty
A company is developing a new data-processing pipeline and knows that the required throughput is achievable (capability is established) but is uncertain which of several alternative approaches can achieve it. The uncertainty is about method — how to achieve the required throughput.
Example 3: Appropriate-Design Uncertainty
A company is developing a new software architecture and is uncertain which of several alternative architectures is the appropriate design for the required performance and scalability. The uncertainty is about appropriate design — what the architecture should look like.
Distinguishing Technical from Business Uncertainty
A common mistake is confusing technical uncertainty with business uncertainty. Business uncertainty — whether a market will accept a feature, whether a project will finish on time, whether a customer will buy — is not the kind of uncertainty the elimination-of-uncertainty element addresses. The uncertainty must be technical, about the capability, method, or design of the software business component.
Hypothetical Example
Consider a company that is developing a new real-time recommendation engine and is uncertain whether any available approach can achieve the required recommendation accuracy within the required latency. The company evaluates alternative approaches, tests each, and systematically varies the approach to resolve the uncertainty. This technical uncertainty about capability and method may support the elimination-of-uncertainty element.
By contrast, if the company is uncertain whether customers will use the recommendation feature, that is business uncertainty, not technical uncertainty.
These examples are illustrative only and do not state whether any particular activity qualifies.
Documentation That May Help
Records that can help support the uncertainty element include project initiation records, design review notes, technical specifications, and project communications that identify the specific technical question. For more, see our page on R&D tax credit documentation.
Key Takeaway
Technical uncertainty in software development may involve uncertainty about capability, method, or appropriate design of a software business component. The uncertainty must be technical, not business, and must be intended to be eliminated through a technological process of inquiry. Because the analysis is fact-specific, professional review is appropriate before claiming the credit.