Last week we looked at the second of the three tests that make up the “Higher Threshold of Innovation Test” for internal-use software (IUS); namely, “The Significant Economic Risk Test.” This three-part test is applied when a taxpayer is evaluating whether their software development efforts (for internal-use software) will qualify for federal and state research and development tax credits. As part of the second test, the Congressional committee reports included a requirement for “substantial uncertainty, because of technical risk…” in order for an IUS development project to qualify.
Today we will take a detailed look at the definition of “technical risk” as compared to “business risk” to help understand whether or not a particular IUS development project will meet the expectations provided by Congress. As part of our analysis, we will look at both court cases and an IRS Coordinated Issue Paper (CIP) for their interpretation.
What is Technical Risk?
While Congress was kind enough to use the term “technical risk” in their Congressional Committee Reports that provided special requirements for IUS development, they did not provide a definition to go with it. As a result, defining the term becomes yet another point to argue over during an IRS audit. Looking back to a 1999 CIP, the IRS defined “technical risk” as follows: “Technical risk arises when the solution, or method of arriving at the solution, is not readily apparent to skilled and experienced programmers after they have analyzed the problem using known software development techniques and parameters”. The CIP goes on to include, “Technical risk also arises when there is some question as to whether the software can be developed, and not whether the software will produce the desired efficiency.”
What factors are considered if defining technical risk?
- What is the size and complexity of the programming task and the project as a whole;
- Did the programming task use existing technologies and known programming methods;
- Had similar programming tasks been completed before;
- Did the software system provide functionality not offered in any other software;
- Did the company attempt to employ existing technology in a new and dynamic way;
- Was the programming task successfully completed;
- If the project failed, was abandoned, or was significantly delayed, did technical risks, as opposed to business-related risks, contribute to the outcome; and
- Did the company consider and account for technical risk in deciding to fund the software system development activities, and in monitoring the progress of the development activities.
Norwest v. Commissioner brings some clarity
Court cases have also helped define “technical risk” through their decision and discussion in court documents. In Norwest v. Commissioner, the court noted that technical risk includes “risk of failure exists throughout a project because problems that arise because of volume or scale cannot be resolved until the implementation phase.”
Additionally, experts who testified during the Norwest case, provided additional examples of “technical risk”. Dr. Randall Davis, PhD at MIT referred to “technical risk” as “the development of novel tasks, the use of familiar technology in a new manner, or the size or complexity of the project.”
Finally, Tower Group President, Diogo Teixeira, a consultant for the IRS, also commenting on the case defined “technical risk” as “the probability that a chosen technological architecture combined with a user’s determined features, functions, and volumes would not go into production.” (Norwest v. Commissioner, 110 T.C. No. 34).
Interestingly enough, the court in Norwest noted that while all the experts in the case helped their understanding of research in the computer science and banking fields, their explanations and comments were inconsistent with the court’s interpretation of the seven tests to qualify internal use software for research tax credits.
Technical Risk - Clear as mud
While the definitions and application to each taxpayer continue to move forward, finding some sort of clear guidance remains difficult. It seems that if a company does all they can from a business perspective to mitigate risk before embarking on a difficult and costly software development effort, their conservative approach may thwart their attempts at taking a research tax credit for the significant and risky efforts.
Randy Eickhoff, CPA is President of Acena Consulting. With more than 20 years of tax and consulting experience, Randy focused on helping companies successfully document and secure tax incentives throughout the US. He has been a long-time speaker nationally as well as conducted numerous training sessions on R&D tax credits and other US tax incentives.