06 October 2016 EY Tax Alert provides in-depth analysis of new final regulations on internal-use software under Section 41 On October 4, 2016, the IRS and Treasury Department published final regulations (TD 9786) on rules related to software development for purposes of the research credit. The final regulations are generally consistent with proposed regulations published on January 20, 2015 (REG-153656-03), but modify the proposed regulations in a few key ways. — Clarify what is internal-use software and what is not internal-use software The final regulations also modify the examples demonstrating the process of experimentation under Section 41 to add examples showing the application of the process of experimentation requirement in the context of computer software. The final regulations are effective for tax years ending on or after October 4, 2016, the publication date of the final regulations; however, the final regulations state that the IRS will not challenge return positions that are consistent with the final or proposed regulations for tax years beginning before October 4, 2016 and ending on or after January 20, 2015 (the publication date of the proposed regulations). Since its enactment in 1986, Section 41(d)(4)(E) has provided special rules applicable to determining if development activities related to internal-use computer software (IUS) constitute qualified research for purposes of computing the research credit. Specifically, Section 41(d)(4)(E) restricts the application of the credit for IUS development activities, unless those activities satisfied additional criteria. The treatment of IUS under Section 41 has been a controversial area for taxpayers claiming the research credit for a number of reasons, including several pieces of vague and conflicting guidance issued by the IRS related to IUS. On January 20, 2015, the IRS issued proposed regulations that define when software is developed primarily for internal use for purposes of Section 41, clarify when certain IUS eligible for the research credit satisfies the "high threshold of innovation" test, and introduce new guidance for software that is developed for both internal and non-internal use (dual-function software). (For details on the proposed regulations, see Tax Alert 2015-131.) Comments were requested on the proposed regulations and several were submitted. After considering the comments, the government rejected most of them. The proposed regulations are made final in TD 9786, with a few important changes and clarifications. The final regulations make a structural change to the proposed regulations to identify three circumstances in which the IUS rules do not apply (instead of subjecting them to the IUS rules, and providing an exception, as is the case in the proposed regulations): software developed for use in an activity that constitutes qualified research; software developed for use in a production process; and a hardware/software package developed together. The first two circumstances reflect statutory exceptions to the exclusion of IUS from the term "qualified research" (see Section 41(d)(4)(E)(i) and (ii)). The last circumstance is a long-standing exclusion for hardware/software packages that are evaluated as a single non-IUS product. Under the final regulations, software is developed by (or for the benefit of) the taxpayer primarily for internal use if the software is developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business. This definition includes software that the taxpayer develops primarily for a related party's internal use. The final regulations limit "general and administrative functions" for this purpose to financial management functions, human resource management functions, and support services functions (e.g., data processing or facilities services). The definition of general and administrative functions in the final regulations is consistent with the definition provided in the proposed regulations. The preamble to the final regulations discusses commenters' concerns that the definition of general and administrative functions was overbroad and included software functions that did not only represent "back office" functions. In particular, commenters identified marketing supported by software and inventory software as examples of software that may provide benefits to third parties. The IRS and Treasury noted that modern software systems may provide more than back office functions, and identified the regulations relating to dual-function software as the appropriate rules for evaluating whether such software is IUS. The preamble further states that the government believes 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 business regardless of the taxpayer's industry and that the benefits that such functions may provide to third parties are collateral and secondary," which will have implications as to whether software related to those functions is treated as IUS. The definition of software not developed primarily for internal use in the final regulations is the most significant change from the proposed regulations. The final regulations modify the definition to state that "software is not developed primarily for the taxpayer's internal use if it is not developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business … " The final regulations use, as examples of software not developed primarily for internal use, the items included in the proposed regulations' definition of software not developed primarily for internal use. Those examples include software "developed to be commercially sold, leased, licensed, or otherwise marketed to third parties," and 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." This subtle but important change results in a new paradigm under the final regulations: if software is not developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business, it is not IUS. In the preamble to the final regulations, the IRS and Treasury addressed some commenters' concerns about terms used in the proposed regulations to describe software not developed primarily for internal use. Specifically, a commenter requested that hosted software be specifically included and the term "otherwise marketed" include software whose full functionality is provided, though there is no transfer of a copy of the software. Although the government responded that the existing terms are broad enough to include hosted software and software that is not transferred, a new example was added to the regulations (Example 9) to demonstrate that cloud-based enterprise application software, developed to be accessed online by the taxpayer's customers, is not IUS (not developed for use in a general or administrative function). An example in the proposed regulations was also revised to clarify that software for a restaurant website, developed for advertising, is IUS (as it was developed for use in a general and administrative function) (see Example 4). Consistent with the proposed regulations, the final regulations provide a time and manner of determination rule regarding the character of software developed by the taxpayer: whether software is developed primarily for internal use or non-internal use depends on both the intent of the taxpayer and the facts and circumstances at the beginning of the software development. The rule further provides that, if software is originally intended for internal use, but later improved for non-internal use, the improvements will be considered separate from the initial development and treated as not for internal use. Similarly, if software is originally intended for non-internal use, but then improved for internal use, the latter improvements will be treated separately as for internal use. Although the government received comments regarding substantiation concerns and requesting that the time and manner of determination rules take into account facts and circumstances that arise during or after software development or establish a rebuttable presumption, the final regulations did not revise the time and manner of determination rules that were provided in the proposed regulations. In response to the commenters' concerns, the preamble states that "only a rule that generally requires that a determination be made at the beginning of software development is consistent with the intent and the purpose of section 41 … [A]llowing a taxpayer to redetermine the overall project's credit eligibility throughout the development which could span multiple years would provide uncertain and inconsistent treatment and impose an undue burden on both taxpayers and the IRS." The preamble to the proposed regulations requested comments regarding the characterization and treatment of connectivity software (bridging software, integration software, or middleware). The final regulations do not provide a specific rule for connectivity software. The preamble notes that connectivity software does not require special rules and should not be specifically categorized, but is subject to the general rules for determining whether software is IUS. The final regulations provide guidance on dual-function software, that is, software developed by (or for the benefit of) the taxpayer both for: (1) use in general and administrative functions; and (2) to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data. This guidance is consistent with the proposed regulations. The final regulations retain the presumption in the proposed regulations that dual-function software is IUS. There were several comments on different aspects of the dual-function software rules. The IRS and Treasury Department rejected most of these comments, and left the dual-function software rules that were in the proposed regulations largely unchanged. The government responded to the suggestion to apply a shrink-back analysis to dual-function software by noting that the dual-function rules already apply a shrink-back approach that allow a taxpayer to identify the software used to interact with third parties (third-party subset) of its software that is not subject to the dual-function rules and, therefore, need not be treated as IUS. As noted, if a third-party subset of software can be identified, that software is not considered IUS. Although commenters argued that the dual-function software safe harbor articulated in the proposed regulations was complicated and inequitable, the final regulations retain that safe harbor, but clarify that the safe harbor can apply to the dual-function software or the dual-function subset (a subset of elements that are dual-function software). Consistent with the proposed regulations, under the safe harbor provided in the final regulations, taxpayers may include 25% of the qualified research expenses of the dual-function software or dual-function subset in computing the amount of the taxpayer's credit, if the use of the dual-function software or dual-function subset by third parties or by the taxpayer to interact with third parties is reasonably anticipated to constitute at least 10% of the dual-function subset's use. For measurement purposes, the government agreed with a commenter that identification of a reasonable method for determining anticipated third-party use of the dual-function software may depend on the taxpayer's industry. The final regulations, therefore, clarify that "an objective, reasonable method within the taxpayer's industry must be used to estimate the dual-function software or dual-function subset's use by third parties or by the taxpayer to interact with third parties." The preamble states that identification of a single method to estimate anticipated third-party use was not realistic, and the final regulations provide examples of objective, reasonable methods (processing time, amount of data transfer, and number of software user interface screens). The preamble states that the beginning of the development is the most accurate and appropriate time for determining anticipated use. The final regulations provide rules of implementing the three-part "high threshold of innovation test" that must be satisfied before IUS development can be considered qualified research. As noted in the preamble to the proposed regulations, the high threshold of innovation test reflects the legislative history of Section 41(d)(4)(E). The final regulations retain the high threshold of innovation standards of the proposed regulations, with one significant modification related to the significant economic risk test (described below). The proposed regulations stated that it is not always necessary to have a revolutionary discovery or the creation of new technology to satisfy the test. The preamble to the final regulations explains that a commenter was concerned that the inclusion of this language would lead to a negative inference that, in some cases, it is necessary to have a revolutionary discovery or the creation of new technology to satisfy the test. The final regulations do not retain the language referring to a "revolutionary discovery." This discussion in the preamble to the final regulations may be helpful in responding to positions raised by the IRS during an examination that require a taxpayer to show that its software is revolutionary or represents a new technology in order to claim the research credit. Under the final regulations, software is innovative if the software would result in a reduction in cost, improvement in speed or other measurable improvement that is substantial and economically significant, if the development is or would have been successful. Thus, the test does not require the software to be developed, only that an improvement would have resulted if the software had been developed. The preamble to the final regulations does not discuss any comments received with respect to the innovative test. Examples 15-18 of the final regulations, which address the application of the high threshold of innovation, demonstrate that the innovative standard is not unreasonably high. The final rule relating to the innovative standard is consistent with the proposed regulations. Under the final regulations, software development involves significant economic risk when the taxpayer commits substantial resources to the development and there is substantial uncertainty, because of technical risk, whether such resources would be recovered within a reasonable period. The test is applied to the level of uncertainty at the outset of software development. Under the proposed regulations, substantial uncertainty did not exist if the only uncertainty at the beginning of the taxpayer's activities related to design uncertainty. The proposed regulations required that the information available to the taxpayer did not establish the capability or method for developing or improving the software. The government received several comments requesting modification of the significant economic risk test, particularly that technical uncertainty, for purposes of the significant economic risk test, not be restricted to capability and/or methodology uncertainties, as defined in Reg. Section 1.174-2(a). The preamble to the final regulations provides that, because of the difficulty of segregating one type of uncertainty from another, the final regulations do not adopt the proposed regulations' requirement that only capability and/or methodology uncertainties (and not design uncertainties) satisfy the significant economic risk test. Instead, the preamble states that "the focus of the significant economic risk test should be on the level of uncertainty that exists and not the types of uncertainty." The preamble notes, however, that the IRS and Treasury "believe that internal use software research activities that involve only uncertainty related to appropriate design, and not capability or methodology, would rarely qualify as having substantial uncertainty for purposes of the high threshold of innovation test." In addition, the final regulations include a statement that was not included in the proposed regulations: "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." Like the proposed regulations, the final regulations interpret the significant economic risk test to require both technical and economic risk (i.e., technical uncertainty and uncertainty regarding whether the final result can be achieved within a timeframe that will allow the substantial resources dedicated to resolving the technological uncertainty to be recovered within a reasonable period). The final regulations also require, consistent with the proposed regulations, that substantial uncertainty exist at the beginning of the taxpayer's activities. In response to comments requesting definitions of the terms "substantial resources" and "reasonable time period" used in the significant economic risk test, the government stated that explanations and examples would not be helpful to demonstrate these concepts because the resolution of either question is a factual determination based on the taxpayer's facts and circumstances. The final regulations state that IUS may only satisfy the high threshold of innovation standard if 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 innovation and significant economic risk requirements. This final rule is consistent with the proposed regulations and with prior versions of regulations addressing IUS. Many of the proposed regulations' examples demonstrating the application of the IUS regulations were clarified to reflect changes to the text of the final regulations. None of the conclusions of the examples contained in the proposed regulations were reversed by the modifications made by the final regulations. One new example was added (Example 9) to demonstrate the application of the definition of software not developed primarily for internal use with respect to online ("cloud-based") software that was developed to be sold, leased, licensed, or to be otherwise marketed to the taxpayer's customers. The preamble to the final regulations discusses comments received on two examples, but the government did not modify the examples as a result of comments received. Example 1 demonstrates the inapplicability of the IUS regulations to a package of hardware and software developed together. Examples 2-10 reflect the application of the IUS definition (Example 10 relates to improvements to existing software). Examples 11-14 demonstrate the application of the dual-function software rules. Examples 15-18 demonstrate the application of the high threshold of innovation standard. The final regulations adopt the text of the examples in the proposed regulations. Commenters requested modification, removal, and clarification of several of the process of experimentation examples. As explained in the preamble to the final regulations, the intent of these additional examples is to provide guidance on the application of the process of experimentation test under Section 41(d)(1)(C) to software development. Because many of the requests for clarification related to issues outside the scope of what the examples are offered to demonstrate, none of the commenters' suggestions were adopted in the final regulations. The conclusion in many of the examples is that the taxpayer did not conduct a process of evaluating alternatives to eliminate uncertainty regarding the development of the business component. In these circumstances, the example provides that the taxpayer was evaluating a vendor's product or selecting from alternative software functions of a chosen product. One example demonstrates the shrinking-back principle, in which the majority of the taxpayer's enterprise resource planning (ERP) system implementation activities did not constitute a process of experimentation, but the creation of integration software by the taxpayer did satisfy the process of experimentation requirement. In one example, the taxpayer designs and systematically tests various algorithms, which the example's conclusion states demonstrates a process of experimentation. Although the preamble notes commenters' requests for retroactive application of the final regulations, the final regulations are effective for tax years beginning on or after October 4, 2016, the date of publication of the final regulations. The final regulations state that the IRS will not challenge return positions consistent with the proposed or final regulations for tax years beginning before October 4, 2016 and ended on or after January 20, 2015, the date of publication of the proposed regulations. The final regulations do not provide any specific guidance on the application of the consistency rules for base period qualified research expenses (QREs) used in computing the research credit. Generally, the final regulations are taxpayer-favorable and acknowledge the rapid and evolving nature of software technology and its role in business practices. As the preamble notes twice, the final regulations narrow the scope of software that is considered IUS compared to prior versions of regulations. The final regulations clarify that, if software is not IUS (i.e., software developed by the taxpayer for use in general and administrative functions), it is non-IUS. Thus, for many taxpayers, the final regulations remove the burden of satisfying the high threshold of innovation standard for their software development efforts to be considered qualified research. This aspect of the regulations by itself is extremely important, as the application of the high threshold of innovation test has been a significant area of disagreement between taxpayers and the IRS. The change in the definition of software not developed primarily for internal use means that taxpayers do not have to affirmatively prove that the software is either "developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or 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." The taxpayer must only show that the software is not developed by the taxpayer for use in general and administrative functions. The IRS, on examination, frequently took the position, under the proposed regulations, that a taxpayer's software was internal-use software unless it was "developed to be commercially sold, leased, licensed, or otherwise marketed to third parties" and 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," even if the software was not developed for general or administrative functions. Under the final regulations, the IRS will not be able to take this position. The revised definition of non-IUS eliminates questions of whether the software is intended to be used by third parties (such as the taxpayer's customers) or by the taxpayer's employees or questions relating to the nature or quantum of interaction between the taxpayer and third parties that is facilitated by the taxpayer's software. Because the characterization of software is based on both the intent of the taxpayer and the facts and circumstances at the beginning of the software development, it is important for taxpayers to document and maintain evidence of the purpose for which the development effort was undertaken. For taxpayers that do not or cannot isolate the third-party subset from dual-function software, the final regulations preserve a safe harbor that excludes dual-function software or the dual-function subset from the internal-use presumption and allows taxpayers to treat 25% of their QREs as not being related to IUS. Alternatively, taxpayers may pursue a QRE inclusion greater than 25% by arguing their facts and satisfying the high threshold of innovation test for dual-function software. The regulations, however, do not allow a taxpayer to pursue QRE inclusion for dual-function software by using both the dual-function safe harbor to obtain 25% of the QREs associated with the dual-function software and pursue the remainder of the QREs under the high threshold of innovation standard. If a taxpayer applies the safe harbor, the presumption that dual-function software is IUS does not apply (and, therefore, the high threshold of innovation standard does not apply to the software). Whether dual-function software is subject to the high threshold of innovation test depends on the taxpayer's application of the dual-function safe harbor. The dual-function safe harbor does not apply only to a portion of the software. For taxpayers that are developing IUS, the high threshold of innovation standard in the proposed regulations is largely adopted in the final regulations, other than specific aspects of the significant economic risk test (discussed below). The innovativeness requirement in the high threshold of innovation standard conforms to legislative history and reflects a relatively objective standard of a reduction in cost, improvement in speed, or other measurable improvement. However, the final regulations do not clarify how to measure how the improvement is substantial and economically significant. Examples 15-18 demonstrate the application of the high threshold of innovation and provide some insight into how the terms "substantial" and "economically significant" may apply in the circumstances described, but the terms remain ambiguous. The final regulations revise the proposed regulations' definition for "substantial uncertainty" in the significant economic risk test. The definition no longer distinguishes between types of uncertainty to meet the test's requirement. This revision to the significant economic risk test eliminates the IRS's ability to assert that a taxpayer has neither capability nor methodology uncertainty, and only has design uncertainty, in evaluating whether a taxpayer satisfied the significant economic risk test. Because of the commentary contained in the preamble to the final regulations and the new text in the final regulations (stating that the term "substantial uncertainty" requires a higher level of uncertainty and technical risk than that required for business components that are not IUS), taxpayers should clearly and robustly document the level of uncertainty related to their IUS development. Two of the examples in final regulations' Examples 15-18, demonstrating the application of the high threshold of innovation standard, reflect the failure of the taxpayer to satisfy the significant economic risk test. The final regulations do not clarify the meaning of certain ambiguous terms used in the significant economic risk test (such as "substantial," "significant," or "reasonable"), leaving the analysis open to the subjective interpretation of the reader. However, this may be helpful in allowing taxpayers flexibility in making their case that they have satisfied the standard. Many taxpayers may find that software subject to the high threshold of innovation rules for the 2014 calendar tax year, and all years prior, will be considered non-IUS in the 2015 tax year (and beyond). Where previously excluded costs of IUS (due to the inability of the taxpayer to satisfy the high threshold of innovation test) would be considered non-IUS or could satisfy the final regulations' (or, when applied by the taxpayer, the proposed regulations') high threshold of innovation test, taxpayers must adjust the base periods to satisfy base consistency requirements under Section 41(c)(6) and Treas. Reg. Section 1.41-9(c)(2).
Document ID: 2016-1704 | |||||||||
