Late last year a Research and Development case highlighted the importance of understanding the subtleties of qualifying software R&D claims. The case, the United States of America vs. Davenport, Civil Action No.: 3:09-CV-2455-L reached judgment in the Northern District of Texas, Dallas Division of the U.S. District Court ruled in favor of the IRS over the taxpayer and provides insight into the Court’s interpretation of the Process of Experimentation (POE) test as it relates to software and other key areas of concern for taxpayers. Without going into detail of the case (click here for a nice summary of the case), the IRS argued that the case did not involve research activities and only involved adaption of existing commercially available software and quality control testing. Based on the evidence presented, the court decision found in favor of the IRS and determined that the software project did not meet the requirements for qualified research with an emphasis on the process of experimentation requirement.
The focus of this article is to highlight key components to a software R&D claim and particularly the Process of Experimentation as it relates to software development.
The software design process is inherently iterative and will often require major changes in software coding as software requirements change or become better understood. The development process generally involves conceptualization; project scoping; creating the design framework; development and testing of code; integration and testing; installation/release and testing; maintenance; and bug fixing.
Based upon the results of any or all of these steps, the software development activity may need to repeat (i.e., iterate through) one or more of these steps. Taxpayers should be aware that since most software design development processes are, by their nature, iterative, simply illustrating for the IRS that an iterative process was used does not typically satisfies their requirements.
To qualify, software development activities must meet, in addition to the standard four tests related to R&D, an additional three tests to qualify under Section 41 defined as follows:
- The software is innovative. (It results in a reduction in cost or an improvement in speed that is substantial and economically significant.)
- Developing the software involves significant economic risk. (The taxpayer commits substantial resources to software development and, due to technical risk, there is substantial uncertainty it will recover the resources in a reasonable time period.)
- The software is not commercially available. (The taxpayer cannot purchase, lease or license and use the software for the intended purpose without modifications that satisfy the first two requirements.)
When these tests are looked at in aggregate, software R&D claims essentially require that the project and thus the project activities be performed to develop a significant, unique, and innovative new application. For an R&D claim it is essential that the uncertainty being resolved exist in the software development rather than in the changing business requirements themselves. In general the types of software projects that will include R&D related activities that meet the process of experimentation test are those that meet the unique and innovation test, for example:
- The initial release of an application software product that requires new architectures, new algorithms, or new database management techniques.
- The development of system software, such as operating systems and compilers.
- The development of specialized technologies, such as image processing, artificial intelligence, or speech recognition.
- Software developed as part of a hardware product wherein the software interacts directly with that hardware in order to make the hardware/software package function as a unit.
In the Davenport case, the IRS was looking for evidence that the activities performed were directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science. In this case, the project in question involved a commercially purchased system and complex software configuration design development, see the excerpt below:
…the cover letter from IBM explains that the Design Proposal was prepared to assist with the ‘Design and configuration’ of the JDE OneWorld application suite and move Mueller as quickly as possible to OneWorld via a four-stage approach referred to as the “IBM JD Edwards Practice’s Turbo BLUE Methodology…”
Both of these elements (commercially purchased and configuration design) are major red flags for the IRS.
The Court reviewed a number of evidential documents provided by the IRS and very little to nothing from the Davenports who relied primarily on oral testimony. The context of the documents obviously steered the Court’s findings that proved too much for the testimonial evidence provided by the Davenports. It is so critical in these claims to understand where and how the IRS will perceive a claim and then perform the due diligence to ensure your claim substantiation is appropriate in answering these issues. In this case, the claim defense did not adequately address the purchased software issue or the configuration issue. There was nothing discussed in the case that indicated the defense argued to the uniqueness or innovation of the new software and thus their claim was destined to be denied.
When developing an IUS claim, it is always helpful to view the project with an eye on the nature of the design development process and the application outcome attempting to be resolved. If the upfront nature of the project proves to meet the uncertainty test (Is the project unique and innovative; and does it require activities to discover information to resolve the uncertainties with creating this unique or innovative application?), then focus on developing details and substantiation related to the development process being utilized to resolve the uncertainty. This was not done in the Davenport case, see the excerpt below:
The evidence establishes that the testing performed by IBM and Mueller was not done to test and refine a hypothesis to determine the strengths and weakness of the alternative tested or to determine whether other alternatives might be better suited for achieving the Davenport’s goal.”
Does the process involve development, testing and revision? Were there major changes in development scope and/or outcomes and how were these issues resolved? What were the major software design issues that had to be resolved? These are the questions that when answered will provide your claim the best possible substantiation and potential success.
For more information on BCP’s R&E Tax Services, please contact:
Gregory J. Lormand: [email protected]