Firm Suggests Refinement of Proposed Research Credit Regs

We are writing on behalf of the Software Coalition¹ to provide comments on the recently proposed Treasury Regulations under section 41 of the Internal Revenue Code relating to the application of the research credit to internal use software (hereinafter the "Proposed Regulations").² Treasury has done a commendable job in drafting a set of regulations that attempt to bring much needed clarity to the challenging issue of internal use software. However, ambiguities in the Proposed Regulations may undermine this effort. With refinements, the Proposed Regulations have the potential to accurately reflect the evolving realities of the software industry, and thereby reduce uncertainty as to the proper application of these rules. We appreciate the opportunity to provide comments on these regulations, and hope that our comments will be useful to Treasury in finalizing these rules in a manner that encourages innovation and economic growth in the United States.

Comments on the Proposed Regulations

The research credit under section 41 was enacted in 1981 to encourage U.S. businesses to increase expenditures on research and experimentation as part of a broader initiative to increase the global competitiveness of U.S.-based businesses and to foster productivity and economic growth in the United States. While the specific provisions of the research credit have gone through changes over time, the credit still serves this basic purpose of promoting technological innovation in the United States.

Section 41(a) allows a research credit for certain "qualified research expenses" for a given taxable year. Section 41(d)(4)(E) provides that, except as provided in regulations, "qualified research" does not include "research with respect to computer software which is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer", unless the software is for use in (i) an activity which constitutes qualified research, or (ii) a production process that otherwise meets the requirement for qualified research.³ Based on the legislative history to section 41(d)(4)(E), the Proposed Regulations also provide that computer software which is developed primarily for internal use by the taxpayer can still be treated as qualified research if it also meets the "high threshold of innovation test" of Prop. Treas. Reg. § 1.41-4(c)(6)(v).⁴

A. Definition of Internal Use Software

The Proposed Regulations represent the latest effort to define "computer software which is developed . . . primarily for internal use" in a manner that best reflects the intent of the statute. The 1986 legislative history to section 41(d)(4)(E) suggested that internal use might include use "in general and administrative functions (such as payroll, bookkeeping, or personnel management) or in providing non-computer services (such as accounting, consulting, or banking services)."⁵ As noted in the Preamble to the Proposed Regulations, Congress later acknowledged the rapid pace of technological advance in software, particularly related to the use of software in service industries, and suggested that software not be considered for internal use merely because it was used by the taxpayer to support to the provision of a service.⁶ In the Proposed Regulations, therefore, Treasury eliminated any further distinction between computer and non-computer services, and explained its reasoning as follows:

Consistent with this basic principle, computer software should be considered to fall within the scope of Section 41(d)(4)(E) only if the software was developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business. However, we are concerned that an examiner might try to argue that software developed for use in general and administrative functions is merely one type of software that might be developed primarily for the taxpayer's internal use. Therefore, for the avoidance of any doubt as to the proper interpretation of this provision, we would suggest the following minor amendment to paragraph (c)(6)(iii)(A) of the Proposed Regulations:

The Proposed Regulations define "general and administrative functions" as (i) financial management functions that involve the financial management of the taxpayer and the supporting recordkeeping; (ii) human resource management functions that manage the taxpayer's workforce; and (iii) support services functions that support the day-to-day operations of the taxpayer. The Proposed Regulations then offer reasonably detailed lists of the sort of functions included within these three categories.

This detailed and specific definition of general and administrative functions should help substantially reduce the level of uncertainty and controversy regarding the proper scope of internal use software. That said, we are concerned that many of the functions listed in the definition of general and administrative functions could be interpreted in a manner inconsistent with the general intent of targeting "back-office" functions of the taxpayer. As noted in the Preamble to the Proposed Regulations, tax software developed by a company engaged in providing tax services to its customers "is not used by the taxpayer in a general and administrative function," even though "tax" is listed in paragraph (c)(6)(iii)(B)(1) as a general and administrative function. We believe that this concept should be made more explicit in the regulations, and would suggest the following additional language be added to the end of paragraph (c)(6)(iii)(A):

Even if software is developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business, such software "does not solely benefit the taxpayer" if it is developed to be used by third parties or in connection with the taxpayer's provisions of goods or services to third parties. The Proposed Regulations provide that, even if one of the motivations underlying a software development project is that the software be used in the taxpayer's own general and administrative functions, computer software is deemed to be not developed "primarily" for the taxpayer's internal use if either (1) the software is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties; or (2) the software is 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.⁸

These provisions leave open certain interpretational issues. First, paragraph (c)(6)(iv)(A)(1) presumably is intended to describe the commercial exploitation of the developed software, not just through sale, lease or license of the software itself, but also through other types of transactions whereby the taxpayer effectively will provide to a third party the functionality of the software, even if there is no transfer of a copy of the software itself to such third party. We therefore recommend that the following language be added to the end of paragraph (c)(6)(iv)(A) as flush language after (c)(6)(iv)(A)(2):

D. Time of Determination

According to the Proposed Regulations, whether either of the exceptions in paragraph (c)(6)(iv)(A) applies "depends on the intent of the taxpayer and the facts and circumstances at the beginning of the software development." If the taxpayer's intended use of the software changes after development has begun, then such change only applies to improvements made after the point in time when such intended use has changed.⁹ In practice, taxpayers likely will have difficulty substantiating their intended use of the software at the very beginning of the development process. Many research projects are begun without a clear sense of whether a viable commercial use for the software will exist. Furthermore, if it becomes clear at a later point in time that there is a market for the software, there may be no specific "improvements" to the software that are created in order to sell, lease, license, host or otherwise market the software to third parties. Instead, the ongoing development of the software may relate to functions that are arguably relevant regardless of whether the intended use of the software changed or not. Therefore, we suggest that paragraph (c)(6)(iv)(B) be amended to look to the intended use of the software, and not just the improvements, as of the tax return filing date for the taxable year in which the software development expenditures were incurred, since that is realistically the most appropriate point in time to expect taxpayers to document the facts underlying the return. As a second best alternative, we would suggest determining the intended use of the software, and not just the improvements, as of the beginning of the taxable year in which the software development expenditures were incurred.

E. Dual Function Computer Software

Of greatest concern to our members are the rules relating to "dual function computer software". The Proposed Regulations establish a presumption whereby computer software developed "both for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business and to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data (dual function computer software) is presumed to be developed primarily for a taxpayer's internal use."¹⁰

The taxpayer can only rebut this presumption with respect to an identified subset of elements that "only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data".¹¹ For any remaining dual function subset, 25% of the expenditures can be claimed if "the dual function subset's use by third parties or by the taxpayer to interact with third parties is reasonably anticipated to constitute at least 10 percent of the dual function subset's use."¹²

This rule likely will result in much software being characterized as developed primarily for the taxpayer's own internal use that otherwise should have been treated as falling outside of section 41(d)(4)(E). Paragraph (c)(6)(iv)(C) of the Proposed Regulations fails to take into account that software systems cannot always be broken into mutually exclusive subsets enabling only internal use or third-party functionality. Software systems contain a variety of general use components of benefit system-wide. Further, it is not uncommon for companies to develop software for the primary purpose of enabling interaction with third parties, but which is also used incidentally for internal general and administrative functions. In either of these two scenarios, it would generally not be possible to identify a discrete element of software functionality that was only intended to enable interaction with third parties, leading to a presumption that such software was developed primarily for internal use.

At a minimum, paragraph (c)(6)(iv)(C) imposes on taxpayers an unreasonable burden of substantiating subsets of software elements that only relate to third parties in order to qualify for the research credit. According to the legislative history to section 41, Congress was "concerned about unnecessary and costly taxpayer record keeping burdens and reaffirm[ed] that eligibility for the credit is not intended to be contingent on meeting unreasonable record keeping requirements."¹³ The presumption of development for internal use is contrary to the intent of the statute, and will likely reduce the effectiveness of this provision in encouraging research expenditures.

Therefore, we have two recommendations regarding the dual function software rule. First, we believe that the internal use presumption of paragraph (c)(6)(iv)(C)(1), properly interpreted, does not apply to computer software developed to be commercially sold, leased, licensed, hosted, or otherwise marketed to third parties. Nevertheless, we are concerned that an examiner might try to argue that the dual function computer software rule could apply to software described in paragraph (c)(6)(iv)(A)(1) if such software is also described in paragraph (c)(6)(iv)(A)(2). Therefore, we recommend that paragraph (c)(6)(iv)(C)(1) should explicitly cross reference paragraph (c)(6)(iv)(A)(1) in order to eliminate any doubt that the dual function software rule does not apply to computer software developed to be commercially sold, leased, licensed, hosted, or otherwise marketed to third parties, even if such software was also developed to enable a taxpayer to interact with third parties (e.g., the customers who purchase cloud-based software services from the taxpayer) or to allow third parties to initiate functions or review data on the taxpayer's system. Second, the presumption of internal use should be replaced with a primary purpose test, consistent with the statutory language that looks to whether software is developed "primarily" for internal use. Therefore, we recommend that paragraphs (c)(6)(iv)(C)(1) and (c)(6)(iv)(C)(2) be amended as follows:

The Proposed Regulations provide that paragraph (c)(6) will be applied prospectively for taxable years ending on or after the date of publication of final regulations in the Federal Register, but that the IRS will not challenge return positions consistent with the Proposed Regulations for taxable years ending on our after January 20, 2015. According to the legislative history to section 41, Congress intended that regulations relating to internal use software would apply as of the effective date of section 41(d)(4)(E).¹⁴ While it is true that a long time has elapsed since Congress made this statement in 1986, applying these regulations on a prospective basis only will impose upon taxpayers an unreasonable burden of accounting for these transactions differently in different taxable years. We recommend, therefore, that the IRS not challenge return positions consistent with the Proposed Regulations for any open taxable years ending on or after the effective date of section 41(d)(4)(E). We believe that these Proposed Regulations constitute the best expression of Congressional intent regarding the encouragement of software development in support of the provision of valuable goods and services to third parties, and as such there is no reason to not apply these rules to all open years.

G. Comments on Existing Examples in Prop. Treas. Reg. § 1.41-4(c)(6)(vi)

² Prop. Treas. Reg. § 1.41-4, Fed. Reg. Vol. 80, No. 12, p. 2624 (Jan. 20, 2015).

³See also, Prop. Treas. Reg. § 1.41-4(c)(6)(i)(C).

⁴ Prop. Treas. Reg. § 1.41-4(c)(6)(i)(C)(3).

⁵ H.R. Rep. No. 841, 99th Cong., 2d Sess. (1986).

⁶ H.R. Rep. No. 478, 106th Cong., 1st Sess. (1999).

⁷ Prop. Treas. Reg. § 1.41-4(c)(6)(iii)(A).

⁸ Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(A).

⁹ Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(B).

¹⁰ Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(C)(1).

¹¹ Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(C)(2).

¹² Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(C)(3).

¹³ H.R. Rep. No. 478, 106th Cong., 1st Sess. (1999).

¹⁴ H.R. Rep. No. 841, 99th Cong., 2d Sess. (1986).