CIP addresses three-part exception for internal-use software development.

The IRS recently released a Coordinated Issue Paper (CIP) addressing the three-part exception to the exclusion from the definition of "qualified research" for internal-use software. To focus the scope of the CIP's analysis of the three-part internal-use software exceptions, the Service assumes, solely for purposes of the CIP that the general tests of qualified research under Sec. 41(d)(1)(A), (B) and (C) have been met.

The CIP attempts to apply the exceptions for internal-use software to a taxpayer installing, maintaining and enhancing a pre-packaged software system, rather than internally developing its own system. From the legislative history, it is clear that Congress intended to allow the research credit for internal-use software only in certain exceptional situations. However, in the IRS's attempt to clarify these exceptions, it takes some rather extreme positions that do not seem to be based either on the legislative history or existing law.

Innovativeness Test

The first requirement of the internal-use software exception is that the software be innovative. "Innovative" is described in the legislative history as a reduction in cost or improvement in speed that is substantial and economically significant. In the Service's view, the "substantial" requirement focuses on the quantity of cost savings or magnitude of the improvement in speed attributable to the software. Noting that no bright-line test of substantial cost savings exists, the IRS determined that the taxpayer's 80% reduction in costs would satisfy this requirement.

In determining whether a reduction in cost or improvement in speed is economically significant, the Service takes a position that would require a taxpayer to prove that a software system provides a competitive advantage over software performing similar functions elsewhere in the industry; implementing a software package to reduce a competitive disadvantage resulting from the use of substandard software would not appear to meet this test. The IRS's position is unsupported by the legislative history. Rather, it seems to be loosely based on a statement by the Tax Court in Norwest Corp., 110 TC 454 (1998). In Norwest, the court cited the maximization of certain software capabilities, giving Norwest a clear advantage over its competitors, as evidence that the software's benefits were economically significant. It seems the Service is attempting to make obtaining a competitive advantage the test rather than viewing it as evidence that the test has been met.

In the CIP, the IRS seems to be creating a third standard for satisfying the innovativeness test. Even if a taxpayer fails to show that its development activity resulted in an economically significant reduction in cost or improvement in speed, it may still meet this requirement if it can prove that the software system is in fact innovative, defined by the Service as novel or unique. While there is no basis for this substitute standard of innovativeness in the legislative history or current proposed or final regulations, it may prove to be taxpayer-favorable by providing an additional opportunity to satisfy the test.

Significant Economic Risk Test

The second requirement of the internal-use software exception is that the software development involve significant economic risk (such as committing substantial resources to development and recovering such resources within a reasonable period) and substantial uncertainty due to technical risk.

The IRS notes several factors that can be considered in determining whether a taxpayer has committed "substantial" resources, including:

1. Amount spent on the activity, as compared to the taxpayer's net assets;

2. Number of hours computer programmers spent on the activity, as compared to the number of hours they spend overall on software development per year;

3. Amount paid or budgeted for the software project, as compared to the taxpayer's total annual information technology budget;

4. Amount paid or budgeted for the software project, as compared to amount paid or budgeted for all research projects during the same period; and

5. Level of management approval, if any, required under a taxpayer's budgetary procedures before it commits funds to a software-project, to the extent that the approval process defines the taxpayer's own assessment of what constitutes substantial commitment.

Noting that no bright-line test exists, the: Service determines that a $450,000 development project, representing less than 1% of the taxpayer's $50 million in net assets, does not appear to be substantial.

Technical risk must contribute to the uncertainty of recovering resources within a reasonable period. Thus, the IRS attempts to distinguish "technical risk" from "business risk" and in doing so stretches the significant economic risk test to new boundaries. In language that appears to be antithetical to Congress's test, the Service takes the position that the uncertainty of whether a taxpayer can complete its development activities on time and within budget is a business risk, not a technical risk. The IRS also seems to take the position that technical risk requires that there be uncertainty as to whether the software can be developed at all, rather than within a reasonable time (as the legislative history states).

The Service lists several factors in determining whether technical risk is the cause of the substantial uncertainty that a company's commitment of resources to a development project will not be recovered within a reasonable period:

1. Size and complexity of the programming task-and the project as a whole;

2. The programming task used existing technologies and known programming methods;

3. Similar programming tasks had been completed before;

4. The software system provided functionality not offered in any other software;

5. The company attempted to employ existing technology in a new and dynamic way;

6. The programming task was successfully completed;

7. If the project failed, was abandoned or was significantly delayed, and technical risks, as opposed to business-related risks, contributed to this outcome; and

8. The company considered and accounted for technical risk in deciding whether to fund software system development and in monitoring the progress of the development activities.

In a somewhat illogical analysis, the IRS develops a new standard to meet the significant economic risk test. Rather than follow Congress's test (which requires only that there be substantial uncertainty due to technical risk as to whether a taxpayer can recover its resources within a reasonable time), the Service states, "technical risk must be so great that it would prevent a reasonably competent software developer from confidently predicting a completion date for a project." In the CIP, the IRS determines that it is unlikely that the taxpayer could not confidently predict a completion date for each aspect of its development activity. Based on this determination and the determination that the taxpayer did not commit substantial resources, the Service concludes that the software development activity did not involve significant economic risk.

Commercial Availability Test

The third requirement of the internal-use software exception is that the software must not be commercially available for use by a taxpayer (i.e., it cannot be purchased, leased or licensed and used for the intended purpose without modifications that would satisfy the first and second requirements of the exception). In the CIP, the IRS determines that, because the taxpayer's modifications failed the innovativeness and significant economic risk tests, they necessarily fail the commercial availability test.

Although the CIP is plausible, its release is still somewhat unsettling, as it seems to create several new general requirements for internal-use software. For instance, in analyzing the significant economic risk test, the Service may use the CIP as support for categorically denying the research credit for all internal-use projects funded by an investment of less than 1% of net assets. For a taxpayer with net assets of $2 billion, this could translate into the denial of any project costing less than $20 million. The IRS may also attempt to disqualify an internal-use project based on evidence of an engineer's estimate of a completion date. Neither the law nor the proposed regulations disallow either of these situations. However, they would seem to disqualify an internal-use software project under the CIP.

On the positive side, the CIP provides some indication of factors that the Service can use as evidence that internal-use software exceptions, particularly the significant economic risk test, have been met.

FROM SARA McCLELLAND AND DAVID HUDSON, WASHINGTON, DC