How Does Developing Internal-Use Software Effect the R&D Credit
In general, software that is developed by or for the benefit of the taxpayer primarily for internal use will need to satisfy three additional tests (as well as the four-part test previously discussed) in order to qualify for the R&D credit. These three tests are collectively referred to as the “high threshold of innovation” test. Thus, correctly identifying what is and is not internal-use software is important. Regs. Sec. 1.41-4(c)(6)(iv) defines software not for internal-use as:
- Software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties; or,
- Software developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system.
Software that falls under either of these two categories will not have to pass the high-threshold of innovation test and will only need to satisfy the four-part test in order to qualify.
Additionally, the regs provide the following exemptions to the definition of internal-use software:
- Software developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer for use in an activity that constitutes qualified research (other than the development of the internal use software itself);
- Software developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer for use in a production process to which the four-part test is met; and
- A new or improved package of software and hardware developed together by the taxpayer as a single product (or to the costs to modify an acquired software and hardware package), of which the software is an integral part, that is used directly by the taxpayer in providing services in its trade or business. In these cases, eligibility for the research credit is to be determined by examining the combined hardware-software product as a single product.
If the software is found to be primarily for internal use, the high-threshold of innovation test under Regs. Sec. 1.41-4(c)(6)(vii) must be met. The three requirements that must be met in order to qualify for the R&D credit are the following:
- The software is innovative: software is innovative if the software would result in a reduction in cost or improvement in speed or other measurable improvement, that is substantial and economically significant, if the development is or would have been successful. This is a measurable objective standard, not a determination of the unique or novel nature of the software or the software development process.
- The software development involves significant economic risk: The software development involves significant economic risk if the taxpayer commits substantial resources to the development and if there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period. The term “substantial uncertainty” requires a higher level of uncertainty and technical risk than that required for business components that are not internal use software (i.e. under the four-part test). This standard does not require technical uncertainty regarding whether the final result can ever be achieved, but rather whether the final result can be achieved within a timeframe that will allow the substantial resources committed to the development to be recovered within a reasonable period. Technical risk arises from uncertainty that is technological in nature, and substantial uncertainty must exist at the beginning of the taxpayer's activities.
- The software is not commercially available for use by the taxpayer in that the software cannot be purchased leased, or licensed and used for the intended purpose without modifications that would satisfy the previous two requirements.
In situations where software is developed for both internal use and interaction with third parties (“dual-function software”), the software is presumed to be internal-use software. Per Regs. Sec. 1.41-4(c)(6)(vi), to the extent a taxpayer can identify a subset of the dual function software that only enables the taxpayer to interact with third parties or allows third parties to initiate functions or review data, then this subset will not be treated as internal use software and the development will only need to satisfy the four-part test to qualify for the R&D credit.
Additionally, the regulations provide for a safe harbor. If, after identifying a subset of the dual function software that is not deemed for internal use, there remains dual function software then the taxpayer may include 25% of the QRE related to the dual function software. Specific examples of the application of these rules are provided in Regs. Sec. 1.41-4.