Internal Use Software: Old School Innovation (part 1)

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

Randy_Eickhoff_President,_Acena_ConsultingInnovation is happening all around us and at such an incredible speed that keeping on top of it all is impossible at best.

I would never have believed as a child growing up in San Diego that I would one day have a car that would play my music because I told it what song I wanted. I would never have believed that I would have a video game that allowed me to compete against others across not only the country but world as we race through digital streets fighting for the finish line.

In the world of software development, large and small companies are developing new and improved software both for their customers and for internal uses. As we discussed last week, the research and development tax credit is available for internal use let_Acena_help_navigate_the_maze_of_R&D_regssoftware development; these efforts, however, must survive a three-prong maze known as the Higher Threshold of Innovation Test. Today, we will look at the first of the three prongs in more detail and talk about how Congress intended taxpayers to define “innovative” as part of this test.

The Software Must Be Innovative

Congress wanted to make a distinction be software developed for sale or use by customers and software developed for internal uses. The congressional record and committee reports tell us that in order to pass this test software is innovative if it “results in a reduction in cost, or improvement in speed, that is substantial and economically significant.” (H.R. Conf. Rep. No. 99-841, at II-73 (1986)). While helpful, this definition does not provide much of a bright-line test that taxpayers (or the IRS) can easily apply. In United Stationers Inc (“USI”) v. US, the government argued during the appeal that the district court incorrectly applied this test by not focusing on the economic significance of the efficiencies generated by USI’s programs pointing out that 65% of the original investment in the projects did not produce the anticipated economic returns. The appellate court did not agree with the government’s quantitative application of this test.

I think it is appropriate to point out that regardless of the outcome of the internal-use software development effort; it is the attempt that is critical; remember that a development effort can fail and may still qualify for R&D tax credits. In some cases, these failures provide better evidence of a taxpayer’s intent to develop new or improved products, processes, software, techniques, formulas or inventions.

Application of Innovation – Facts and Circumstances

Few things can be more difficult than applying tax law on a facts and circumstances basis. Bright-line tests make qualifying for deductions and credits more conclusive and leave little doubt to both the IRS and the taxpayer in terms of the application and use. In the case of internal-use software, final regulations are still forthcoming so we must apply current regulations and congressional reports to each company and their situation. One thing is certain, when software is developed primarily for internal use by a company, additional documentation related to innovation must be completed.

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

Randy Eickhoff

Randy Eickhoff

Acena Consulting President Randy Eickhoff, licensed CPA, has partnered with more than 200 companies during more than 20 years of experience securing tax credits and other government incentives. His corporate partners range from multinational technology firms to smaller, privately held manufacturing, sports, and technology enterprises.