Source: http://www.fgmk.com/news-resources/thought-leadership/rd-tax-credit-internal-use-software-finally-defined/
Timestamp: 2017-09-21 14:05:55
Document Index: 575040474

Matched Legal Cases: ['§ 41', '§ 1', '§ 41', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 41', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1']

R&D Tax Credit - Internal Use Software "Finally" Defined | FGMK
R&D Tax Credit - Internal Use Software "Finally" Defined
Since the inception of the credit for increasing research activities (“R&D tax credit”), taxpayers have faced uncertainty as to the definition of Internal Use Software (“IUS”). On October 4, 2016, the Department of the Treasury and the IRS published final regulations that provide long-sought clarification.
IUS versus Non-IUS
The final regulations adopt the proposed regulations’ definition of IUS as software developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of a taxpayer’s trade or business.[1] General and administrative functions are limited to financial management functions, human resource functions, and support services functions.[2] Although commentators expressed concern as to the broad scope of “general and administrative functions”, the Treasury Decision provides that the “dual function” rules address this concern.
Importantly, the Treasury Department and the IRS “continue to believe that functions such as inventory management, marketing, legal services, and government compliance services provide support to day-to-day operations of a taxpayer in carrying on a trade or business regardless of the taxpayer’s industry, and that the benefits that such functions may provide to third parties are collateral and secondary.”[3] Therefore, taxpayers should expect IRS scrutiny of software developed for these functions.
Conversely, the final regulations assert that software is not presumed to be IUS if it is developed to be “commercially sold, leased, licensed, or otherwise marketed to third parties.”[4] The Treasury Decision declines commentators’ requests for the inclusion of “hosted” in the quoted language, and further definition of “otherwise marketed”.[5] Rather, it concludes the language is “sufficiently broad to encompass hosted software and other software where there is no transfer of a copy of the software.”
The final regulations also adopt the proposed regulations’ taxpayer-favorable, non-IUS presumption for 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.[6] The final regulations define “third party” as any corporation, trade or business, or other person that is not treated as a single taxpayer with the taxpayer pursuant to IRC § 41(f).[7] The Treasury Decision rejects a commentator’s proposal to remove language that states third parties do not include any persons that use the software to support the taxpayer’s general and administrative functions that facilitate or support the taxpayer’s trade or business, e.g. vendors.[8] Rather, it provides, “Where a taxpayer develops software for internal use, any benefit to others, such as vendors or those who provide support services to the taxpayer, is collateral and secondary.”[9]
“High Threshold of Innovation” Test
The distinction between IUS and non-IUS is critical, because IUS must meet additional criteria to qualify for the credit:
Software must be innovative, in that it results in a reduction of cost, improvement of speed, or other measurable improvement;
The software development must entail significant economic risk, in that the taxpayer commits substantial resources to the development, and there is substantial uncertainty, because of technical risk, that such resources will be recovered in a reasonable period; and
(3) Software is not commercially available for use by the taxpayer, in that it cannot be purchased, leased, or licensed, and used without modifications that would satisfy the first two requirements.
The final regulations provide another taxpayer-favorable modification to the proposed regulations, as they allow the consideration of design uncertainty in the evaluation of technical risk under the “significant economic risk” test. However, the Treasury Department and the IRS caution that IUS research activities that involve only design uncertainty would rarely satisfy the substantial uncertainty standard under the “significant economic risk” test.[10]
The “high threshold of innovation” test does not apply to software developed for use in an activity that constitutes qualified research, or to software developed for utilization in a production process.[11] In addition, the final regulations clarify that the test is not applicable to a new or improved package of software and hardware developed together by the taxpayer as a single product.[12]
Software developed for internal use in general and administrative functions that facilitate or support the conduct of a taxpayer’s trade or business and enable third party interaction will be presumed to be IUS. However, if a taxpayer can identify a subset of activities related to third party interaction, the presumption of IUS will not apply to the subset.[13]
The final regulations provide additional clarification that the safe harbor test can apply to the dual function software (or the dual function subset) after application of the third-party interaction provision at § 1.41-4(c)(6)(vi)(B).[14] The safe harbor test allows the taxpayer to claim 25% of the related development costs if the third-party interaction is reasonably anticipated to constitute 10% or more of the dual function software or dual function subset’s use.[15]
Time & Manner of Determination
Whether or not software is developed for internal use depends on the intent of the taxpayer and the facts and circumstances at the beginning of software development.[16] The Treasury Decision states that this standard was consistent with the intent and purpose of section 41.[17] In reaching that conclusion, the Treasury Department and the IRS declined to implement a commentator’s request for consideration of changes in intent during development, as well as requests to analyze the use of software, not just improvements, at the time the return is filed, or use of the software at the time it is placed in service.[18]
However, the final regulations do adopt the proposed regulations’ special rule for improvements to software that can be separately identified.[19] Therefore, if a taxpayer undertakes an initial development project for internal use, but later undertakes a separate improvement project with the intent to sell, license, lease, or otherwise market the software, or to provide third-party interaction, then the taxpayer’s later development efforts can avoid the IUS presumption.
Similar to the determination as to whether development is IUS or non-IUS, the determination of the application of the dual function safe harbor must occur at the beginning of software development.[20]
The Treasury Decision includes a discussion of “connectivity software”, which it clarifies is sometimes referred to as bridging software, integration software, or middleware. The Treasury Department and the IRS received few comments on this topic and determined that a special rule for connectivity software was not needed. The Treasury Decision notes that connectivity software is often purchased or has been diminished due to the use of ERP software.[21] Moreover, it provides, “whether certain software is developed to be used primarily for internal use should be based on the function the software provides, rather than the type of software.”[22]
The final regulations are prospective only. While the IRS will not challenge tax return positions consistent with the IUS provisions of the final regulations for taxable years ending on or after January 20, 2015, taxpayers may only elect to apply T.D. 8930 or the 2001 proposed regulations for taxable years ending before January 20, 2015.[23] The Treasury Decision asserts that retroactive application of the final regulations would provide an unfair advantage to taxpayers whose prior taxable years are not closed by the statute of limitations. Moreover, it provides that the retroactive application would not further the purpose of § 41.
The final regulations’ clarification of the definition of IUS, as well as the examples provided therein, establish long-sought standards for qualification. Although the IRS and taxpayers may continue to disagree as to whether certain software development activities meet the qualification standards, they now have established standards against which to measure their arguments.
[1] Treas. Reg. § 1.41-4(c)(6)(iii)(A), Treasury Decision 9786
[2] Treas. Reg. § 1.41-4(c)(6)(iii)(B).
[3] T.D. 9786 at 4 (The Treasury Decision also provides that the dual function rules address commentators’ concerns).
[4] Treas. Reg. § 1.41-4(c)(6)(iv)(A).
[5] T.D. 9786 at 7.
[6] Treas. Reg. § 1.41-4(c)(6)(iv)(B).
[7] Treas. Reg. § 1.41-4(c)(6)(vi)(E).
[11] IRC § 41(d)(4)(E); Teas. Reg. § 1.41-4(c)(6)(ii).
[12] Teas. Reg. § 1.41-4(c)(6)(ii)(C) (The 1997 proposed regulations introduced the single product exception).
[13] Treas. Reg. § 1.41-4(c)(6)(vi)(B).
[14] Treas. Reg. § 1.41-4(c)(6)(vi)(C).
[16] Treas. Reg. § 1.41-4(c)(6)(v).
[17] T.D. 9786 at 11.
[20] Treas. Reg. § 1.41-4(c)(6)(vi)(D).
[21] T.D. 9786 at 8.
[22] T.D. 9786 at 9.
[23] As set forth in CCA 2014-052909222361, the IRS will not challenge taxpayers who follow only the IUS provisions of T.D. 8930 but follow T.D. 9104 for the general eligibility rules (no application of the “discover” test).