Internal Use Software: Significant Economic Risk (part 2)

3 Minute Read
Posted by Randy Eickhoff on Sep 13, 2011 2:00:00 AM

randy.eickhoff@acenaconsulting.comI have always been a fan of bright-line tests when it comes to tax law and a taxpayer’s opportunity to know that the facts of their situation will result, without question, in a certain tax treatment. Unfortunately, the current landscape and treasury regulations for the research and development tax credit provide few bright-line tests.

In the area of internal-use software (IUS), the information and directives available to taxpayers are anything but definitive. As we reviewed last week, the Higher Threshold of Innovation Test, provides for three additional tests to the initial four-part test for software development. Last week, we discussed the first of the three tests-“The Innovativeness Test”. Today and next week, we will look at the second component, “The Significant Economic Risk Test” in more detail and provide some clarity for taxpayers to use in their efforts to document and understand IUS and the R&D tax credit.

Defining Significant Economic Risk

For a definition of “significant economic risk” we must reach back to the Congressional committee reports (final regulations for the Higher Threshold of Innovation Test have not yet been released by the IRS). Under H.R. Conf. Rep. No. 99-841, at II-73-74 (1986), substantial economic risk is when a “taxpayer commits substantial resources to the development and also there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable time period.” Clears everything up, doesn’t it?

Let’s look at how the IRS evaluates facts and circumstances to determine if an IUS development activity meets this test.internal_use_software_required_additional_documentation

Documenting Significant Economic Risk

In an IRS Coordinated Issue Paper (CIP) issued August 26, 1999 on internal-use software, the IRS included the following facts and circumstances as areas considered (but not limited to):

  • The amount of time the taxpayer spent on IUS projects as compared to net assets;

  • The number of hours computer programmers spent on the IUS software projects as compared to the number of hours they spent on overall software development;

  • The amount paid or budgeted for IUS projects as compared to the total annual information technology budget;

  • The amount paid or budgeted for the IUS software projects as compared to the amount paid or budgeted for all research projects during the same period;

  • The level of management approval required under its budgetary procedures before it committed funds to a software project to the extent that the approval process defines the taxpayer’s own assessment of what they consider to be a substantial commitment of resources.


Documenting these facts and circumstances does not guarantee that a taxpayer’s development of IUS will result in passing an IRS audit but it does help illuminate how IUS development will be evaluated under audit.

In our next blog, we will expand the definition of “technical risk” and compare it to the definition of “business risk” in order to better evaluate IUS development projects and their ability to qualify for research tax credits.

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.

New Call-to-action