Credit for Increasing Research Activities, 68299-68312 [2016-23174]

Download as PDF Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations Dated: September 28, 2016. Harriet Tregoning, Principal Deputy Assistant, Secretary for Community Planning and Development. [FR Doc. 2016–23986 Filed 10–3–16; 8:45 am] BILLING CODE 4210–67–P DEPARTMENT OF THE TREASURY Internal Revenue Service 26 CFR Part 1 [TD 9786] RIN 1545–BC70 Credit for Increasing Research Activities Internal Revenue Service (IRS), Treasury. ACTION: Final regulations. AGENCY: This document contains final regulations concerning the application of the credit for increasing research activities. These final regulations provide guidance on software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer (internal use software). These final regulations also include examples to illustrate the application of the process of experimentation requirement to software. These final regulations will affect taxpayers engaged in research activities involving software. DATES: Effective date: These regulations are effective on October 4, 2016. Applicability date: For date of applicability see § 1.41–4(e). FOR FURTHER INFORMATION CONTACT: Martha Garcia or Jennifer Records of the IRS Office of the Associate Chief Counsel (Passthroughs and Special Industries) at (202) 317–6853 (not a tollfree number). SUPPLEMENTARY INFORMATION: SUMMARY: asabaliauskas on DSK3SPTVN1PROD with RULES Background This document contains final regulations that amend the Income Tax Regulations (26 CFR part 1) relating to the credit for increasing research activities (research credit) under section 41 of the Internal Revenue Code (Code). Section 41(d)(4)(E) provides that, except to the extent provided by regulations, research with respect to software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer is excluded from the definition of qualified research under section 41(d). Software that is developed for use in an activity that constitutes qualified research for purposes of section 41(d) and software VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 that is developed for use in a production process with respect to which the general credit eligibility requirements under section 41 are satisfied are internal use software, but are not excluded under section 41(d)(4)(E) from the definition of qualified research and are not subject to these regulations. On January 20, 2015, the Treasury Department and the IRS published in the Federal Register (80 FR 2624, January 20, 2015) a notice of proposed rulemaking (REG–153656–03, 2015–5 IRB 566) under section 41 (the proposed regulations) relating to the research credit. Comments responding to the proposed regulations were received and a public hearing was held on April 17, 2015. After consideration of all of the comments received, these final regulations adopt the proposed regulations as revised by this Treasury decision. Summary of Comments and Explanation of Provisions I. Definition of Internal Use Software The proposed regulations provided that 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. General and administrative functions, as defined in the proposed regulations, are limited to (1) financial management functions, (2) human resource management functions, and (3) support services functions. Financial management functions are functions that involve the financial management of the taxpayer and the supporting recordkeeping. Human resource management functions are functions that manage the taxpayer’s workforce. Support services functions are functions that support the day-today operations of the taxpayer, such as data processing or facilities services. Commenters expressed concern that the list of general and administrative functions in the proposed regulations was overly broad and included functions that do not represent ‘‘backoffice’’ functions. In particular, the commenters noted that inventory management, marketing, legal services, and government compliance services can provide significant benefits to third parties and may be 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. Specifically, one commenter noted that many inventory management software applications are an integral part of a taxpayer’s supply PO 00000 Frm 00007 Fmt 4700 Sfmt 4700 68299 chain management system and can be readily seen as part of the modern ‘‘front office.’’ This commenter noted that modern inventory management software usually requires interaction with a number of third party vendors to ensure the correct flow of raw materials and a corresponding flow of finished goods. Additionally, the commenter added that inventory management is inherently customer facing because it provides the proper amount of inventory to customers at the point of sale at the right time. Another commenter added that marketing is an external-facing function by nature, and software that supports marketing is necessarily intended to interact with third parties. The Treasury Department and the IRS understand that many modern software systems perform more than back-office functions. These software systems commonly provide benefits to vendors and include functions that are customer facing. Additionally, software with functions such as marketing or inventory management may not provide solely back-office functions, but may also contain functions that enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system. Recognizing such situations, the proposed regulations provided rules under § 1.41– 4(c)(6)(iv)(C) (dual function rules) to evaluate whether software that has both back-office and front-office functions is developed primarily for internal use. 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 business regardless of the taxpayer’s industry and that the benefits that such functions may provide to third parties are collateral and secondary. In addition, the Treasury Department and the IRS believe the dual function rules in these final regulations sufficiently address these comments by allowing taxpayers to identify subsets of elements of dual function software that only enable a taxpayer to interact with third parties or allow third parties to initiate functions or review data. Accordingly, the list of general and administrative functions provided in the proposed regulations remains unchanged in the final regulations. Another commenter referred to the tax software example in the preamble to the proposed regulations which notes that tax software developed by a company engaged in providing tax services to its customers is not used by the taxpayer in general and administrative functions E:\FR\FM\04OCR1.SGM 04OCR1 68300 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations even though tax is listed under § 1.41– 4(c)(6)(iii)(B)(1) of the proposed regulations, as a general and administrative function. The commenter requested that we make this concept more explicit by revising § 1.41– 4(c)(6)(iii)(A) of the proposed regulations and providing additional examples. As discussed in the preamble to the proposed regulations, the list of general and administrative functions is intended to target the back-office functions that most taxpayers would have regardless of the taxpayer’s industry, although the characterization of a function as back office will vary depending on the facts and circumstances of the taxpayer. Because § 1.41–4(c)(6)(v) of these final regulations makes clear that the determination of whether software is developed primarily for internal use depends on the intent of the taxpayer and the facts and circumstances at the beginning of software development, the Treasury Department and the IRS believe that additional clarifying language and examples are unnecessary. asabaliauskas on DSK3SPTVN1PROD with RULES II. Definition of Software Not Developed Primarily for Internal Use The proposed regulations provided that software is not developed primarily for internal use only if it is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or if it 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. After consideration of the comments described herein, these final regulations clarify that (1) 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; and (2) software that is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties and software that 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 are examples of software that is not developed primarily for the taxpayer’s internal use. A. Software Developed To Be Commercially Sold, Leased, Licensed or Otherwise Marketed to Third Parties A commenter requested that § 1.41– 4(c)(6)(iv)(A)(1) of the proposed regulations be revised to state that software is not developed primarily for the taxpayer’s internal use if the software is developed to be VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 commercially sold, leased, licensed, hosted, or otherwise marketed to third parties. (Emphasis added.) The commenter also recommended additional language to further define ‘‘otherwise marketed’’ to include transactions where the taxpayer effectively provides the functionality of the software to a third party even if there is no transfer of a copy of the software itself to such third party. The Treasury Department and the IRS understand that a taxpayer may develop software where the full functionality of that software is provided to a third party even though there is no transfer of a copy of the software. The Treasury Department and the IRS believe the phrase ‘‘software that is developed to be commercially sold, leased, licensed or otherwise marketed to third parties’’ is sufficiently broad to encompass hosted software and other software where there is no transfer of a copy of the software. An example has been added to further illustrate this point (Example 9 of these final regulations). B. Software Developed To Enable a Taxpayer To Interact With Third Parties or Allow Third Parties To Initiate Functions or Review Data on the Taxpayer’s System Several commenters requested clarification on the terms ‘‘interact,’’ ‘‘initiate,’’ or ‘‘review,’’ and recommended additional examples illustrating the terms. One commenter noted that a common example that should be clarified is whether a third party reviewing a Web site constitutes ‘‘interaction,’’ ‘‘initiate functions,’’ or ‘‘review data.’’ In response to these comments, the final regulations clarify that software that 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 are examples of software that is not developed primarily for the taxpayer’s internal use. In addition, these final regulations provide that the determination of whether software is internal use 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 depends on the intent of the taxpayer and the facts and circumstances at the beginning of the software development. Accordingly, Example 3 of the proposed regulations, now designated as Example 4 in these final regulations, is revised to show that software developed with the intent of marketing via a Web site and not to allow third parties to review data on the taxpayer’s system is developed for internal use because it was developed PO 00000 Frm 00008 Fmt 4700 Sfmt 4700 for use in a general and administrative function. III. Connectivity Software In the proposed regulations, the Treasury Department and the IRS requested comments on the appropriate definition and treatment of connectivity software that allows multiple processes running on one or more machines to interact across a network, sometimes referred to as bridging software, integration software, or middleware. The Treasury Department and the IRS received very few responses to this request for comments. One of the commenters noted that the treatment of such software is challenging because of its multi-faceted purposes; it could fall within a category in which it is not sold, does not interact with a third party, and does not perform a general and administrative function. The other commenter recommended that the regulations provide a general rule for connectivity software that is tied to the intent of the taxpayer and the facts and circumstances at the beginning of the software development and that the regulations provide examples demonstrating the rule. In addition, with respect to this category of software, the Treasury Department and the IRS understand that with wide use and availability of enterprise resource planning (ERP) software, few companies actually engage in developing connectivity software. Connectivity software is often purchased or the need for it has diminished due to the use of ERP software. After further consideration of business practices and the limited comments received, the Treasury Department and the IRS believe that a special rule for connectivity software is not needed. The final regulations clarify that software is not developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use if the software is not developed for use in general and administrative functions. Accordingly, any software that is not developed to be used in a general and administrative function will not be considered to be developed for internal use. This is the case even if the software is not developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or is not 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. Furthermore, connectivity software should not be specifically identified or categorized differently from other types of software. Whether certain software is developed to be used primarily for E:\FR\FM\04OCR1.SGM 04OCR1 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations asabaliauskas on DSK3SPTVN1PROD with RULES internal use should be based on the function the software provides, rather than the type of software. For example, connectivity software that is developed to connect a taxpayer’s existing payroll software with financial budgeting software to allow an exchange of data between the two software modules would be considered to be developed for the taxpayer’s internal use because the connectivity software’s function is to be used in human resources and financial management functions. Accordingly, the Treasury Department and the IRS believe that the general rule in the final regulations to determine whether or not software is developed primarily for internal use already provides sufficient guidance for connectivity software. Whether software, including connectivity software, is developed for use in general and administrative functions depends upon the intent of the taxpayer and the facts and circumstances at the beginning of the software development. IV. Intent of the Taxpayer and the Facts and Circumstances at the Beginning of the Software Development The proposed regulations provided that whether software is or is not developed primarily for internal use depends upon the intent of the taxpayer and the facts and circumstances at the beginning of the software development. If a taxpayer originally develops software primarily for internal use but later makes improvements to the software with the intent to hold the improved software for commercial sale, lease, or license or to allow third parties to initiate functions or review data on the taxpayer’s system, the improvements will be considered separate from the existing software and will not be considered developed primarily for internal use. Likewise, if a taxpayer originally develops software for commercial sale, lease, or license or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system, but later makes improvements to the software with the intent to use the software in general and administrative functions, the improvements will be considered separate from the existing software and will be considered developed primarily for internal use. After consideration of the comments described below, these final regulations retain these rules without modification. A commenter explained that it is common for a taxpayer to initiate a software development project with one purpose in mind and to later discover that other purposes should be considered and pursued. Commenters VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 also explained that it is common for a taxpayer to abandon its original intentions of how the software might be used. Commenters made several different recommendations, among them that the final regulations adopt a standard that allows facts at any point during the software development to be considered. Another suggested looking to the intended use of the software, and not just the improvements, as of the tax return filing date for the taxable year or the beginning of the taxable year in which the software development expenditures were incurred. One commenter further suggested that if the regulations require a determination at the beginning of the software development, the regulations should allow that determination to be rebutted with evidence about how the software is actually used when it is placed in service. Commenters also noted that taxpayers will likely have difficulty substantiating their intended use of the software at the beginning of the development process. The Treasury Department and the IRS conclude 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. Congress intended that the credit for increasing research activities would provide an incentive for greater private activity in research. That incentive nature of section 41 is promoted by taking into account a taxpayer’s intent at the beginning of the software development; allowing any change in a taxpayer’s intent throughout the development to support treatment as qualifying research of expenses incurred prior to that change would frustrate the purpose of the credit. Furthermore, allowing 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. Finally, the final regulations continue to provide a special rule for improvements to software that can be separately identified. This special rule would apply, for example, when a taxpayer completes a software development and then decides to improve that software by undertaking further development to the same software. V. Dual Function Software and Safe Harbor A. Presumption and Third Party Subset The proposed regulations provided that software developed by (or for the PO 00000 Frm 00009 Fmt 4700 Sfmt 4700 68301 benefit of) the taxpayer 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 software) is presumed to be developed primarily for a taxpayer’s internal use. However, this presumption is inapplicable to the extent that a taxpayer can identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer’s system (third party subset). The proposed regulations provided that if the taxpayer can identify a third party subset, the portion of qualified research expenditures allocable to such third party subset of the dual function software may be eligible for the research credit, provided all the other applicable requirements are met. The Treasury Department and the IRS received several comments on dual function software rules. One commenter recommended changes to clarify that the dual function software rules do not apply to software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, even if such software was also 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 Treasury Department and the IRS believe such clarification is unnecessary as § 1.41–4(c)(6)(iv)(C)(1) of the proposed regulations clearly defines dual function software as software that is developed by the taxpayer both for use in general and administrative functions and to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data. Software that is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties is not dual function software, even if such software was also 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. One commenter suggested that the ‘‘substantially all’’ and ‘‘shrink back’’ rules found in § 1.41–4(b)(2) can be easily applied to evaluate dual function software. If substantially all of the software is non-internal use, then all of the software should be considered noninternal use under the substantially all rule. Similarly, if substantially all of the software is internal use, then the software should be considered internal use. In the case where the software as E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES 68302 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations a whole does not meet the substantially all rule, then the taxpayer would apply the shrink back rule and the software would be divided into subcomponents based on functionality until the noninternal use portion and the internal use portion were appropriately separated. That commenter noted that these two rules have worked for many years with little difficulty in other areas of the research credit rules and could be used equally well to address the issue of dual function software. Another commenter encouraged the addition of a rule to cover cases in which a taxpayer’s dual function subset’s third party use or interaction exceeds 80 percent. The commenter stated that in this circumstance, the remaining internal use is de minimis and should be disregarded and the entire development should be treated as not developed for internal use. The shrink back rule provides that the requirements of section 41(d) and § 1.41–4(a) are to be applied first at the level of the discrete business component, that is, the product, process, computer software, technique, formula, or invention to be held for sale, lease, or license, or used by the taxpayer in a trade or business of the taxpayer. If these requirements are not met at that level, then they apply at the most significant subset of elements of the product, process, computer software, technique, formula, or invention to be held for sale, lease, or license. This shrinking back of the product is to continue until either a subset of elements of the product that satisfies the requirements is reached, or the most basic element of the product is reached and such element fails to satisfy the test. The Treasury Department and the IRS believe that the proposed rules already apply principles similar to the shrink back rule to allow taxpayers to identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer’s system. The substantially all test referenced by the commenter is similar to the general credit eligibility requirement in section 41(d)(1)(C), which provides that in order for activities to constitute qualified research, substantially all of the activities must constitute elements of a process of experimentation that relates to a qualified purpose. Under § 1.41– 4(a)(6), this substantially all requirement is satisfied only if 80 percent or more of a taxpayer’s research activities, for the development or improvement of a business component, measured on a cost or other consistently applied reasonable basis, constitute VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 elements of a process of experimentation. In contrast to the general requirement of section 41(d)(1) pertaining to qualifying research, section 41(d)(4)(E) does not apply the substantially all test when it excludes activities related to internal use software from qualifying research. Accordingly, the Treasury Department and the IRS believe the use of the substantially all test in these regulations is inappropriate, and the final regulations do not adopt the commenter’s suggested approach. Another commenter requested that the dual function rules be eliminated because the provisions are confusing and unnecessary and that trying to delineate elements of dual function software raises significant administrative issues. Similarly, another commenter noted that the concepts in the dual function rules can be confusing to taxpayers and will require additional recordkeeping by taxpayers. According to this commenter, most taxpayers do not differentiate their software applications by ‘‘third party interactions’’ or generally track such interactions. One commenter similarly stated that § 1.41–4(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. Regarding the presumption that dual function software is developed for internal use, a commenter stated that such presumption is contrary to the intent of the statute. One commenter recommended that the presumption should be replaced with a primary purpose test, consistent with the statutory language that looks to whether software is developed ‘‘primarily’’ for internal use. The Treasury Department and the IRS believe it is necessary to implement rules for dual function software as this type of software development is increasingly common in business practice. Rather than simply reiterating the ‘‘primarily’’ language in the statute, these regulations specifically identify the types of software functions that are considered to be primarily for internal use. A definition that specifically identifies the types of software functions that are considered to be primarily for internal use provides a clearer objective test that will provide consistency in application. The nature of software and its development has rapidly evolved over time, and the statute did not expressly address the treatment of dual function software. In conjunction with crafting a narrow definition of internal use, the Treasury PO 00000 Frm 00010 Fmt 4700 Sfmt 4700 Department and the IRS believe that the dual function software rules in the proposed regulations strike an appropriate balance between the administrative burdens and compliance concerns relating to claiming the research credit for activities relating to software. Thus, these final regulations retain the dual function rules. These final regulations are applicable to taxable years beginning on or after the date of their publication in the Federal Register. Taxpayers have been aware of the proposed rules and have had the opportunity to begin maintaining the necessary documentation to establish their entitlement to research credits under these rules. B. Safe Harbor The proposed regulations provided taxpayers with a safe harbor to apply to dual function software if there remains a subset of elements of dual function software (dual function subset) after the third party subset has been identified. The safe harbor allows a taxpayer to include 25 percent of the qualified research expenditures of the dual function subset in computing the amount of the taxpayer’s credit, provided that the taxpayer’s research activities related to the dual function subset constitute qualified research and the use of the dual function subset 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. Some commenters requested that the safe harbor be removed from the regulations. Specifically, one commenter stated that the burdens associated with the safe harbor may be greater than its benefits and noted the multiple steps that a taxpayer must take to determine if it meets the safe harbor. Another commenter noted that the safe harbor complicates the administration of the credit for both taxpayers and the IRS. Another commenter noted that the safe harbor potentially penalizes the taxpayer with the inequitable result of allowing only 25 percent of the qualified research expenditures. According to the commenter, given that a taxpayer must document anticipated use, it should then follow that the portion of software treated as third party facing should mirror this analysis. In other words, the proportion anticipated to be third party facing should be the proportion of software that is not developed primarily for internal use. After careful consideration, the final regulations do not adopt these comments. However, the safe harbor has E:\FR\FM\04OCR1.SGM 04OCR1 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations asabaliauskas on DSK3SPTVN1PROD with RULES been modified to clarify that the safe harbor can be applied to the dual function software or the dual function subset after the application of § 1.41– 4(c)(6)(vi)(B) of the final regulations. The safe harbor is not a requirement but an option available for taxpayers who cannot identify a third party subset, or after identification of a third party subset, still have a dual function subset. Without the safe harbor, dual function software or a dual function subset would be presumed to be internal use and the taxpayer would have to demonstrate that the research with respect to the dual function software or dual function subset meets the high threshold of innovation test in addition to the general eligibility requirements under section 41(d)(1). The safe harbor provides a benefit, not a detriment, to taxpayers, provided the dual function software or dual function subset’s use by third parties is anticipated to be at least 10 percent of the total use. Taxpayers who consider it too burdensome to comply with the requirements of the safe harbor can choose not to rely upon it. C. Time of Determination Several commenters noted concerns with the time of determination for the application of the safe harbor. A commenter noted that determining the percentage of third party use based upon an estimate made at the beginning of software development imposes an undue administrative burden and may not be an accurate reflection of the actual use once the software is released. This commenter requested that the rule be eliminated or amended to provide that a taxpayer must estimate third party use once the software is deployed. Similarly, another commenter noted that it has not been their experience that taxpayers plot out the future expected use of their software at the time the development begins with such specificity, especially given that software development is an iterative development process where functionality and expected uses rapidly evolve. Lastly, another commenter requested that, similar to the provisions for improvements to existing software, there should be a mechanism to recharacterize software over time. While the Treasury Department and the IRS understand commenters’ concerns, the final regulations do not change the requirement that the time of determination occur at the beginning of the software development. As discussed herein, the Treasury Department and the IRS continue to believe that the rule requiring that a determination be made at the beginning of the software VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 development is most accurate and appropriate given Congress’ intent that the research credit serve as an incentive to conduct qualifying research rather than an unanticipated reward for doing so. D. Objective Reasonable Method In the proposed regulations, the Treasury Department and the IRS invited comments on the administrability of measuring the reasonably anticipated use of software by taxpayers to interact with third parties and by third parties to initiate functions or review data based on reasonable methods (such as processing time, amount of data transfer, number of software user interface screens, number of third party initiated functions, and other objective, reasonable methods) and whether the regulations should include specific reasonable methods and examples. A commenter recommended that due to the wide range of taxpayers that will be subject to these regulations, the final regulations should not provide overly detailed examples of ‘‘reasonable methods.’’ This commenter noted that it should be clear that any examples of reasonable methods are for illustrative purposes only and any reasonable method may be acceptable. Another commenter recommended the adoption of the phrase ‘‘within each industry’’ to ensure that the application of the objective, reasonable method takes into account unique aspects of all taxpayers within given industries. The Treasury Department and the IRS agree that it is unrealistic to impose one specific method that will be used to measure reasonably anticipated use due to the variety of industries that are subject to the final regulations. Therefore, the final regulations provide that any objective, reasonable method within the taxpayer’s industry may be used for purposes of the safe harbor. VI. Third Party Definition The proposed regulations provided that the term ‘‘third party’’ means any corporation, trade or business, or other person that is not treated as a single taxpayer with the taxpayer pursuant to section 41(f). A commenter raised concerns and requested that the Treasury Department and the IRS reconsider whether it is appropriate to apply the controlled group standard under section 41(f). The commenter contended that this third party definition would potentially deny a research credit to some software for artificial reasons. The commenter further noted that if the regulations do not modify the third party definition, PO 00000 Frm 00011 Fmt 4700 Sfmt 4700 68303 taxpayers should at least have an opportunity to demonstrate that software provided to a member of the controlled group is not internal use software based on the facts and circumstances. The Treasury Department and the IRS continue to believe that the use of the controlled group standard under section 41(f) is appropriate. A well established, objective standard is essential and using the standard in section 41(f) is consistent with the reference to section 41(f) in section 41(b)(2) relating to inhouse research expenditures and in § 1.41–6(a)(3)(ii) relating to the definition of controlled group for purposes of aggregating expenditures. The proposed regulations also provided that 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 conduct of the taxpayer’s trade or business, e.g., the taxpayer’s own vendors. A commenter contended that excluding any person that uses a taxpayer’s software to support a general and administrative function from the definition of third party creates confusion and blurs a wellconceived, objective measurement. This commenter believes the term third party suggests a person who is external to the organization or a person who is not an employee. The Treasury Department and the IRS note that the statute provides a higher standard for internal use software, in part, because the benefits of such software are intended primarily for the taxpayer developing it. 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. Accordingly, the final regulations do not adopt these comments requesting a change to the definition of third party. VII. High Threshold of Innovation— Significant Economic Risk The proposed regulations provided that certain internal use software is eligible for the research credit if the software satisfies the high threshold of innovation test, the three parts of which are (1) software is innovative in that 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; (2) software development involves significant economic risk in that the taxpayer commits substantial resources to the development and there is a substantial uncertainty, because of E:\FR\FM\04OCR1.SGM 04OCR1 68304 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations asabaliauskas on DSK3SPTVN1PROD with RULES technical risk, that such resources would be recovered within a reasonable period; and (3) 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. The proposed regulations further provided that substantial uncertainty exists if, at the beginning of the taxpayer’s activities, the information available to the taxpayer does not establish the capability or method for developing or improving the software. A. Design Uncertainty Several commenters requested that the final regulations include design uncertainty in the definition of technical risk for purposes of meeting the significant economic risk test. Commenters noted that both sections 174 and 41 have long included the concept of design uncertainty. Commenters also raised concerns that the statute and regulations do not define the concepts of capability, methodology, and design uncertainty. Commenters further explained that these three types of uncertainties are inherently related to each other, and it is often difficult for taxpayers to clearly state or describe which type of uncertainty they face. The use of the word ‘‘substantial’’ before ‘‘uncertainty’’ in the significant economic risk test for internal use software indicates a higher threshold of uncertainty than that required for business components that are not internal use software. While there may be design uncertainty in the development of internal use software, substantial uncertainty generally exists only when there is also uncertainty in regard to the capability or method of achieving the intended result. However, the Treasury Department and the IRS understand that it is difficult to delineate the types of technical uncertainties and attempting to do so may lead to unnecessary burdens on both taxpayers and the IRS. Furthermore, the appropriate design uncertainty of internal use software may be inextricably linked to substantial uncertainty regarding capability or method. The focus of the significant economic risk test should be on the level of uncertainty that exists and not the types of uncertainty. For these reasons, the final regulations remove the reference to capability and method uncertainty. However, the Treasury Department and the IRS believe that internal use software research activities that involve only uncertainty related to VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 appropriate design, and not capability or methodology, would rarely qualify as having substantial uncertainty for purposes of the high threshold of innovation test. B. Substantial Resources/Reasonable Time Period A commenter requested that the final regulations provide further explanation or examples on what constitutes ‘‘substantial resources’’ or a ‘‘reasonable time period’’ for purposes of meeting the significant economic risk test. The Treasury Department and the IRS believe that whether the amount of resources committed is substantial or whether substantial resources would be recovered within a reasonable time period are factual determinations to be resolved based on the taxpayer’s facts and circumstances and, therefore, further explanation or examples would be too specific and not helpful. Accordingly, the final regulations do not adopt these comments. C. Application of High Threshold of Innovation Test Another commenter requested deletion of the statement, ‘‘[i]t is not always necessary to have a revolutionary discovery or creation of new technologies such as a new programming language, operating system, architecture, or algorithm to satisfy the high threshold of innovation test.’’ The commenter is concerned that the sentence can be read to imply that in some situations it will be necessary to have a revolutionary discovery to qualify internal use software for the research credit. The Treasury Department and the IRS did not intend the inclusion of this statement to have the interpretation suggested or taken by the commenter. Accordingly, the Treasury Department and the IRS agree that this statement should be removed from the final regulations because a revolutionary discovery is not required to meet the high threshold of innovation test. Furthermore, the Treasury Department and the IRS are revising §§ 1.41–4(c)(6)(i) and (ii) of the proposed regulations to clarify that the internal use software rules under § 1.41– 4(c)(6) do not apply to (1) software developed for use in an activity that constitutes qualified research, (2) software developed for use in a production process to which the requirements of section 41(d)(1) are met, and (3) a new or improved package of software and hardware developed together by the taxpayer as a single product. Accordingly, under the final regulations, the high threshold of PO 00000 Frm 00012 Fmt 4700 Sfmt 4700 innovation test applies only to the software developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business and to dual function software. VIII. Examples A. Process of Experimentation Section 1.41–4(a)(8) of the proposed regulations provided six new examples illustrating the application of the process of experimentation requirement to software under section 41(d)(1)(C). One commenter noted that the examples appear to suggest a presumption that activities related to developing web design or ERP software do not meet the process of experimentation requirement. This commenter requested that the final regulations clearly state the reasons for such presumption. The proposed regulations and these final regulations do not establish a presumption against a particular type of software; rather these examples focus on the facts and circumstances surrounding activities to determine whether they involve a process of experimentation. Another commenter requested that the final regulations include additional examples demonstrating fact patterns that do not initially qualify as a process of experimentation but where a change in facts introduces technical uncertainty that requires a process of experimentation. The final regulations could provide examples describing a particular change in facts that would introduce technical uncertainty and require a process of experimentation; however, because the examples are very factual and would differ based on a taxpayer’s business, we do not think more examples would provide the clarification that the commenter is seeking. Accordingly, the final regulations do not include additional examples to address this comment. i. Example 6 Section 1.41–4(a)(8), Example 6, of the proposed regulations analyzed whether activities related to selecting a commercial software vendor with object-oriented functions and selecting and incorporating the specific functions into new software developed by X involved conducting a process of experimentation. One commenter noted that the use of certain terms in Example 6, such as ‘‘develop,’’ ‘‘evaluate,’’ and ‘‘determine’’ suggest that the process of experimentation criteria may be met and recommended changes to clearly show that a purchase, installation, and E:\FR\FM\04OCR1.SGM 04OCR1 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations selection from pre-determined categories do not meet a process of experimentation. We disagree with the commenter because the use or nonuse of certain terms is not an implication that the process of experimentation criteria has or has not been met. This example is intended to show that the process of experimentation requirement is not met regardless of the terms used. Accordingly, the final regulations do not adopt this comment. asabaliauskas on DSK3SPTVN1PROD with RULES ii. Example 7 Section 1.41–4(a)(8), Example 7, of the proposed regulations analyzed whether when developing software, activities relating to X’s decision to use a separate server to distribute the workload across each of the web servers and X’s decision that a round robin workload distribution algorithm is appropriate for its needs involved conducting a process of experimentation. Two commenters recommended removing Example 7. One commenter believed that the example did not provide any clarification. The other commenter stated that the example shows a failure to meet the technical uncertainty requirement under section 174, rather than a process of experimentation. While the Treasury Department and the IRS agree with the commenter that activities under section 174 must be for the purpose of discovering information that would eliminate uncertainties, Example 7 is intended to demonstrate the process of experimentation requirement under section 41(d). The example shows a taxpayer’s failure to meet the process of experimentation requirement under section 41(d)(1) because the use of a technique or design, such as a round robin workload distribution algorithm, does not qualify where the taxpayer did not conduct a process of evaluating alternatives intended to eliminate uncertainty regarding the development of software. Accordingly, the final regulations do not adopt these comments. iii. Example 8 Section 1.41–4(a)(8), Example 8, of the proposed regulations analyzed whether X’s activities relating to design and systematic testing and evaluation of several different algorithms in the development of load balancing software involved conducting a process of experimentation. One commenter recommended that all references to the terms ‘‘dynamic’’ and ‘‘highly volatile’’ be removed because the commenter believes the terms provide no additional value and that VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 they suggest that the nature of X’s business environment has some bearing on the performance of qualified research. The Treasury Department and the IRS disagree and the final regulations do not adopt the commenter’s recommendation because we believe the nature of a taxpayer’s business environment can be a valuable indicator of circumstances that may result in the necessary uncertainty required for a process of experimentation. Another commenter requested that for both Example 8 and Example 10, the Treasury Department and the IRS provide clarification by applying the high threshold of innovation test once the software is determined to be internal use software. Additionally, this commenter requested that the final regulations provide an additional example addressing this process. The Treasury Department and the IRS note that the examples are added to illustrate only the application of a process of experimentation to software research. They are not meant to address the high threshold of innovation test; those examples were provided under § 1.41– 4(c)(6)(vi) of the proposed regulations. Furthermore, a comprehensive example that applies the rules contained in § 1.41–4(c)(6) would require more developed facts and layers of analysis and would be better suited for a different type of published guidance than these final regulations. Accordingly, the final regulations do not adopt these comments. iv. Example 9 Section 1.41–4(a)(8), Example 9, of the proposed regulations analyzed whether X’s activities relating to the installation of an ERP system involved a process of experimentation. Two commenters requested deletion of the phrase ‘‘routine programming’’ in Example 9 because the term is subjective, immeasurable, and inconsistent with Suder v. Commissioner, T.C. Memo 2014–201. One commenter also stated that taxpayers may confront uncertainty about the appropriate design of the configuration of an ERP system, and the example does not address this technical uncertainty. The Treasury Department and the IRS did not intend to illustrate in this example the types of uncertainty that must be eliminated to satisfy the process of experimentation requirement under section 41(d)(1). Rather, this example demonstrates a taxpayer’s failure to meet the process of experimentation requirement under section 41(d)(1) because X did not conduct a process of evaluating PO 00000 Frm 00013 Fmt 4700 Sfmt 4700 68305 alternatives in order to eliminate uncertainty regarding the development of the ERP software. Accordingly, the Treasury Department and the IRS believe further clarification of these examples is unnecessary. Furthermore, the Tax Court’s decision in Suder is not inconsistent with Example 9 because in Suder the court did not address whether ‘‘routine programming’’ could meet the process of experimentation requirement. B. Internal Use Software The proposed regulations provided examples illustrating the provisions contained in § 1.41–4(c)(6) of the proposed regulations. i. Example 3 Section 1.41–4(c)(6)(vi), Example 3, of the proposed regulations analyzed whether software that is developed for a Web site that provides general information about the taxpayer’s business, and which does not enable a taxpayer to interact with third parties or allow third parties to initiate functions or review data, is internal use software. One commenter disagreed with the characterization of the facts in Example 3 which illustrates a support services function. The commenter believes that the software is dual function software that is developed to allow a third party to review data and to be used in marketing. The Treasury Department and the IRS disagree with the commenter’s characterization of Example 3. The example demonstrates that the software is intended to serve marketing purposes and thus is developed to be used in general and administrative functions. Changes were made to clarify this example which is designated as Example 4 of the final regulations. ii. Example 6 Section 1.41–4(c)(6)(vi), Example 6, of the proposed regulations analyzed the definition of third parties, specifically whether software that is developed to allow its users to upload and modify photographs at no charge allows third parties to initiate functions on the taxpayer’s system. A commenter believed the example is an important example that comes to the correct conclusion, but the commenter believed it is not a particularly good fact pattern to illustrate the third party interaction exclusion. Specifically, the commenter requested changes to the conclusion of the example to show that the advertising software is developed for use in a marketing function to an unrelated third party. The purpose of the example is to illustrate the third party definition and E:\FR\FM\04OCR1.SGM 04OCR1 68306 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations to demonstrate whether the software is developed to allow third parties to initiate functions or review data. The example is not meant to address which, if any, general and administrative function applies to the software. Accordingly, the final regulations do not adopt this comment. However, other changes were made to clarify Example 6 of the proposed regulations, which is designated as Example 8 of the final regulations. asabaliauskas on DSK3SPTVN1PROD with RULES IX. Effective/Applicability Date Some commenters requested that the final regulations apply retroactively back to 1986, while one commenter requested that the final regulations apply retroactively back to 2004 to give software development equal treatment with all other types of qualified research as defined under TD 9104 (69 FR 22). After further consideration, the effective date in the proposed regulations is generally retained with slight modifications. These final regulations are prospective and apply to taxable years beginning on or after the date of publication of this Treasury decision in the Federal Register. Retroactive application of these final regulations may provide an unfair advantage to taxpayers whose prior taxable years are not closed by the statute of limitations. Furthermore, retroactively determining whether taxpayers engaged in research activities does not further the purpose of section 41 which is to encourage taxpayers to engage in qualifying research activities within the United States and would impose a significant administrative burden on the IRS. Section 41(d)(4)(E) provides that, except to the extent provided by regulations, research with respect to computer software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer is excluded from the definition of qualified research under section 41(d). The nature of software and its development has rapidly evolved over time. Recognizing the evolving nature of software technology and its role in business practices, these final regulations more narrowly define internal use software than the rules that apply for prior periods. These final regulations are not, and should not be viewed as, an interpretation of prior regulatory guidance. Software not developed for internal use under these final regulations, such as software developed to enable a taxpayer to interact with third parties, may or may not have been internal use software under prior law. VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 The proposed regulations provided that the 2004 ANPRM (published in the Federal Register (69 FR 43)) is withdrawn effective for taxable years beginning on or after January 20, 2015, the date the proposed regulations were published in the Federal Register (80 FR 2624). For taxable years ending before January 20, 2015, taxpayers may choose to follow either all of the internal use software provisions of § 1.41–4(c)(6) in the final regulations published on January 3, 2001 in the Federal Register (TD 8930; 66 FR 280) or all of the internal use software provisions of § 1.41–4(c)(6) contained in the proposed regulations (REG–112991– 01) published on December 26, 2001 in the Federal Register (66 FR 66362). In addition, the IRS will not challenge return positions consistent with all of paragraph (c)(6) of these final regulations or all of paragraph (c)(6) of the proposed regulations for any taxable year that both ends on or after January 20, 2015, the date the proposed regulations were published in the Federal Register (80 FR 2624), and begins before October 4, 2016. X. Duty of Consistency Some commenters noted the administrative difficulties of applying the duty of consistency rule under section 41(c)(6)(A) and requested guidance on how to comply with the consistency rule. The duty of consistency is a statutory requirement and existing regulations under §§ 1.41–3(d) and 1.41–9(c) provide sufficient guidance for taxpayers to follow. In computing the research credit, qualified research expenses and gross receipts must be determined on a basis consistent with the definition of qualified research expenses and gross receipts for the credit year. These final regulations do not modify this existing law. Section 1.41–3(d) provides that in computing the credit for increasing research activities, qualified research expenses and gross receipts taken into account in computing a taxpayer’s fixed-base percentage and a taxpayer’s base amount must be determined on a basis consistent with the definition of qualified research expenses and gross receipts for the credit year, without regard to the law in effect for the taxable years taken into account in computing the fixed-base percentage or the base amount. Section 1.41–3(d) also provides examples illustrating the requirement. Current section 1.41–9(c) contains similar rules. Accordingly, the final regulations do not adopt the commenters’ suggestions concerning the duty of consistency. PO 00000 Frm 00014 Fmt 4700 Sfmt 4700 Special Analyses Certain IRS regulations, including this one, are exempt from the requirements of Executive Order 12866, as supplemented and reaffirmed by Executive Order 13563. Therefore, a regulatory impact assessment is not required. It also has been determined that section 553(b) of the Administrative Procedure Act (5 U.S.C. chapter 5) does not apply to these regulations, and because the regulations do not impose a collection of information on small entities, the Regulatory Flexibility Act (5 U.S.C. chapter 6) does not apply. Pursuant to section 7805(f) of the Code, the notice of proposed rulemaking was submitted to the Chief Counsel for Advocacy of the Small Business Administration for comment on its impact on small business, and no comments were received. Drafting Information The principal author of these regulations is Martha M. Garcia, Office of the Associate Chief Counsel (Passthroughs and Special Industries), IRS. However, other personnel from the Treasury Department and the IRS participated in their development. List of Subjects in 26 CFR Part 1 Income taxes, Reporting and recordkeeping requirements. Adoption of Amendments to the Regulations Accordingly, 26 CFR part 1 is amended as follows: PART 1—INCOME TAXES Paragraph 1. The authority citation for part 1 is amended by adding an entry in numerical order to read in part as follows: ■ Authority: 26 U.S.C. 7805 * * * * * * * * Section 1.41–4 also issued under 26 U.S.C. 41(d)(4)(E). * * * * * Par. 2. Section 1.41–0 is amended by: 1. Revising the entry in the table of contents for § 1.41–4(c)(6). ■ 2. Adding entries in the table of contents for § 1.41–4(c)(6)(i) through (viii). The revision and additions read as follows: ■ ■ § 1.41–0. * * Table of contents. * * * § 1.41–4. Qualified research for expenditures paid or incurred in taxable years ending on or after December 31, 2003. * * * (c) * * * E:\FR\FM\04OCR1.SGM 04OCR1 * * Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations (6) Internal use software. (i) General rule. (ii) Inapplicability of the high threshold of innovation test. (iii) Software developed primarily for internal use. (iv) Software not developed primarily for internal use. (v) Time and manner of determination. (vi) Software developed for both internal use and to enable interaction with third parties (dual function software). (vii) High threshold of innovation test. (viii) Illustrations. * * * * * ■ Par. 3. Section 1.41–4 is amended by: ■ 1. Adding Example 5 through Example 10 at the end of paragraph (a)(8). ■ 2. Revising paragraphs (c)(6) and (e). The additions and revisions read as follows: § 1.41–4 Qualified research for expenditures paid or incurred in taxable years ending on or after December 31, 2003. asabaliauskas on DSK3SPTVN1PROD with RULES (a) * * * (8) * * * Example 5. (i) Facts. X, a retail and distribution company, wants to upgrade its warehouse management software. X evaluates several of the alternative warehouse management software products available from vendors in the marketplace to determine which product will best serve X’s technical requirements. X selects vendor V’s software. (ii) Conclusion. X’s activities to select the software are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating alternatives in order to eliminate uncertainty regarding the development of a business component. X’s evaluation of products available from vendors is not a process of experimentation. Example 6. (i) Facts. X wants to develop a new web application to allow customers to purchase its products online. X, after reviewing commercial software offered by various vendors, purchases a commercial software package of object-oriented functions from vendor Z that X can use in its web application (for example, a shopping cart). X evaluates the various object-oriented functions included in vendor Z’s software package to determine which functions it can use. X then incorporates the selected software functions in its new web application software. (ii) Conclusion. X’s activities related to selecting the commercial software vendor with the object-oriented functions it wanted, and then selecting which functions to use, are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. In addition, incorporating the selected objectoriented functions into the new web application software being developed by X did not involve conducting a process of evaluating alternatives in order to eliminate VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 uncertainty regarding the development of software. X’s evaluation of products available from vendors and selection of software functions are not a process of experimentation. Example 7. (i) Facts. In order to be more responsive to user online requests, X wants to develop software to balance the incoming processing requests across multiple web servers that run the same set of software applications. Without evaluating or testing any alternatives, X decides that a separate server will be used to distribute the workload across each of the web servers and that a round robin workload distribution algorithm is appropriate for its needs. (ii) Conclusion. X’s activities to develop the software are activities relating to the development of a separate business component under section 41(d)(2)(A). X’s activities to develop the load distribution function are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating different load distribution alternatives in order to eliminate uncertainty regarding the development of software. X’s selection of a separate server and a round robin distribution algorithm is not a process of experimentation. Example 8. (i) Facts. X must develop load balancing software across a server cluster supporting multiple web applications. X’s web applications have high concurrency demands because of a dynamic, highly volatile environment. X is uncertain of the appropriate design of the load balancing algorithm, given that the existing evolutionary algorithms did not meet the demands of their highly volatile web environment. Therefore, X designs and systematically tests and evaluates several different algorithms that perform the load distribution functions. (ii) Conclusion. X’s activities to develop software are activities to develop a separate business component under section 41(d)(2)(A). X’s activities involving the design, evaluation, and systematic testing of several new load balancing algorithms meet the requirements as set forth in paragraph (a)(5) of this section. X’s activities constitute elements of a process of experimentation because X identified uncertainties related to the development of a business component, identified alternatives intended to eliminate those uncertainties, and evaluated one or more alternatives to achieve a result where the appropriate design was uncertain at the beginning of X’s research activities. Example 9. (i) Facts. X, a multinational manufacturer, wants to install an enterprise resource planning (ERP) system that runs off a single database so that X can track orders more easily, and coordinate manufacturing, inventory, and shipping among many different locations at the same time. In order to successfully install and implement ERP software, X evaluates its business needs and the technical requirements of the software, such as processing power, memory, storage, and network resources. X devotes the majority of its resources in implementing the ERP system to evaluating the available templates, reports, and other standard programs and choosing among these PO 00000 Frm 00015 Fmt 4700 Sfmt 4700 68307 alternatives in configuring the system to match its business process and reengineering its business process to match the available alternatives in the ERP system. X also performs some data transfer from its old system, involving routine programming and one-to-one mapping of data to be exchanged between each system. (ii) Conclusion. X’s activities related to the ERP software including the data transfer are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating alternatives in order to eliminate uncertainty regarding the development of software. X’s activities in choosing between available templates, reports, and other standard programs and conducting data transfer are not elements of a process of experimentation. Example 10. (i) Facts. Same facts as Example 9 except that X determines that it must interface part of its legacy software with the new ERP software because the ERP software does not provide a particular function that X requires for its business. As a result, X must develop an interface between its legacy software and the ERP software, and X evaluates several data exchange software applications and chooses one of the available alternatives. X is uncertain as to how to keep the data synchronized between the legacy and ERP systems. Thus, X engages in systematic trial and error testing of several newly designed data caching algorithms to eliminate synchronization problems. (ii) Conclusion. Substantially all of X’s activities with respect to this ERP project do not satisfy the requirements for a process of experimentation. However, when the shrinking-back rule is applied, a subset of X’s activities do satisfy the requirements for a process of experimentation. X’s activities to develop the data caching software and keeping the data on the legacy and ERP systems synchronized meet the requirements of qualified research as set forth in paragraph (a)(2) of this section. Substantially all of X’s activities to develop the specialized data caching and synchronization software constitute elements of a process of experimentation because X identified uncertainties related to the development of a business component, identified alternatives intended to eliminate those uncertainties, and evaluated alternatives to achieve a result where the appropriate design of that result was uncertain as of the beginning of the taxpayer’s research activities. * * * * * (c) * * * (6) Internal use software—(i) General rule. Research with respect to software that is developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use is eligible for the research credit only if— (A) The research with respect to the software satisfies the requirements of section 41(d)(1); (B) The research with respect to the software is not otherwise excluded under section 41(d)(4) (other than section 41(d)(4)(E)); and E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES 68308 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations (C) The software satisfies the high threshold of innovation test of paragraph (c)(6)(vii) of this section. (ii) Inapplicability of the high threshold of innovation test. This paragraph (c)(6) does not apply to the following: (A) 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); (B) 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 requirements of section 41(d)(1) are met; and (C) 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. (iii) Software developed primarily for internal use—(A) In general. Except as otherwise provided in paragraph (c)(6)(vi) of this section, software is developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use if the software is developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. Software that the taxpayer develops primarily for a related party’s internal use will be considered internal use software. A related party is any corporation, trade or business, or other person that is treated as a single taxpayer with the taxpayer pursuant to section 41(f). (B) General and administrative functions. General and administrative functions are: (1) Financial management. Financial management functions are functions that involve the financial management of the taxpayer and the supporting recordkeeping. Financial management functions include, but are not limited to, functions such as accounts payable, accounts receivable, inventory management, budgeting, cash management, cost accounting, disbursements, economic analysis and forecasting, financial reporting, finance, fixed asset accounting, general ledger bookkeeping, internal audit, management accounting, risk VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 management, strategic business planning, and tax. (2) Human resources management. Human resources management functions are functions that manage the taxpayer’s workforce. Human resources management functions include, but are not limited to, functions such as recruiting, hiring, training, assigning personnel, and maintaining personnel records, payroll, and benefits. (3) Support services. Support services are other functions that support the dayto-day operations of the taxpayer. Support services include, but are not limited to, functions such as data processing, facility services (for example, grounds keeping, housekeeping, janitorial, and logistics), graphic services, marketing, legal services, government compliance services, printing and publication services, and security services (for example, video surveillance and physical asset protection from fire and theft). (iv) Software not developed primarily for internal use. 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, such as— (A) Software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties; or (B) 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. (v) Time and manner of determination. For purposes of paragraphs (c)(6)(iii) and (iv) of this section, whether software is developed primarily for internal use or not developed primarily for internal use depends on the intent of the taxpayer and the facts and circumstances at the beginning of the software development. For example, software will not be considered internal use software solely because it is used internally for purposes of testing prior to commercial sale, lease, or license. If a taxpayer originally develops software primarily for internal use, but later makes improvements to the software with the intent to hold the improved software to be sold, leased, licensed, or otherwise marketed to third parties, or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system using the improved software, the improvements will be considered separate from the existing software and will not be considered developed primarily for PO 00000 Frm 00016 Fmt 4700 Sfmt 4700 internal use. Alternatively, if a taxpayer originally develops software to be sold, leased, licensed, or otherwise marketed to third parties, or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system, but later makes improvements to the software with the intent to use the software in general and administrative functions, the improvements will be considered separate from the existing software and will be considered developed primarily for internal use. (vi) Software developed for both internal use and to enable interaction with third parties (dual function software)—(A) Presumption of development primarily for internal use. Unless paragraph (c)(6)(vi)(B) or (C) of this section applies, software developed by (or for the benefit of) the taxpayer 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 on the taxpayer’s system (dual function software) is presumed to be developed primarily for a taxpayer’s internal use. (B) Identification of a subset of elements of software that only enables interaction with third parties. To the extent that a taxpayer can identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data (third party subset), the presumption under paragraph (c)(6)(vi)(A) of this section does not apply to such third party subset, and such third party subset is not developed primarily for internal use as described under paragraph (c)(6)(iv)(B) of this section. (C) Safe harbor for expenditures related to software developed for both internal use and to enable interaction with third parties. If, after the application of paragraph (c)(6)(vi)(B) of this section, there remains dual function software or a subset of elements of dual function software (dual function subset), a taxpayer may include 25 percent of the qualified research expenditures of such dual function software or dual function subset in computing the amount of the taxpayer’s credit. This paragraph (c)(6)(vi)(C) applies only if the taxpayer’s research activities related to the development or improvement of the dual function software or dual function subset constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the dual function software or dual function E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations 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 software or the dual function subset’s use. 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. An objective, reasonable method may include, but is not limited to, processing time, amount of data transfer, and number of software user interface screens. (D) Time and manner of determination. A taxpayer must apply this paragraph (c)(6)(vi) based on the intent of the taxpayer and the facts and circumstances at the beginning of the software development. (E) Third party. For purposes of paragraphs (c)(6)(iv), (v), and (vi) of this section, the term third party means any corporation, trade or business, or other person that is not treated as a single taxpayer with the taxpayer pursuant to section 41(f). Additionally, for purposes of paragraph (c)(6)(iv)(B) of this section, third parties do not include any persons that use the software to support the general and administrative functions of the taxpayer. (vii) High threshold of innovation test—(A) In general. Software satisfies this paragraph (c)(6)(vii) only if the taxpayer can establish that— (1) The software is innovative; (2) The software development involves significant economic risk; and (3) 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 requirements of paragraphs (c)(6)(vii)(A)(1) and (2) of this section. (B) 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. (C) 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 VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 higher level of uncertainty and technical risk than that required for business components that are not internal use software. 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, as defined in paragraph (a)(4) of this section, and substantial uncertainty must exist at the beginning of the taxpayer’s activities. (D) Application of high threshold of innovation test. The high threshold of innovation test of paragraph (c)(6)(vii) of this section takes into account only the results anticipated to be attributable to the development of new or improved software at the beginning of the software development independent of the effect of any modifications to related hardware or other software. The implementation of existing technology by itself is not evidence of innovation, but the use of existing technology in new ways could be evidence of a high threshold of innovation if it resolves substantial uncertainty as defined in paragraph (c)(6)(vii)(C) of this section. (viii) Illustrations. The following examples illustrate provisions contained in this paragraph (c)(6). No inference should be drawn from these examples concerning the application of section 41(d)(1) and paragraph (a) of this section to these facts. Example 1. Computer hardware and software developed as a single product—(i) Facts. X is a telecommunications company that developed high technology telephone switching hardware. In addition, X developed software that interfaces directly with the hardware to initiate and terminate a call, along with other functions. X designed and developed the hardware and software together. (ii) Conclusion. The telecommunications software that interfaces directly with the hardware is part of a package of software and hardware developed together by the taxpayer that is used by the taxpayer in providing services in its trade or business. Accordingly, this paragraph (c)(6) does not apply to the software that interfaces directly with the hardware as described in paragraph (c)(6)(ii)(C) of this section, and eligibility for the research credit is determined by examining the combined software-hardware product as a single product. Example 2. Internal use software; financial management—(i) Facts. X, a manufacturer, self-insures its liabilities for employee health benefits. X develops its own software to administer its self-insurance reserves related to employee health benefits. At the beginning of the development, X does not intend to PO 00000 Frm 00017 Fmt 4700 Sfmt 4700 68309 develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The software is developed for use in a general and administrative function because reserve valuation is a financial management function under paragraph (c)(6)(iii)(B)(1) of this section. Accordingly, the software is internal use software because it is developed for use in a general and administrative function. Example 3. Internal use software; human resources management—(i) Facts. X, a manufacturer, develops a software module that interacts with X’s existing payroll software to allow X’s employees to print pay stubs and make certain changes related to payroll deductions over the internet. At the beginning of the development, X does not intend to develop the software module for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The employee access software module is developed for use in a general and administrative function because employee access software is a human resources management function under paragraph (c)(6)(iii)(B)(2) of this section. Accordingly, the software module is internal use software because it is developed for use in a general and administrative function. Example 4. Internal use software; support services—(i) Facts. X, a restaurant, develops software for a Web site that provides information, such as items served, price, location, phone number, and hours of operation for purposes of advertising. At the beginning of the development, X does not intend to develop the Web site software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. X intends to use the software for marketing by allowing third parties to review general information on X’s Web site. (ii) Conclusion. The software is developed for use in a general and administrative function because the software was developed to be used by X for marketing which is a support services function under paragraph (c)(6)(iii)(B)(3) of this section. Accordingly, the software is internal use software because it is developed for use in a general and administrative function. Example 5. Internal use software—(i) Facts. X, a multinational manufacturer with different business and financial systems in each of its divisions, undertakes a software development project aimed at integrating the majority of the functional areas of its major software systems (Existing Software) into a single enterprise resource management system supporting centralized financial systems, human resources, inventory, and sales. X purchases software (New Software) upon which to base its enterprise-wide system. X has to develop software (Developed Software) that transfers data from E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES 68310 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations X’s legacy financial, human resources, inventory, and sales systems to the New Software. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The financial systems, human resource systems, inventory and sales systems are general and administrative functions under paragraph (c)(6)(iii)(B) of this section. Accordingly, the Developed Software is internal use software because it is developed for use in general and administrative functions. Example 6. Internal use software; definition of third party—(i) Facts. X develops software to interact electronically with its vendors to improve X’s inventory management. X develops the software to enable X to interact with vendors and to allow vendors to initiate functions or review data on the taxpayer’s system. X defines the electronic messages that will be exchanged between X and the vendors. X’s software allows a vendor to request X’s current inventory of the vendor’s product, and allows a vendor to send a message to X which informs X that the vendor has just made a new shipment of the vendor’s product to replenish X’s inventory. At the beginning of development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties. (ii) Conclusion. Under paragraph (c)(6)(vi)(E) of this section, X’s vendors are not third parties for purposes of paragraph (c)(6)(iv) of this section. While X’s software was developed to allow vendors to initiate functions or review data on the taxpayer’s system, the software is not excluded from internal use software as set forth in paragraph (c)(6)(iv)(B) of this section because the software was developed to allow vendors to use the software to support X’s inventory management, which is a general and administrative function of X. Example 7. Not internal use software; third party interaction—(i) Facts. X, a manufacturer of various products, develops software for a Web site with the intent to allow third parties to access data on X’s database, to order X’s products and track the status of their orders online. At the beginning of the development, X does not intend to develop the Web site software for commercial sale, lease, license, or to be otherwise marketed to third parties. (ii) Conclusion. The software is not developed primarily for internal use because it is not developed for use in a general and administrative function. X developed the software to allow third parties to initiate functions or review data on the taxpayer’s system as provided under paragraph (c)(6)(iv)(B) of this section. Example 8. Not internal use software; third party interaction—(i) Facts. X developed software that allows its users to upload and modify photographs at no charge. X earns revenue by selling advertisements that are displayed while users enjoy the software that X offers for free. X also developed software VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 that has interfaces through which advertisers can bid for the best position in placing their ads, set prices for the ads, or develop advertisement campaign budgets. At the beginning of the development, X intended to develop the software to enable X to interact with third parties or to allow third parties to initiate functions on X’s system. (ii) Conclusion. The software for uploading and modifying photographs is not developed primarily for internal use because it is not developed for use in X’s general and administrative functions under paragraph (c)(6)(iii)(A) of this section. The users and the advertisers are third parties for purposes of paragraph (c)(6)(iv) of this section. Furthermore, both the software for uploading and modifying photographs and the advertising software are not internal use software under paragraph (c)(6)(iv)(B) of this section because at the beginning of the development X developed the software with the intention of enabling X to interact with third parties or to allow third parties to initiate functions on X’s system. Example 9. Not internal use software; commercially sold, leased, licensed, or otherwise marketed—(i) Facts. X is a provider of cloud-based software. X develops enterprise application software (including customer relationship management, sales automation, and accounting software) to be accessed online and used by X’s customers. At the beginning of development, X intended to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties. (ii) Conclusion. The software is not developed primarily for internal use because it is not developed for use in a general and administrative function. X developed the software to be commercially sold, leased, licensed, or otherwise marketed to third parties under paragraph (c)(6)(iv)(A) of this section. Example 10. Improvements to existing internal use software—(i) Facts. X has branches throughout the country and develops its own facilities services software to coordinate moves and to track maintenance requests for all locations. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. Several years after completing the development and using the software, X consults its business development department, which assesses the market for the software. X determines that the software could be sold at a profit if certain technical and functional enhancements are made. X develops the improvements to the software, and sells the improved software to third parties. (ii) Conclusion. Support services, which include facility services, are general and administrative functions under paragraph (c)(6)(iii)(B) of this section. Accordingly, the original software is developed for use in general and administrative functions and is, therefore, developed primarily for internal use. However, the improvements to the software are not developed primarily for PO 00000 Frm 00018 Fmt 4700 Sfmt 4700 internal use because the improved software was not developed for use in a general and administrative function. X developed the improved software to be commercially sold, leased, licensed, or otherwise marketed to third parties under paragraphs (c)(6)(iv)(A) and (c)(6)(v) of this section. Example 11. Dual function software; identification of a third party subset—(i) Facts. X develops software for use in general and administrative functions that facilitate or support the conduct of X’s trade or business and to allow third parties to initiate functions. X is able to identify a third party subset. X incurs $50,000 of research expenditures for the software, 50% of which is allocable to the third party subset. (ii) Conclusion. The software developed by X is dual function software. Because X is able to identify a third party subset, the third party subset is not presumed to be internal use software under paragraph (c)(6)(vi)(A) of this section. If X’s research activities related to the third party subset constitute qualified research under section 41(d), and the allocable expenditures are qualified research expenditures under section 41(b), $25,000 of the software research expenditures allocable to the third party subset may be included in computing the amount of X’s credit, pursuant to paragraph (c)(6)(vi)(B) of this section. If, after the application of paragraph (c)(6)(vi)(B) of this section, there remains a dual function subset, X may determine whether paragraph (c)(6)(vi)(C) of this section applies. Example 12. Dual function software; application of the safe harbor—(i) Facts. The facts are the same as in Example 11, except that X is unable to identify a third party subset. X uses an objective, reasonable method at the beginning of the software development to determine that the dual function software’s use by third parties to initiate functions is reasonably anticipated to constitute 15% of the dual function software’s use. (ii) Conclusion. The software developed by X is dual function software. The software is presumed to be developed primarily for internal use under paragraph (c)(6)(vi)(A) of this section. Although X is unable to identify a third party subset, X reasonably anticipates that the dual function software’s use by third parties will be at least 10% of the dual function software’s use. If X’s research activities related to the development or improvement of the dual function software constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under section 41(b), X may include $12,500 (25% of $50,000) of the software research expenditures of the dual function software in computing the amount of X’s credit pursuant to paragraph (c)(6)(vi)(C) of this section. Example 13. Dual function software; safe harbor inapplicable—(i) Facts. The facts are the same as in Example 11, except X is unable to identify a third party subset. X uses an objective, reasonable method at the beginning of the software development to determine that the dual function software’s use by third parties to initiate functions is reasonably anticipated to constitute 5% of the dual function software’s use. E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations (ii) Conclusion. The software developed by X is dual function software. The software is presumed to be developed primarily for X’s internal use under paragraph (c)(6)(vi)(A) of this section. X is unable to identify a third party subset, and X reasonably anticipates that the dual function software’s use by third parties will be less than 10% of the dual function software’s use. X may only include the software research expenditures of the dual function software in computing the amount of X’s credit if the software satisfies the high threshold of innovation test of paragraph (c)(6)(vii) of this section and X’s research activities related to the development or improvement of the dual function software constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under section 41(b). Example 14. Dual function software; identification of a third party subset and the safe harbor—(i) Facts. X develops software for use in general and administrative functions that facilitate or support the conduct of X’s trade or business and to allow third parties to initiate functions and review data. X is able to identify a third party subset (Subset A). The remaining dual function subset of the software (Subset B) allows third parties to review data and provides X with data used in its general and administrative functions. X is unable to identify a third party subset of Subset B. X incurs $50,000 of research expenditures for the software, 50% of which is allocable to Subset A and 50% of which is allocable to Subset B. X determines, at the beginning of the software development, that the processing time of the third party use of Subset B is reasonably anticipated to account for 15% of the total processing time of Subset B. (ii) Conclusion. The software developed by X is dual function software. Because X is able to identify a third party subset, such third party subset (Subset A) is not presumed to be internal use software under paragraph (c)(6)(vi)(A) of this section. If X’s research activities related to the development or improvement of Subset A constitute qualified research under section 41(d), and the allocable expenditures are qualified research expenditures under section 41(b), the $25,000 of the software research expenditures allocable to Subset A may be included in computing the amount of X’s credit pursuant to paragraph (c)(6)(vi)(B) of this section. Although X is unable to identify a third party subset of Subset B, 15% of Subset B’s use is reasonably anticipated to be attributable to the use of Subset B by third parties. If X’s research activities related to the development or improvement of Subset B constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under 41(b), X may include $6,250 (25% x $25,000) of the software research expenditures of Subset B in computing the amount of X’s credit, pursuant to paragraph (c)(6)(vi)(C) of this section. Example 15. Internal use software; application of the high threshold of innovation test—(i) Facts. X maintained separate software applications for tracking a variety of human resource (HR) functions, VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 including employee reviews, salary information, location within the hierarchy and physical location of employees, 401(k) plans, and insurance coverage information. X determined that improved HR efficiency could be achieved by redesigning its disparate software applications into one employee-centric system, and worked to develop that system. X also determined that commercially available database management systems did not meet all of the requirements of the proposed system. Rather than waiting several years for vendor offerings to mature and become viable for its purpose, X embarked upon the project utilizing older technology that was severely challenged with respect to data modeling capabilities. The improvements, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. For example, having one employee-centric system would remove the duplicative time and cost of manually entering basic employee information separately in each application because the information would only have to be entered once to be available across all applications. The limitations of the technology X was attempting to utilize required that X attempt to develop a new database architecture. X committed substantial resources to the project, but could not predict, because of technical risk, whether it could develop the database software in the timeframe necessary so that X could recover its resources in a reasonable period. Specifically, X was uncertain regarding the capability of developing, within a reasonable period, a new database architecture using the old technology that would resolve its technological issues regarding the data modeling capabilities and the integration of the disparate systems into one system. At the beginning of the development, X did not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. However, the software satisfies the high threshold of innovation test set forth in paragraph (c)(6)(vii) of this section. The software was intended to be innovative in that it would provide a reduction in cost or improvement in speed that is substantial and economically significant. In addition, X’s development activities involved significant economic risk in that X committed substantial resources to the development and there was substantial uncertainty, because of technical risk, that the resources would be recovered within a reasonable period. Finally, at the time X undertook the development of the system, software meeting X’s requirements was not commercially available for use by X. Example 16. Internal use software; application of the high threshold of innovation test—(i) Facts. X undertook a software project to rewrite a legacy mainframe application using an objectoriented programming language, and to move PO 00000 Frm 00019 Fmt 4700 Sfmt 4700 68311 the new application off the mainframe to a client/server environment. Both the objectoriented language and client/server technologies were new to X. This project was undertaken to develop a more maintainable application, which X expected would significantly reduce the cost of maintenance, and implement new features more quickly, which X expected would provide both significant improvements in speed and reduction in cost. Thus, the improvements, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. X also determined that commercially available systems did not meet the requirements of the proposed system. X was certain that it would be able to overcome any technological uncertainties and implement the improvements within a reasonable period. However, X was unsure of the appropriate methodology to achieve the improvements. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. X’s activities do not satisfy the high threshold of innovation test of paragraph (c)(6)(vii) of this section. Although the software meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of this section, X’s development activities did not involve significant economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X did not have substantial uncertainty, because of technical risk, that the resources committed to the project would be recovered within a reasonable period. Example 17. Internal use software; application of the high threshold of innovation test—(i) Facts. X wants to expand its internal computing power, and is aware that its PCs and workstations are idle at night, on the weekends, and for a significant part of any business day. Because the general and administrative computations that X needs to make could be done on workstations as well as PCs, X develops a screen-saver-like application that runs on employee computers. When employees’ computers have been idle for an amount of time set by each employee, X’s application goes back to a central server to get a new job to execute. This job will execute on the idle employee’s computer until it has either finished, or the employee resumes working on his computer. The ability to use the idle employee’s computers would save X significant costs because X would not have to buy new hardware to expand the computing power. The improvements, if successful, would provide a reduction in cost that is substantial and economically significant. At the time X undertook the software development project, there was no commercial application available with such a capability. In addition, at the time X undertook the software development project, X was uncertain regarding the capability of developing a server application that could schedule and E:\FR\FM\04OCR1.SGM 04OCR1 asabaliauskas on DSK3SPTVN1PROD with RULES 68312 Federal Register / Vol. 81, No. 192 / Tuesday, October 4, 2016 / Rules and Regulations distribute the jobs across thousands of PCs and workstations, as well as handle all the error conditions that occur on a user’s machine. X commits substantial resources to the project. X undertakes a process of experimentation to attempt to eliminate its uncertainty. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. However, the software satisfies the high threshold of innovation test as set forth in paragraph (c)(6)(vii) of this section. The software was intended to be innovative because it would provide a reduction in cost or improvement in speed that is substantial and economically significant. In addition, X’s development activities involved significant economic risk in that X committed substantial resources to the development and there was substantial uncertainty that because of technical risk, such resources would be recovered within a reasonable period. Finally, at the time X undertook the development of the system, software meeting X’s requirements was not commercially available for use by X. Example 18. Internal use software; application of the high threshold of innovation test—(i) Facts. X, a multinational manufacturer, wants to install an enterprise resource planning (ERP) system that runs off a single database. However, to implement the ERP system, X determines that it must integrate part of its old system with the new because the ERP system does not have a particular function that X requires for its business. The two systems are general and administrative software systems. The systems have mutual incompatibilities. The integration, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. At the time X undertook this project, there was no commercial application available with such a capability. X is uncertain regarding the appropriate design of the interface software. However, X knows that given a reasonable period of time to experiment with various designs, X would be able to determine the appropriate design necessary to meet X’s technical requirements and would recover the substantial resources that X commits to the development of the system within a reasonable period. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X’s system. (ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. X’s activities do not satisfy the high threshold of innovation test of paragraph (c)(6)(vii) of this section. Although the software meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of this section, X’s development VerDate Sep<11>2014 17:56 Oct 03, 2016 Jkt 241001 activities did not involve significant economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X did not have substantial uncertainty, because of technical risk, that the resources committed to the project would be recovered within a reasonable period. * * * * * (e) Effective/applicability dates. Other than paragraph (c)(6) of this section, this section is applicable for taxable years ending on or after December 31, 2003. Paragraph (c)(6) of this section is applicable for taxable years beginning on or after October 4, 2016. For any taxable year that both ends on or after January 20, 2015 and begins before October 4, 2016, the IRS will not challenge return positions consistent with all of paragraph (c)(6) of this section or all of paragraph (c)(6) of this section as contained in the Internal Revenue Bulletin (IRB) 2015–5 (see www.irs.gov/pub/irs-irbs/irb15-05.pdf). For taxable years ending before January 20, 2015, taxpayers may choose to follow either all of § 1.41–4(c)(6) as contained in 26 CFR part 1 (revised as of April 1, 2003) and IRB 2001–5 (see www.irs.gov/pub/irs-irbs/irb01-05.pdf) or all of § 1.41–4(c)(6) as contained in IRB 2002–4 (see www.irs.gov/pub/irsirbs/irb02-04.pdf). John Dalrymple, Deputy Commissioner for Services and Enforcement. Approved: August 22, 2016. Mark J. Mazur Assistant Secretary of the Treasury (Tax Policy). [FR Doc. 2016–23174 Filed 10–3–16; 8:45 am] BILLING CODE 4830–01–P DEPARTMENT OF DEFENSE Office of the Secretary 32 CFR Part 236 [DOD–2014–OS–0097/RIN 0790–AJ29] Department of Defense (DoD)’s Defense Industrial Base (DIB) Cybersecurity (CS) Activities Office of the DoD Chief Information Officer, DoD. ACTION: Final rule. AGENCY: This final rule responds to public comments and updates DoD’s Defense Industrial Base (DIB) Cybersecurity (CS) Activities. This rule implements mandatory cyber incident reporting requirements for DoD contractors and subcontractors who have agreements with DoD. In addition, the rule modifies eligibility criteria to SUMMARY: PO 00000 Frm 00020 Fmt 4700 Sfmt 4700 permit greater participation in the voluntary DIB CS information sharing program. DATES: Effective Date: This rule is effective on November 3, 2016. FOR FURTHER INFORMATION CONTACT: Vicki Michetti, DoD’s DIB Cybersecurity Program Office: (703) 604–3167, toll free (855) 363–4227, or OSD.DIBCSIA@ mail.mil. SUPPLEMENTARY INFORMATION: Purpose: This final rule responds to public comments to the interim final rule published on October 2, 2015. This rule implements statutory requirements for DoD contractors and subcontractors to report cyber incidents that result in an actual or potentially adverse effect on a covered contractor information system or covered defense information residing therein, or on a contractor’s ability to provide operationally critical support. The mandatory reporting applies to all forms of agreements between DoD and DIB companies (contracts, grants, cooperative agreements, other transaction agreements, technology investment agreements, and any other type of legal instrument or agreement). The revisions provided are part of DoD’s efforts to establish a single reporting mechanism for such cyber incidents on unclassified DoD contractor networks or information systems. Reporting under this rule does not abrogate the contractor’s responsibility for any other applicable cyber incident reporting requirement. Cyber incident reporting involving classified information on classified contractor systems will be in accordance with the National Industrial Security Program Operating Manual (DoD–M 5220.22 (http://dtic.mil/whs/ directives/corres/pdf/522022M.pdf)). The rule also addresses the voluntary DIB CS information sharing program that is outside the scope of the mandatory reporting requirements. By modifying the eligibility criteria for the DIB CS program, the rule enables greater participation in the voluntary program. Expanding participation in the DIB CS program is part of DoD’s comprehensive approach to counter cyber threats through information sharing between the Government and DIB participants. Benefits: The DIB CS program allows eligible DIB participants to receive Government furnished information and cyber threat information from other DIB participants, thereby providing greater insights into adversarial activity targeting the DIB. The program builds trust between DoD and DIB and provides a collaborative environment for participating companies and DoD to share actionable unclassified cyber threat information that may be used to E:\FR\FM\04OCR1.SGM 04OCR1

Agencies

[Federal Register Volume 81, Number 192 (Tuesday, October 4, 2016)]
[Rules and Regulations]
[Pages 68299-68312]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-23174]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF THE TREASURY

Internal Revenue Service

26 CFR Part 1

[TD 9786]
RIN 1545-BC70


Credit for Increasing Research Activities

AGENCY: Internal Revenue Service (IRS), Treasury.

ACTION: Final regulations.

-----------------------------------------------------------------------

SUMMARY: This document contains final regulations concerning the 
application of the credit for increasing research activities. These 
final regulations provide guidance on software that is developed by (or 
for the benefit of) the taxpayer primarily for internal use by the 
taxpayer (internal use software). These final regulations also include 
examples to illustrate the application of the process of 
experimentation requirement to software. These final regulations will 
affect taxpayers engaged in research activities involving software.

DATES: Effective date: These regulations are effective on October 4, 
2016.
    Applicability date: For date of applicability see Sec.  1.41-4(e).

FOR FURTHER INFORMATION CONTACT: Martha Garcia or Jennifer Records of 
the IRS Office of the Associate Chief Counsel (Passthroughs and Special 
Industries) at (202) 317-6853 (not a toll-free number).

SUPPLEMENTARY INFORMATION: 

Background

    This document contains final regulations that amend the Income Tax 
Regulations (26 CFR part 1) relating to the credit for increasing 
research activities (research credit) under section 41 of the Internal 
Revenue Code (Code). Section 41(d)(4)(E) provides that, except to the 
extent provided by regulations, research with respect to software that 
is developed by (or for the benefit of) the taxpayer primarily for 
internal use by the taxpayer is excluded from the definition of 
qualified research under section 41(d). Software that is developed for 
use in an activity that constitutes qualified research for purposes of 
section 41(d) and software that is developed for use in a production 
process with respect to which the general credit eligibility 
requirements under section 41 are satisfied are internal use software, 
but are not excluded under section 41(d)(4)(E) from the definition of 
qualified research and are not subject to these regulations.
    On January 20, 2015, the Treasury Department and the IRS published 
in the Federal Register (80 FR 2624, January 20, 2015) a notice of 
proposed rulemaking (REG-153656-03, 2015-5 IRB 566) under section 41 
(the proposed regulations) relating to the research credit. Comments 
responding to the proposed regulations were received and a public 
hearing was held on April 17, 2015. After consideration of all of the 
comments received, these final regulations adopt the proposed 
regulations as revised by this Treasury decision.

Summary of Comments and Explanation of Provisions

I. Definition of Internal Use Software

    The proposed regulations provided that 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. General and administrative functions, as 
defined in the proposed regulations, are limited to (1) financial 
management functions, (2) human resource management functions, and (3) 
support services functions. Financial management functions are 
functions that involve the financial management of the taxpayer and the 
supporting recordkeeping. Human resource management functions are 
functions that manage the taxpayer's workforce. Support services 
functions are functions that support the day-to-day operations of the 
taxpayer, such as data processing or facilities services.
    Commenters expressed concern that the list of general and 
administrative functions in the proposed regulations was overly broad 
and included functions that do not represent ``back-office'' functions. 
In particular, the commenters noted that inventory management, 
marketing, legal services, and government compliance services can 
provide significant benefits to third parties and may be 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. 
Specifically, one commenter noted that many inventory management 
software applications are an integral part of a taxpayer's supply chain 
management system and can be readily seen as part of the modern ``front 
office.'' This commenter noted that modern inventory management 
software usually requires interaction with a number of third party 
vendors to ensure the correct flow of raw materials and a corresponding 
flow of finished goods. Additionally, the commenter added that 
inventory management is inherently customer facing because it provides 
the proper amount of inventory to customers at the point of sale at the 
right time. Another commenter added that marketing is an external-
facing function by nature, and software that supports marketing is 
necessarily intended to interact with third parties.
    The Treasury Department and the IRS understand that many modern 
software systems perform more than back-office functions. These 
software systems commonly provide benefits to vendors and include 
functions that are customer facing. Additionally, software with 
functions such as marketing or inventory management may not provide 
solely back-office functions, but may also contain functions that 
enable a taxpayer to interact with third parties or to allow third 
parties to initiate functions or review data on the taxpayer's system. 
Recognizing such situations, the proposed regulations provided rules 
under Sec.  1.41-4(c)(6)(iv)(C) (dual function rules) to evaluate 
whether software that has both back-office and front-office functions 
is developed primarily for internal use. 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 business regardless of the taxpayer's industry and that the 
benefits that such functions may provide to third parties are 
collateral and secondary. In addition, the Treasury Department and the 
IRS believe the dual function rules in these final regulations 
sufficiently address these comments by allowing taxpayers to identify 
subsets of elements of dual function software that only enable a 
taxpayer to interact with third parties or allow third parties to 
initiate functions or review data. Accordingly, the list of general and 
administrative functions provided in the proposed regulations remains 
unchanged in the final regulations.
    Another commenter referred to the tax software example in the 
preamble to the proposed regulations which notes that tax software 
developed by a company engaged in providing tax services to its 
customers is not used by the taxpayer in general and administrative 
functions

[[Page 68300]]

even though tax is listed under Sec.  1.41-4(c)(6)(iii)(B)(1) of the 
proposed regulations, as a general and administrative function. The 
commenter requested that we make this concept more explicit by revising 
Sec.  1.41-4(c)(6)(iii)(A) of the proposed regulations and providing 
additional examples. As discussed in the preamble to the proposed 
regulations, the list of general and administrative functions is 
intended to target the back-office functions that most taxpayers would 
have regardless of the taxpayer's industry, although the 
characterization of a function as back office will vary depending on 
the facts and circumstances of the taxpayer. Because Sec.  1.41-
4(c)(6)(v) of these final regulations makes clear that the 
determination of whether software is developed primarily for internal 
use depends on the intent of the taxpayer and the facts and 
circumstances at the beginning of software development, the Treasury 
Department and the IRS believe that additional clarifying language and 
examples are unnecessary.

II. Definition of Software Not Developed Primarily for Internal Use

    The proposed regulations provided that software is not developed 
primarily for internal use only if it is developed to be commercially 
sold, leased, licensed, or otherwise marketed to third parties, or if 
it 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. After consideration of the comments described 
herein, these final regulations clarify that (1) 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; 
and (2) software that is developed to be commercially sold, leased, 
licensed, or otherwise marketed to third parties and software that 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 are examples of software that is not developed 
primarily for the taxpayer's internal use.

A. Software Developed To Be Commercially Sold, Leased, Licensed or 
Otherwise Marketed to Third Parties

    A commenter requested that Sec.  1.41-4(c)(6)(iv)(A)(1) of the 
proposed regulations be revised to state that software is not developed 
primarily for the taxpayer's internal use if the software is developed 
to be commercially sold, leased, licensed, hosted, or otherwise 
marketed to third parties. (Emphasis added.) The commenter also 
recommended additional language to further define ``otherwise 
marketed'' to include transactions where the taxpayer effectively 
provides the functionality of the software to a third party even if 
there is no transfer of a copy of the software itself to such third 
party. The Treasury Department and the IRS understand that a taxpayer 
may develop software where the full functionality of that software is 
provided to a third party even though there is no transfer of a copy of 
the software. The Treasury Department and the IRS believe the phrase 
``software that is developed to be commercially sold, leased, licensed 
or otherwise marketed to third parties'' is sufficiently broad to 
encompass hosted software and other software where there is no transfer 
of a copy of the software. An example has been added to further 
illustrate this point (Example 9 of these final regulations).

B. Software Developed To Enable a Taxpayer To Interact With Third 
Parties or Allow Third Parties To Initiate Functions or Review Data on 
the Taxpayer's System

    Several commenters requested clarification on the terms 
``interact,'' ``initiate,'' or ``review,'' and recommended additional 
examples illustrating the terms. One commenter noted that a common 
example that should be clarified is whether a third party reviewing a 
Web site constitutes ``interaction,'' ``initiate functions,'' or 
``review data.'' In response to these comments, the final regulations 
clarify that software that 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 are examples of 
software that is not developed primarily for the taxpayer's internal 
use. In addition, these final regulations provide that the 
determination of whether software is internal use 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 
depends on the intent of the taxpayer and the facts and circumstances 
at the beginning of the software development. Accordingly, Example 3 of 
the proposed regulations, now designated as Example 4 in these final 
regulations, is revised to show that software developed with the intent 
of marketing via a Web site and not to allow third parties to review 
data on the taxpayer's system is developed for internal use because it 
was developed for use in a general and administrative function.

III. Connectivity Software

    In the proposed regulations, the Treasury Department and the IRS 
requested comments on the appropriate definition and treatment of 
connectivity software that allows multiple processes running on one or 
more machines to interact across a network, sometimes referred to as 
bridging software, integration software, or middleware. The Treasury 
Department and the IRS received very few responses to this request for 
comments. One of the commenters noted that the treatment of such 
software is challenging because of its multi-faceted purposes; it could 
fall within a category in which it is not sold, does not interact with 
a third party, and does not perform a general and administrative 
function. The other commenter recommended that the regulations provide 
a general rule for connectivity software that is tied to the intent of 
the taxpayer and the facts and circumstances at the beginning of the 
software development and that the regulations provide examples 
demonstrating the rule. In addition, with respect to this category of 
software, the Treasury Department and the IRS understand that with wide 
use and availability of enterprise resource planning (ERP) software, 
few companies actually engage in developing connectivity software. 
Connectivity software is often purchased or the need for it has 
diminished due to the use of ERP software.
    After further consideration of business practices and the limited 
comments received, the Treasury Department and the IRS believe that a 
special rule for connectivity software is not needed. The final 
regulations clarify that software is not developed by (or for the 
benefit of) the taxpayer primarily for the taxpayer's internal use if 
the software is not developed for use in general and administrative 
functions. Accordingly, any software that is not developed to be used 
in a general and administrative function will not be considered to be 
developed for internal use. This is the case even if the software is 
not developed to be commercially sold, leased, licensed, or otherwise 
marketed to third parties, or is not 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.
    Furthermore, connectivity software should not be specifically 
identified or categorized differently from other types of software. 
Whether certain software is developed to be used primarily for

[[Page 68301]]

internal use should be based on the function the software provides, 
rather than the type of software. For example, connectivity software 
that is developed to connect a taxpayer's existing payroll software 
with financial budgeting software to allow an exchange of data between 
the two software modules would be considered to be developed for the 
taxpayer's internal use because the connectivity software's function is 
to be used in human resources and financial management functions. 
Accordingly, the Treasury Department and the IRS believe that the 
general rule in the final regulations to determine whether or not 
software is developed primarily for internal use already provides 
sufficient guidance for connectivity software. Whether software, 
including connectivity software, is developed for use in general and 
administrative functions depends upon the intent of the taxpayer and 
the facts and circumstances at the beginning of the software 
development.

IV. Intent of the Taxpayer and the Facts and Circumstances at the 
Beginning of the Software Development

    The proposed regulations provided that whether software is or is 
not developed primarily for internal use depends upon the intent of the 
taxpayer and the facts and circumstances at the beginning of the 
software development. If a taxpayer originally develops software 
primarily for internal use but later makes improvements to the software 
with the intent to hold the improved software for commercial sale, 
lease, or license or to allow third parties to initiate functions or 
review data on the taxpayer's system, the improvements will be 
considered separate from the existing software and will not be 
considered developed primarily for internal use. Likewise, if a 
taxpayer originally develops software for commercial sale, lease, or 
license or to interact with third parties or to allow third parties to 
initiate functions or review data on the taxpayer's system, but later 
makes improvements to the software with the intent to use the software 
in general and administrative functions, the improvements will be 
considered separate from the existing software and will be considered 
developed primarily for internal use. After consideration of the 
comments described below, these final regulations retain these rules 
without modification.
    A commenter explained that it is common for a taxpayer to initiate 
a software development project with one purpose in mind and to later 
discover that other purposes should be considered and pursued. 
Commenters also explained that it is common for a taxpayer to abandon 
its original intentions of how the software might be used. Commenters 
made several different recommendations, among them that the final 
regulations adopt a standard that allows facts at any point during the 
software development to be considered. Another suggested looking to the 
intended use of the software, and not just the improvements, as of the 
tax return filing date for the taxable year or the beginning of the 
taxable year in which the software development expenditures were 
incurred. One commenter further suggested that if the regulations 
require a determination at the beginning of the software development, 
the regulations should allow that determination to be rebutted with 
evidence about how the software is actually used when it is placed in 
service. Commenters also noted that taxpayers will likely have 
difficulty substantiating their intended use of the software at the 
beginning of the development process.
    The Treasury Department and the IRS conclude 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. Congress intended that the credit for increasing research 
activities would provide an incentive for greater private activity in 
research. That incentive nature of section 41 is promoted by taking 
into account a taxpayer's intent at the beginning of the software 
development; allowing any change in a taxpayer's intent throughout the 
development to support treatment as qualifying research of expenses 
incurred prior to that change would frustrate the purpose of the 
credit. Furthermore, allowing 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. Finally, the 
final regulations continue to provide a special rule for improvements 
to software that can be separately identified. This special rule would 
apply, for example, when a taxpayer completes a software development 
and then decides to improve that software by undertaking further 
development to the same software.

V. Dual Function Software and Safe Harbor

A. Presumption and Third Party Subset

    The proposed regulations provided that software developed by (or 
for the benefit of) the taxpayer 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 software) is presumed to be developed primarily for 
a taxpayer's internal use. However, this presumption is inapplicable to 
the extent that a taxpayer can identify a subset of elements of dual 
function software that only enables a taxpayer to interact with third 
parties or allows third parties to initiate functions or review data on 
the taxpayer's system (third party subset). The proposed regulations 
provided that if the taxpayer can identify a third party subset, the 
portion of qualified research expenditures allocable to such third 
party subset of the dual function software may be eligible for the 
research credit, provided all the other applicable requirements are 
met.
    The Treasury Department and the IRS received several comments on 
dual function software rules. One commenter recommended changes to 
clarify that the dual function software rules do not apply to software 
developed to be commercially sold, leased, licensed, or otherwise 
marketed to third parties, even if such software was also 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 Treasury Department and the IRS believe such clarification is 
unnecessary as Sec.  1.41-4(c)(6)(iv)(C)(1) of the proposed regulations 
clearly defines dual function software as software that is developed by 
the taxpayer both for use in general and administrative functions and 
to enable a taxpayer to interact with third parties or to allow third 
parties to initiate functions or review data. Software that is 
developed to be commercially sold, leased, licensed, or otherwise 
marketed to third parties is not dual function software, even if such 
software was also 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.
    One commenter suggested that the ``substantially all'' and ``shrink 
back'' rules found in Sec.  1.41-4(b)(2) can be easily applied to 
evaluate dual function software. If substantially all of the software 
is non-internal use, then all of the software should be considered non-
internal use under the substantially all rule. Similarly, if 
substantially all of the software is internal use, then the software 
should be considered internal use. In the case where the software as

[[Page 68302]]

a whole does not meet the substantially all rule, then the taxpayer 
would apply the shrink back rule and the software would be divided into 
subcomponents based on functionality until the non-internal use portion 
and the internal use portion were appropriately separated. That 
commenter noted that these two rules have worked for many years with 
little difficulty in other areas of the research credit rules and could 
be used equally well to address the issue of dual function software. 
Another commenter encouraged the addition of a rule to cover cases in 
which a taxpayer's dual function subset's third party use or 
interaction exceeds 80 percent. The commenter stated that in this 
circumstance, the remaining internal use is de minimis and should be 
disregarded and the entire development should be treated as not 
developed for internal use.
    The shrink back rule provides that the requirements of section 
41(d) and Sec.  1.41-4(a) are to be applied first at the level of the 
discrete business component, that is, the product, process, computer 
software, technique, formula, or invention to be held for sale, lease, 
or license, or used by the taxpayer in a trade or business of the 
taxpayer. If these requirements are not met at that level, then they 
apply at the most significant subset of elements of the product, 
process, computer software, technique, formula, or invention to be held 
for sale, lease, or license. This shrinking back of the product is to 
continue until either a subset of elements of the product that 
satisfies the requirements is reached, or the most basic element of the 
product is reached and such element fails to satisfy the test.
    The Treasury Department and the IRS believe that the proposed rules 
already apply principles similar to the shrink back rule to allow 
taxpayers to identify a subset of elements of dual function software 
that only enables a taxpayer to interact with third parties or allows 
third parties to initiate functions or review data on the taxpayer's 
system. The substantially all test referenced by the commenter is 
similar to the general credit eligibility requirement in section 
41(d)(1)(C), which provides that in order for activities to constitute 
qualified research, substantially all of the activities must constitute 
elements of a process of experimentation that relates to a qualified 
purpose. Under Sec.  1.41-4(a)(6), this substantially all requirement 
is satisfied only if 80 percent or more of a taxpayer's research 
activities, for the development or improvement of a business component, 
measured on a cost or other consistently applied reasonable basis, 
constitute elements of a process of experimentation. In contrast to the 
general requirement of section 41(d)(1) pertaining to qualifying 
research, section 41(d)(4)(E) does not apply the substantially all test 
when it excludes activities related to internal use software from 
qualifying research. Accordingly, the Treasury Department and the IRS 
believe the use of the substantially all test in these regulations is 
inappropriate, and the final regulations do not adopt the commenter's 
suggested approach.
    Another commenter requested that the dual function rules be 
eliminated because the provisions are confusing and unnecessary and 
that trying to delineate elements of dual function software raises 
significant administrative issues. Similarly, another commenter noted 
that the concepts in the dual function rules can be confusing to 
taxpayers and will require additional recordkeeping by taxpayers. 
According to this commenter, most taxpayers do not differentiate their 
software applications by ``third party interactions'' or generally 
track such interactions. One commenter similarly stated that Sec.  
1.41-4(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.
    Regarding the presumption that dual function software is developed 
for internal use, a commenter stated that such presumption is contrary 
to the intent of the statute. One commenter recommended that the 
presumption should be replaced with a primary purpose test, consistent 
with the statutory language that looks to whether software is developed 
``primarily'' for internal use.
    The Treasury Department and the IRS believe it is necessary to 
implement rules for dual function software as this type of software 
development is increasingly common in business practice. Rather than 
simply reiterating the ``primarily'' language in the statute, these 
regulations specifically identify the types of software functions that 
are considered to be primarily for internal use. A definition that 
specifically identifies the types of software functions that are 
considered to be primarily for internal use provides a clearer 
objective test that will provide consistency in application. The nature 
of software and its development has rapidly evolved over time, and the 
statute did not expressly address the treatment of dual function 
software. In conjunction with crafting a narrow definition of internal 
use, the Treasury Department and the IRS believe that the dual function 
software rules in the proposed regulations strike an appropriate 
balance between the administrative burdens and compliance concerns 
relating to claiming the research credit for activities relating to 
software. Thus, these final regulations retain the dual function rules. 
These final regulations are applicable to taxable years beginning on or 
after the date of their publication in the Federal Register. Taxpayers 
have been aware of the proposed rules and have had the opportunity to 
begin maintaining the necessary documentation to establish their 
entitlement to research credits under these rules.

B. Safe Harbor

    The proposed regulations provided taxpayers with a safe harbor to 
apply to dual function software if there remains a subset of elements 
of dual function software (dual function subset) after the third party 
subset has been identified. The safe harbor allows a taxpayer to 
include 25 percent of the qualified research expenditures of the dual 
function subset in computing the amount of the taxpayer's credit, 
provided that the taxpayer's research activities related to the dual 
function subset constitute qualified research and the use of the dual 
function subset 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.
    Some commenters requested that the safe harbor be removed from the 
regulations. Specifically, one commenter stated that the burdens 
associated with the safe harbor may be greater than its benefits and 
noted the multiple steps that a taxpayer must take to determine if it 
meets the safe harbor. Another commenter noted that the safe harbor 
complicates the administration of the credit for both taxpayers and the 
IRS.
    Another commenter noted that the safe harbor potentially penalizes 
the taxpayer with the inequitable result of allowing only 25 percent of 
the qualified research expenditures. According to the commenter, given 
that a taxpayer must document anticipated use, it should then follow 
that the portion of software treated as third party facing should 
mirror this analysis. In other words, the proportion anticipated to be 
third party facing should be the proportion of software that is not 
developed primarily for internal use.
    After careful consideration, the final regulations do not adopt 
these comments. However, the safe harbor has

[[Page 68303]]

been modified to clarify that the safe harbor can be applied to the 
dual function software or the dual function subset after the 
application of Sec.  1.41-4(c)(6)(vi)(B) of the final regulations. The 
safe harbor is not a requirement but an option available for taxpayers 
who cannot identify a third party subset, or after identification of a 
third party subset, still have a dual function subset. Without the safe 
harbor, dual function software or a dual function subset would be 
presumed to be internal use and the taxpayer would have to demonstrate 
that the research with respect to the dual function software or dual 
function subset meets the high threshold of innovation test in addition 
to the general eligibility requirements under section 41(d)(1). The 
safe harbor provides a benefit, not a detriment, to taxpayers, provided 
the dual function software or dual function subset's use by third 
parties is anticipated to be at least 10 percent of the total use. 
Taxpayers who consider it too burdensome to comply with the 
requirements of the safe harbor can choose not to rely upon it.

C. Time of Determination

    Several commenters noted concerns with the time of determination 
for the application of the safe harbor. A commenter noted that 
determining the percentage of third party use based upon an estimate 
made at the beginning of software development imposes an undue 
administrative burden and may not be an accurate reflection of the 
actual use once the software is released. This commenter requested that 
the rule be eliminated or amended to provide that a taxpayer must 
estimate third party use once the software is deployed. Similarly, 
another commenter noted that it has not been their experience that 
taxpayers plot out the future expected use of their software at the 
time the development begins with such specificity, especially given 
that software development is an iterative development process where 
functionality and expected uses rapidly evolve. Lastly, another 
commenter requested that, similar to the provisions for improvements to 
existing software, there should be a mechanism to recharacterize 
software over time.
    While the Treasury Department and the IRS understand commenters' 
concerns, the final regulations do not change the requirement that the 
time of determination occur at the beginning of the software 
development. As discussed herein, the Treasury Department and the IRS 
continue to believe that the rule requiring that a determination be 
made at the beginning of the software development is most accurate and 
appropriate given Congress' intent that the research credit serve as an 
incentive to conduct qualifying research rather than an unanticipated 
reward for doing so.

D. Objective Reasonable Method

    In the proposed regulations, the Treasury Department and the IRS 
invited comments on the administrability of measuring the reasonably 
anticipated use of software by taxpayers to interact with third parties 
and by third parties to initiate functions or review data based on 
reasonable methods (such as processing time, amount of data transfer, 
number of software user interface screens, number of third party 
initiated functions, and other objective, reasonable methods) and 
whether the regulations should include specific reasonable methods and 
examples.
    A commenter recommended that due to the wide range of taxpayers 
that will be subject to these regulations, the final regulations should 
not provide overly detailed examples of ``reasonable methods.'' This 
commenter noted that it should be clear that any examples of reasonable 
methods are for illustrative purposes only and any reasonable method 
may be acceptable. Another commenter recommended the adoption of the 
phrase ``within each industry'' to ensure that the application of the 
objective, reasonable method takes into account unique aspects of all 
taxpayers within given industries.
    The Treasury Department and the IRS agree that it is unrealistic to 
impose one specific method that will be used to measure reasonably 
anticipated use due to the variety of industries that are subject to 
the final regulations. Therefore, the final regulations provide that 
any objective, reasonable method within the taxpayer's industry may be 
used for purposes of the safe harbor.

VI. Third Party Definition

    The proposed regulations provided that the term ``third party'' 
means any corporation, trade or business, or other person that is not 
treated as a single taxpayer with the taxpayer pursuant to section 
41(f). A commenter raised concerns and requested that the Treasury 
Department and the IRS reconsider whether it is appropriate to apply 
the controlled group standard under section 41(f). The commenter 
contended that this third party definition would potentially deny a 
research credit to some software for artificial reasons. The commenter 
further noted that if the regulations do not modify the third party 
definition, taxpayers should at least have an opportunity to 
demonstrate that software provided to a member of the controlled group 
is not internal use software based on the facts and circumstances.
    The Treasury Department and the IRS continue to believe that the 
use of the controlled group standard under section 41(f) is 
appropriate. A well established, objective standard is essential and 
using the standard in section 41(f) is consistent with the reference to 
section 41(f) in section 41(b)(2) relating to in-house research 
expenditures and in Sec.  1.41-6(a)(3)(ii) relating to the definition 
of controlled group for purposes of aggregating expenditures.
    The proposed regulations also provided that 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 
conduct of the taxpayer's trade or business, e.g., the taxpayer's own 
vendors. A commenter contended that excluding any person that uses a 
taxpayer's software to support a general and administrative function 
from the definition of third party creates confusion and blurs a well-
conceived, objective measurement. This commenter believes the term 
third party suggests a person who is external to the organization or a 
person who is not an employee. The Treasury Department and the IRS note 
that the statute provides a higher standard for internal use software, 
in part, because the benefits of such software are intended primarily 
for the taxpayer developing it. 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. 
Accordingly, the final regulations do not adopt these comments 
requesting a change to the definition of third party.

VII. High Threshold of Innovation--Significant Economic Risk

    The proposed regulations provided that certain internal use 
software is eligible for the research credit if the software satisfies 
the high threshold of innovation test, the three parts of which are (1) 
software is innovative in that 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; (2) software development involves 
significant economic risk in that the taxpayer commits substantial 
resources to the development and there is a substantial uncertainty, 
because of

[[Page 68304]]

technical risk, that such resources would be recovered within a 
reasonable period; and (3) 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. The proposed regulations further provided that 
substantial uncertainty exists if, at the beginning of the taxpayer's 
activities, the information available to the taxpayer does not 
establish the capability or method for developing or improving the 
software.

A. Design Uncertainty

    Several commenters requested that the final regulations include 
design uncertainty in the definition of technical risk for purposes of 
meeting the significant economic risk test. Commenters noted that both 
sections 174 and 41 have long included the concept of design 
uncertainty. Commenters also raised concerns that the statute and 
regulations do not define the concepts of capability, methodology, and 
design uncertainty. Commenters further explained that these three types 
of uncertainties are inherently related to each other, and it is often 
difficult for taxpayers to clearly state or describe which type of 
uncertainty they face.
    The use of the word ``substantial'' before ``uncertainty'' in the 
significant economic risk test for internal use software indicates a 
higher threshold of uncertainty than that required for business 
components that are not internal use software. While there may be 
design uncertainty in the development of internal use software, 
substantial uncertainty generally exists only when there is also 
uncertainty in regard to the capability or method of achieving the 
intended result. However, the Treasury Department and the IRS 
understand that it is difficult to delineate the types of technical 
uncertainties and attempting to do so may lead to unnecessary burdens 
on both taxpayers and the IRS. Furthermore, the appropriate design 
uncertainty of internal use software may be inextricably linked to 
substantial uncertainty regarding capability or method. The focus of 
the significant economic risk test should be on the level of 
uncertainty that exists and not the types of uncertainty. For these 
reasons, the final regulations remove the reference to capability and 
method uncertainty. However, the Treasury Department and the IRS 
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.

B. Substantial Resources/Reasonable Time Period

    A commenter requested that the final regulations provide further 
explanation or examples on what constitutes ``substantial resources'' 
or a ``reasonable time period'' for purposes of meeting the significant 
economic risk test. The Treasury Department and the IRS believe that 
whether the amount of resources committed is substantial or whether 
substantial resources would be recovered within a reasonable time 
period are factual determinations to be resolved based on the 
taxpayer's facts and circumstances and, therefore, further explanation 
or examples would be too specific and not helpful. Accordingly, the 
final regulations do not adopt these comments.

C. Application of High Threshold of Innovation Test

    Another commenter requested deletion of the statement, ``[i]t is 
not always necessary to have a revolutionary discovery or creation of 
new technologies such as a new programming language, operating system, 
architecture, or algorithm to satisfy the high threshold of innovation 
test.'' The commenter is concerned that the sentence can be read to 
imply that in some situations it will be necessary to have a 
revolutionary discovery to qualify internal use software for the 
research credit. The Treasury Department and the IRS did not intend the 
inclusion of this statement to have the interpretation suggested or 
taken by the commenter. Accordingly, the Treasury Department and the 
IRS agree that this statement should be removed from the final 
regulations because a revolutionary discovery is not required to meet 
the high threshold of innovation test.
    Furthermore, the Treasury Department and the IRS are revising 
Sec. Sec.  1.41-4(c)(6)(i) and (ii) of the proposed regulations to 
clarify that the internal use software rules under Sec.  1.41-4(c)(6) 
do not apply to (1) software developed for use in an activity that 
constitutes qualified research, (2) software developed for use in a 
production process to which the requirements of section 41(d)(1) are 
met, and (3) a new or improved package of software and hardware 
developed together by the taxpayer as a single product. Accordingly, 
under the final regulations, the high threshold of innovation test 
applies only to the software developed for use in general and 
administrative functions that facilitate or support the conduct of the 
taxpayer's trade or business and to dual function software.

VIII. Examples

A. Process of Experimentation

    Section 1.41-4(a)(8) of the proposed regulations provided six new 
examples illustrating the application of the process of experimentation 
requirement to software under section 41(d)(1)(C).
    One commenter noted that the examples appear to suggest a 
presumption that activities related to developing web design or ERP 
software do not meet the process of experimentation requirement. This 
commenter requested that the final regulations clearly state the 
reasons for such presumption. The proposed regulations and these final 
regulations do not establish a presumption against a particular type of 
software; rather these examples focus on the facts and circumstances 
surrounding activities to determine whether they involve a process of 
experimentation.
    Another commenter requested that the final regulations include 
additional examples demonstrating fact patterns that do not initially 
qualify as a process of experimentation but where a change in facts 
introduces technical uncertainty that requires a process of 
experimentation. The final regulations could provide examples 
describing a particular change in facts that would introduce technical 
uncertainty and require a process of experimentation; however, because 
the examples are very factual and would differ based on a taxpayer's 
business, we do not think more examples would provide the clarification 
that the commenter is seeking. Accordingly, the final regulations do 
not include additional examples to address this comment.
i. Example 6
    Section 1.41-4(a)(8), Example 6, of the proposed regulations 
analyzed whether activities related to selecting a commercial software 
vendor with object-oriented functions and selecting and incorporating 
the specific functions into new software developed by X involved 
conducting a process of experimentation.
    One commenter noted that the use of certain terms in Example 6, 
such as ``develop,'' ``evaluate,'' and ``determine'' suggest that the 
process of experimentation criteria may be met and recommended changes 
to clearly show that a purchase, installation, and

[[Page 68305]]

selection from pre-determined categories do not meet a process of 
experimentation. We disagree with the commenter because the use or 
nonuse of certain terms is not an implication that the process of 
experimentation criteria has or has not been met. This example is 
intended to show that the process of experimentation requirement is not 
met regardless of the terms used. Accordingly, the final regulations do 
not adopt this comment.
ii. Example 7
    Section 1.41-4(a)(8), Example 7, of the proposed regulations 
analyzed whether when developing software, activities relating to X's 
decision to use a separate server to distribute the workload across 
each of the web servers and X's decision that a round robin workload 
distribution algorithm is appropriate for its needs involved conducting 
a process of experimentation.
    Two commenters recommended removing Example 7. One commenter 
believed that the example did not provide any clarification. The other 
commenter stated that the example shows a failure to meet the technical 
uncertainty requirement under section 174, rather than a process of 
experimentation. While the Treasury Department and the IRS agree with 
the commenter that activities under section 174 must be for the purpose 
of discovering information that would eliminate uncertainties, Example 
7 is intended to demonstrate the process of experimentation requirement 
under section 41(d). The example shows a taxpayer's failure to meet the 
process of experimentation requirement under section 41(d)(1) because 
the use of a technique or design, such as a round robin workload 
distribution algorithm, does not qualify where the taxpayer did not 
conduct a process of evaluating alternatives intended to eliminate 
uncertainty regarding the development of software. Accordingly, the 
final regulations do not adopt these comments.
iii. Example 8
    Section 1.41-4(a)(8), Example 8, of the proposed regulations 
analyzed whether X's activities relating to design and systematic 
testing and evaluation of several different algorithms in the 
development of load balancing software involved conducting a process of 
experimentation.
    One commenter recommended that all references to the terms 
``dynamic'' and ``highly volatile'' be removed because the commenter 
believes the terms provide no additional value and that they suggest 
that the nature of X's business environment has some bearing on the 
performance of qualified research. The Treasury Department and the IRS 
disagree and the final regulations do not adopt the commenter's 
recommendation because we believe the nature of a taxpayer's business 
environment can be a valuable indicator of circumstances that may 
result in the necessary uncertainty required for a process of 
experimentation.
    Another commenter requested that for both Example 8 and Example 10, 
the Treasury Department and the IRS provide clarification by applying 
the high threshold of innovation test once the software is determined 
to be internal use software. Additionally, this commenter requested 
that the final regulations provide an additional example addressing 
this process. The Treasury Department and the IRS note that the 
examples are added to illustrate only the application of a process of 
experimentation to software research. They are not meant to address the 
high threshold of innovation test; those examples were provided under 
Sec.  1.41-4(c)(6)(vi) of the proposed regulations. Furthermore, a 
comprehensive example that applies the rules contained in Sec.  1.41-
4(c)(6) would require more developed facts and layers of analysis and 
would be better suited for a different type of published guidance than 
these final regulations. Accordingly, the final regulations do not 
adopt these comments.
iv. Example 9
    Section 1.41-4(a)(8), Example 9, of the proposed regulations 
analyzed whether X's activities relating to the installation of an ERP 
system involved a process of experimentation.
    Two commenters requested deletion of the phrase ``routine 
programming'' in Example 9 because the term is subjective, 
immeasurable, and inconsistent with Suder v. Commissioner, T.C. Memo 
2014-201. One commenter also stated that taxpayers may confront 
uncertainty about the appropriate design of the configuration of an ERP 
system, and the example does not address this technical uncertainty. 
The Treasury Department and the IRS did not intend to illustrate in 
this example the types of uncertainty that must be eliminated to 
satisfy the process of experimentation requirement under section 
41(d)(1). Rather, this example demonstrates a taxpayer's failure to 
meet the process of experimentation requirement under section 41(d)(1) 
because X did not conduct a process of evaluating alternatives in order 
to eliminate uncertainty regarding the development of the ERP software. 
Accordingly, the Treasury Department and the IRS believe further 
clarification of these examples is unnecessary. Furthermore, the Tax 
Court's decision in Suder is not inconsistent with Example 9 because in 
Suder the court did not address whether ``routine programming'' could 
meet the process of experimentation requirement.

B. Internal Use Software

    The proposed regulations provided examples illustrating the 
provisions contained in Sec.  1.41-4(c)(6) of the proposed regulations.
i. Example 3
    Section 1.41-4(c)(6)(vi), Example 3, of the proposed regulations 
analyzed whether software that is developed for a Web site that 
provides general information about the taxpayer's business, and which 
does not enable a taxpayer to interact with third parties or allow 
third parties to initiate functions or review data, is internal use 
software.
    One commenter disagreed with the characterization of the facts in 
Example 3 which illustrates a support services function. The commenter 
believes that the software is dual function software that is developed 
to allow a third party to review data and to be used in marketing. The 
Treasury Department and the IRS disagree with the commenter's 
characterization of Example 3. The example demonstrates that the 
software is intended to serve marketing purposes and thus is developed 
to be used in general and administrative functions. Changes were made 
to clarify this example which is designated as Example 4 of the final 
regulations.
ii. Example 6
    Section 1.41-4(c)(6)(vi), Example 6, of the proposed regulations 
analyzed the definition of third parties, specifically whether software 
that is developed to allow its users to upload and modify photographs 
at no charge allows third parties to initiate functions on the 
taxpayer's system.
    A commenter believed the example is an important example that comes 
to the correct conclusion, but the commenter believed it is not a 
particularly good fact pattern to illustrate the third party 
interaction exclusion. Specifically, the commenter requested changes to 
the conclusion of the example to show that the advertising software is 
developed for use in a marketing function to an unrelated third party.
    The purpose of the example is to illustrate the third party 
definition and

[[Page 68306]]

to demonstrate whether the software is developed to allow third parties 
to initiate functions or review data. The example is not meant to 
address which, if any, general and administrative function applies to 
the software. Accordingly, the final regulations do not adopt this 
comment. However, other changes were made to clarify Example 6 of the 
proposed regulations, which is designated as Example 8 of the final 
regulations.

IX. Effective/Applicability Date

    Some commenters requested that the final regulations apply 
retroactively back to 1986, while one commenter requested that the 
final regulations apply retroactively back to 2004 to give software 
development equal treatment with all other types of qualified research 
as defined under TD 9104 (69 FR 22). After further consideration, the 
effective date in the proposed regulations is generally retained with 
slight modifications. These final regulations are prospective and apply 
to taxable years beginning on or after the date of publication of this 
Treasury decision in the Federal Register.
    Retroactive application of these final regulations may provide an 
unfair advantage to taxpayers whose prior taxable years are not closed 
by the statute of limitations. Furthermore, retroactively determining 
whether taxpayers engaged in research activities does not further the 
purpose of section 41 which is to encourage taxpayers to engage in 
qualifying research activities within the United States and would 
impose a significant administrative burden on the IRS.
    Section 41(d)(4)(E) provides that, except to the extent provided by 
regulations, research with respect to computer software that is 
developed by (or for the benefit of) the taxpayer primarily for 
internal use by the taxpayer is excluded from the definition of 
qualified research under section 41(d). The nature of software and its 
development has rapidly evolved over time. Recognizing the evolving 
nature of software technology and its role in business practices, these 
final regulations more narrowly define internal use software than the 
rules that apply for prior periods. These final regulations are not, 
and should not be viewed as, an interpretation of prior regulatory 
guidance. Software not developed for internal use under these final 
regulations, such as software developed to enable a taxpayer to 
interact with third parties, may or may not have been internal use 
software under prior law.
    The proposed regulations provided that the 2004 ANPRM (published in 
the Federal Register (69 FR 43)) is withdrawn effective for taxable 
years beginning on or after January 20, 2015, the date the proposed 
regulations were published in the Federal Register (80 FR 2624). For 
taxable years ending before January 20, 2015, taxpayers may choose to 
follow either all of the internal use software provisions of Sec.  
1.41-4(c)(6) in the final regulations published on January 3, 2001 in 
the Federal Register (TD 8930; 66 FR 280) or all of the internal use 
software provisions of Sec.  1.41-4(c)(6) contained in the proposed 
regulations (REG-112991-01) published on December 26, 2001 in the 
Federal Register (66 FR 66362). In addition, the IRS will not challenge 
return positions consistent with all of paragraph (c)(6) of these final 
regulations or all of paragraph (c)(6) of the proposed regulations for 
any taxable year that both ends on or after January 20, 2015, the date 
the proposed regulations were published in the Federal Register (80 FR 
2624), and begins before October 4, 2016.

X. Duty of Consistency

    Some commenters noted the administrative difficulties of applying 
the duty of consistency rule under section 41(c)(6)(A) and requested 
guidance on how to comply with the consistency rule.
    The duty of consistency is a statutory requirement and existing 
regulations under Sec. Sec.  1.41-3(d) and 1.41-9(c) provide sufficient 
guidance for taxpayers to follow. In computing the research credit, 
qualified research expenses and gross receipts must be determined on a 
basis consistent with the definition of qualified research expenses and 
gross receipts for the credit year. These final regulations do not 
modify this existing law. Section 1.41-3(d) provides that in computing 
the credit for increasing research activities, qualified research 
expenses and gross receipts taken into account in computing a 
taxpayer's fixed-base percentage and a taxpayer's base amount must be 
determined on a basis consistent with the definition of qualified 
research expenses and gross receipts for the credit year, without 
regard to the law in effect for the taxable years taken into account in 
computing the fixed-base percentage or the base amount. Section 1.41-
3(d) also provides examples illustrating the requirement. Current 
section 1.41-9(c) contains similar rules. Accordingly, the final 
regulations do not adopt the commenters' suggestions concerning the 
duty of consistency.

Special Analyses

    Certain IRS regulations, including this one, are exempt from the 
requirements of Executive Order 12866, as supplemented and reaffirmed 
by Executive Order 13563. Therefore, a regulatory impact assessment is 
not required. It also has been determined that section 553(b) of the 
Administrative Procedure Act (5 U.S.C. chapter 5) does not apply to 
these regulations, and because the regulations do not impose a 
collection of information on small entities, the Regulatory Flexibility 
Act (5 U.S.C. chapter 6) does not apply. Pursuant to section 7805(f) of 
the Code, the notice of proposed rulemaking was submitted to the Chief 
Counsel for Advocacy of the Small Business Administration for comment 
on its impact on small business, and no comments were received.

Drafting Information

    The principal author of these regulations is Martha M. Garcia, 
Office of the Associate Chief Counsel (Passthroughs and Special 
Industries), IRS. However, other personnel from the Treasury Department 
and the IRS participated in their development.

List of Subjects in 26 CFR Part 1

    Income taxes, Reporting and recordkeeping requirements.

Adoption of Amendments to the Regulations

    Accordingly, 26 CFR part 1 is amended as follows:

PART 1--INCOME TAXES

0
Paragraph 1. The authority citation for part 1 is amended by adding an 
entry in numerical order to read in part as follows:

    Authority:  26 U.S.C. 7805 * * *
* * * * *
    Section 1.41-4 also issued under 26 U.S.C. 41(d)(4)(E).
* * * * *

0
Par. 2. Section 1.41-0 is amended by:
0
1. Revising the entry in the table of contents for Sec.  1.41-4(c)(6).
0
2. Adding entries in the table of contents for Sec.  1.41-4(c)(6)(i) 
through (viii).
    The revision and additions read as follows:


Sec.  1.41-0.  Table of contents.

* * * * *


Sec.  1.41-4.  Qualified research for expenditures paid or incurred in 
taxable years ending on or after December 31, 2003.

* * * * *
    (c) * * *

[[Page 68307]]

    (6) Internal use software.
    (i) General rule.
    (ii) Inapplicability of the high threshold of innovation test.
    (iii) Software developed primarily for internal use.
    (iv) Software not developed primarily for internal use.
    (v) Time and manner of determination.
    (vi) Software developed for both internal use and to enable 
interaction with third parties (dual function software).
    (vii) High threshold of innovation test.
    (viii) Illustrations.
* * * * *

0
Par. 3. Section 1.41-4 is amended by:
0
1. Adding Example 5 through Example 10 at the end of paragraph (a)(8).
0
2. Revising paragraphs (c)(6) and (e).
    The additions and revisions read as follows:


Sec.  1.41-4  Qualified research for expenditures paid or incurred in 
taxable years ending on or after December 31, 2003.

    (a) * * *
    (8) * * *
    Example 5.  (i) Facts. X, a retail and distribution company, 
wants to upgrade its warehouse management software. X evaluates 
several of the alternative warehouse management software products 
available from vendors in the marketplace to determine which product 
will best serve X's technical requirements. X selects vendor V's 
software.
    (ii) Conclusion. X's activities to select the software are not 
qualified research under section 41(d)(1) and paragraph (a)(5) of 
this section. X did not conduct a process of evaluating alternatives 
in order to eliminate uncertainty regarding the development of a 
business component. X's evaluation of products available from 
vendors is not a process of experimentation.
    Example 6.  (i) Facts. X wants to develop a new web application 
to allow customers to purchase its products online. X, after 
reviewing commercial software offered by various vendors, purchases 
a commercial software package of object-oriented functions from 
vendor Z that X can use in its web application (for example, a 
shopping cart). X evaluates the various object-oriented functions 
included in vendor Z's software package to determine which functions 
it can use. X then incorporates the selected software functions in 
its new web application software.
    (ii) Conclusion. X's activities related to selecting the 
commercial software vendor with the object-oriented functions it 
wanted, and then selecting which functions to use, are not qualified 
research under section 41(d)(1) and paragraph (a)(5) of this 
section. In addition, incorporating the selected object-oriented 
functions into the new web application software being developed by X 
did not involve conducting a process of evaluating alternatives in 
order to eliminate uncertainty regarding the development of 
software. X's evaluation of products available from vendors and 
selection of software functions are not a process of 
experimentation.
    Example 7.  (i) Facts. In order to be more responsive to user 
online requests, X wants to develop software to balance the incoming 
processing requests across multiple web servers that run the same 
set of software applications. Without evaluating or testing any 
alternatives, X decides that a separate server will be used to 
distribute the workload across each of the web servers and that a 
round robin workload distribution algorithm is appropriate for its 
needs.
    (ii) Conclusion. X's activities to develop the software are 
activities relating to the development of a separate business 
component under section 41(d)(2)(A). X's activities to develop the 
load distribution function are not qualified research under section 
41(d)(1) and paragraph (a)(5) of this section. X did not conduct a 
process of evaluating different load distribution alternatives in 
order to eliminate uncertainty regarding the development of 
software. X's selection of a separate server and a round robin 
distribution algorithm is not a process of experimentation.
    Example 8.  (i) Facts. X must develop load balancing software 
across a server cluster supporting multiple web applications. X's 
web applications have high concurrency demands because of a dynamic, 
highly volatile environment. X is uncertain of the appropriate 
design of the load balancing algorithm, given that the existing 
evolutionary algorithms did not meet the demands of their highly 
volatile web environment. Therefore, X designs and systematically 
tests and evaluates several different algorithms that perform the 
load distribution functions.
    (ii) Conclusion. X's activities to develop software are 
activities to develop a separate business component under section 
41(d)(2)(A). X's activities involving the design, evaluation, and 
systematic testing of several new load balancing algorithms meet the 
requirements as set forth in paragraph (a)(5) of this section. X's 
activities constitute elements of a process of experimentation 
because X identified uncertainties related to the development of a 
business component, identified alternatives intended to eliminate 
those uncertainties, and evaluated one or more alternatives to 
achieve a result where the appropriate design was uncertain at the 
beginning of X's research activities.
    Example 9.  (i) Facts. X, a multinational manufacturer, wants to 
install an enterprise resource planning (ERP) system that runs off a 
single database so that X can track orders more easily, and 
coordinate manufacturing, inventory, and shipping among many 
different locations at the same time. In order to successfully 
install and implement ERP software, X evaluates its business needs 
and the technical requirements of the software, such as processing 
power, memory, storage, and network resources. X devotes the 
majority of its resources in implementing the ERP system to 
evaluating the available templates, reports, and other standard 
programs and choosing among these alternatives in configuring the 
system to match its business process and reengineering its business 
process to match the available alternatives in the ERP system. X 
also performs some data transfer from its old system, involving 
routine programming and one-to-one mapping of data to be exchanged 
between each system.
    (ii) Conclusion. X's activities related to the ERP software 
including the data transfer are not qualified research under section 
41(d)(1) and paragraph (a)(5) of this section. X did not conduct a 
process of evaluating alternatives in order to eliminate uncertainty 
regarding the development of software. X's activities in choosing 
between available templates, reports, and other standard programs 
and conducting data transfer are not elements of a process of 
experimentation.
    Example 10.  (i) Facts. Same facts as Example 9 except that X 
determines that it must interface part of its legacy software with 
the new ERP software because the ERP software does not provide a 
particular function that X requires for its business. As a result, X 
must develop an interface between its legacy software and the ERP 
software, and X evaluates several data exchange software 
applications and chooses one of the available alternatives. X is 
uncertain as to how to keep the data synchronized between the legacy 
and ERP systems. Thus, X engages in systematic trial and error 
testing of several newly designed data caching algorithms to 
eliminate synchronization problems.
    (ii) Conclusion. Substantially all of X's activities with 
respect to this ERP project do not satisfy the requirements for a 
process of experimentation. However, when the shrinking-back rule is 
applied, a subset of X's activities do satisfy the requirements for 
a process of experimentation. X's activities to develop the data 
caching software and keeping the data on the legacy and ERP systems 
synchronized meet the requirements of qualified research as set 
forth in paragraph (a)(2) of this section. Substantially all of X's 
activities to develop the specialized data caching and 
synchronization software constitute elements of a process of 
experimentation because X identified uncertainties related to the 
development of a business component, identified alternatives 
intended to eliminate those uncertainties, and evaluated 
alternatives to achieve a result where the appropriate design of 
that result was uncertain as of the beginning of the taxpayer's 
research activities.
* * * * *
    (c) * * *
    (6) Internal use software--(i) General rule. Research with respect 
to software that is developed by (or for the benefit of) the taxpayer 
primarily for the taxpayer's internal use is eligible for the research 
credit only if--
    (A) The research with respect to the software satisfies the 
requirements of section 41(d)(1);
    (B) The research with respect to the software is not otherwise 
excluded under section 41(d)(4) (other than section 41(d)(4)(E)); and

[[Page 68308]]

    (C) The software satisfies the high threshold of innovation test of 
paragraph (c)(6)(vii) of this section.
    (ii) Inapplicability of the high threshold of innovation test. This 
paragraph (c)(6) does not apply to the following:
    (A) 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);
    (B) 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 requirements of section 41(d)(1) are met; and
    (C) 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.
    (iii) Software developed primarily for internal use--(A) In 
general. Except as otherwise provided in paragraph (c)(6)(vi) of this 
section, software is developed by (or for the benefit of) the taxpayer 
primarily for the taxpayer's internal use if the software is developed 
for use in general and administrative functions that facilitate or 
support the conduct of the taxpayer's trade or business. Software that 
the taxpayer develops primarily for a related party's internal use will 
be considered internal use software. A related party is any 
corporation, trade or business, or other person that is treated as a 
single taxpayer with the taxpayer pursuant to section 41(f).
    (B) General and administrative functions. General and 
administrative functions are:
    (1) Financial management. Financial management functions are 
functions that involve the financial management of the taxpayer and the 
supporting recordkeeping. Financial management functions include, but 
are not limited to, functions such as accounts payable, accounts 
receivable, inventory management, budgeting, cash management, cost 
accounting, disbursements, economic analysis and forecasting, financial 
reporting, finance, fixed asset accounting, general ledger bookkeeping, 
internal audit, management accounting, risk management, strategic 
business planning, and tax.
    (2) Human resources management. Human resources management 
functions are functions that manage the taxpayer's workforce. Human 
resources management functions include, but are not limited to, 
functions such as recruiting, hiring, training, assigning personnel, 
and maintaining personnel records, payroll, and benefits.
    (3) Support services. Support services are other functions that 
support the day- to-day operations of the taxpayer. Support services 
include, but are not limited to, functions such as data processing, 
facility services (for example, grounds keeping, housekeeping, 
janitorial, and logistics), graphic services, marketing, legal 
services, government compliance services, printing and publication 
services, and security services (for example, video surveillance and 
physical asset protection from fire and theft).
    (iv) Software not developed primarily for internal use. 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, 
such as--
    (A) Software developed to be commercially sold, leased, licensed, 
or otherwise marketed to third parties; or
    (B) 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.
    (v) Time and manner of determination. For purposes of paragraphs 
(c)(6)(iii) and (iv) of this section, whether software is developed 
primarily for internal use or not developed primarily for internal use 
depends on the intent of the taxpayer and the facts and circumstances 
at the beginning of the software development. For example, software 
will not be considered internal use software solely because it is used 
internally for purposes of testing prior to commercial sale, lease, or 
license. If a taxpayer originally develops software primarily for 
internal use, but later makes improvements to the software with the 
intent to hold the improved software to be sold, leased, licensed, or 
otherwise marketed to third parties, or to interact with third parties 
or to allow third parties to initiate functions or review data on the 
taxpayer's system using the improved software, the improvements will be 
considered separate from the existing software and will not be 
considered developed primarily for internal use. Alternatively, if a 
taxpayer originally develops software to be sold, leased, licensed, or 
otherwise marketed to third parties, or to interact with third parties 
or to allow third parties to initiate functions or review data on the 
taxpayer's system, but later makes improvements to the software with 
the intent to use the software in general and administrative functions, 
the improvements will be considered separate from the existing software 
and will be considered developed primarily for internal use.
    (vi) Software developed for both internal use and to enable 
interaction with third parties (dual function software)--(A) 
Presumption of development primarily for internal use. Unless paragraph 
(c)(6)(vi)(B) or (C) of this section applies, software developed by (or 
for the benefit of) the taxpayer 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 on the taxpayer's system (dual function software) is presumed to 
be developed primarily for a taxpayer's internal use.
    (B) Identification of a subset of elements of software that only 
enables interaction with third parties. To the extent that a taxpayer 
can identify a subset of elements of dual function software that only 
enables a taxpayer to interact with third parties or allows third 
parties to initiate functions or review data (third party subset), the 
presumption under paragraph (c)(6)(vi)(A) of this section does not 
apply to such third party subset, and such third party subset is not 
developed primarily for internal use as described under paragraph 
(c)(6)(iv)(B) of this section.
    (C) Safe harbor for expenditures related to software developed for 
both internal use and to enable interaction with third parties. If, 
after the application of paragraph (c)(6)(vi)(B) of this section, there 
remains dual function software or a subset of elements of dual function 
software (dual function subset), a taxpayer may include 25 percent of 
the qualified research expenditures of such dual function software or 
dual function subset in computing the amount of the taxpayer's credit. 
This paragraph (c)(6)(vi)(C) applies only if the taxpayer's research 
activities related to the development or improvement of the dual 
function software or dual function subset constitute qualified research 
under section 41(d), without regard to section 41(d)(4)(E), and the 
dual function software or dual function

[[Page 68309]]

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 software or the dual function subset's use. 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. 
An objective, reasonable method may include, but is not limited to, 
processing time, amount of data transfer, and number of software user 
interface screens.
    (D) Time and manner of determination. A taxpayer must apply this 
paragraph (c)(6)(vi) based on the intent of the taxpayer and the facts 
and circumstances at the beginning of the software development.
    (E) Third party. For purposes of paragraphs (c)(6)(iv), (v), and 
(vi) of this section, the term third party means any corporation, trade 
or business, or other person that is not treated as a single taxpayer 
with the taxpayer pursuant to section 41(f). Additionally, for purposes 
of paragraph (c)(6)(iv)(B) of this section, third parties do not 
include any persons that use the software to support the general and 
administrative functions of the taxpayer.
    (vii) High threshold of innovation test--(A) In general. Software 
satisfies this paragraph (c)(6)(vii) only if the taxpayer can establish 
that--
    (1) The software is innovative;
    (2) The software development involves significant economic risk; 
and
    (3) 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 requirements of paragraphs (c)(6)(vii)(A)(1) and (2) of 
this section.
    (B) 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.
    (C) 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. 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, as defined in paragraph (a)(4) of this section, and substantial 
uncertainty must exist at the beginning of the taxpayer's activities.
    (D) Application of high threshold of innovation test. The high 
threshold of innovation test of paragraph (c)(6)(vii) of this section 
takes into account only the results anticipated to be attributable to 
the development of new or improved software at the beginning of the 
software development independent of the effect of any modifications to 
related hardware or other software. The implementation of existing 
technology by itself is not evidence of innovation, but the use of 
existing technology in new ways could be evidence of a high threshold 
of innovation if it resolves substantial uncertainty as defined in 
paragraph (c)(6)(vii)(C) of this section.
    (viii) Illustrations. The following examples illustrate provisions 
contained in this paragraph (c)(6). No inference should be drawn from 
these examples concerning the application of section 41(d)(1) and 
paragraph (a) of this section to these facts.

    Example 1.  Computer hardware and software developed as a single 
product--(i) Facts. X is a telecommunications company that developed 
high technology telephone switching hardware. In addition, X 
developed software that interfaces directly with the hardware to 
initiate and terminate a call, along with other functions. X 
designed and developed the hardware and software together.
    (ii) Conclusion. The telecommunications software that interfaces 
directly with the hardware is part of a package of software and 
hardware developed together by the taxpayer that is used by the 
taxpayer in providing services in its trade or business. 
Accordingly, this paragraph (c)(6) does not apply to the software 
that interfaces directly with the hardware as described in paragraph 
(c)(6)(ii)(C) of this section, and eligibility for the research 
credit is determined by examining the combined software-hardware 
product as a single product.
    Example 2.  Internal use software; financial management--(i) 
Facts. X, a manufacturer, self-insures its liabilities for employee 
health benefits. X develops its own software to administer its self-
insurance reserves related to employee health benefits. At the 
beginning of the development, X does not intend to develop the 
software for commercial sale, lease, license, or to be otherwise 
marketed to third parties or to enable X to interact with third 
parties or to allow third parties to initiate functions or review 
data on X's system.
    (ii) Conclusion. The software is developed for use in a general 
and administrative function because reserve valuation is a financial 
management function under paragraph (c)(6)(iii)(B)(1) of this 
section. Accordingly, the software is internal use software because 
it is developed for use in a general and administrative function.
    Example 3.  Internal use software; human resources management--
(i) Facts. X, a manufacturer, develops a software module that 
interacts with X's existing payroll software to allow X's employees 
to print pay stubs and make certain changes related to payroll 
deductions over the internet. At the beginning of the development, X 
does not intend to develop the software module for commercial sale, 
lease, license, or to be otherwise marketed to third parties or to 
enable X to interact with third parties or to allow third parties to 
initiate functions or review data on X's system.
    (ii) Conclusion. The employee access software module is 
developed for use in a general and administrative function because 
employee access software is a human resources management function 
under paragraph (c)(6)(iii)(B)(2) of this section. Accordingly, the 
software module is internal use software because it is developed for 
use in a general and administrative function.
    Example 4.  Internal use software; support services--(i) Facts. 
X, a restaurant, develops software for a Web site that provides 
information, such as items served, price, location, phone number, 
and hours of operation for purposes of advertising. At the beginning 
of the development, X does not intend to develop the Web site 
software for commercial sale, lease, license, or to be otherwise 
marketed to third parties or to enable X to interact with third 
parties or to allow third parties to initiate functions or review 
data on X's system. X intends to use the software for marketing by 
allowing third parties to review general information on X's Web 
site.
    (ii) Conclusion. The software is developed for use in a general 
and administrative function because the software was developed to be 
used by X for marketing which is a support services function under 
paragraph (c)(6)(iii)(B)(3) of this section. Accordingly, the 
software is internal use software because it is developed for use in 
a general and administrative function.
    Example 5.  Internal use software--(i) Facts. X, a multinational 
manufacturer with different business and financial systems in each 
of its divisions, undertakes a software development project aimed at 
integrating the majority of the functional areas of its major 
software systems (Existing Software) into a single enterprise 
resource management system supporting centralized financial systems, 
human resources, inventory, and sales. X purchases software (New 
Software) upon which to base its enterprise-wide system. X has to 
develop software (Developed Software) that transfers data from

[[Page 68310]]

X's legacy financial, human resources, inventory, and sales systems 
to the New Software. At the beginning of the development, X does not 
intend to develop the software for commercial sale, lease, license, 
or to be otherwise marketed to third parties or to enable X to 
interact with third parties or to allow third parties to initiate 
functions or review data on X's system.
    (ii) Conclusion. The financial systems, human resource systems, 
inventory and sales systems are general and administrative functions 
under paragraph (c)(6)(iii)(B) of this section. Accordingly, the 
Developed Software is internal use software because it is developed 
for use in general and administrative functions.
    Example 6.  Internal use software; definition of third party--
(i) Facts. X develops software to interact electronically with its 
vendors to improve X's inventory management. X develops the software 
to enable X to interact with vendors and to allow vendors to 
initiate functions or review data on the taxpayer's system. X 
defines the electronic messages that will be exchanged between X and 
the vendors. X's software allows a vendor to request X's current 
inventory of the vendor's product, and allows a vendor to send a 
message to X which informs X that the vendor has just made a new 
shipment of the vendor's product to replenish X's inventory. At the 
beginning of development, X does not intend to develop the software 
for commercial sale, lease, license, or to be otherwise marketed to 
third parties.
    (ii) Conclusion. Under paragraph (c)(6)(vi)(E) of this section, 
X's vendors are not third parties for purposes of paragraph 
(c)(6)(iv) of this section. While X's software was developed to 
allow vendors to initiate functions or review data on the taxpayer's 
system, the software is not excluded from internal use software as 
set forth in paragraph (c)(6)(iv)(B) of this section because the 
software was developed to allow vendors to use the software to 
support X's inventory management, which is a general and 
administrative function of X.
    Example 7.  Not internal use software; third party interaction--
(i) Facts. X, a manufacturer of various products, develops software 
for a Web site with the intent to allow third parties to access data 
on X's database, to order X's products and track the status of their 
orders online. At the beginning of the development, X does not 
intend to develop the Web site software for commercial sale, lease, 
license, or to be otherwise marketed to third parties.
    (ii) Conclusion. The software is not developed primarily for 
internal use because it is not developed for use in a general and 
administrative function. X developed the software to allow third 
parties to initiate functions or review data on the taxpayer's 
system as provided under paragraph (c)(6)(iv)(B) of this section.
    Example 8.  Not internal use software; third party interaction--
(i) Facts. X developed software that allows its users to upload and 
modify photographs at no charge. X earns revenue by selling 
advertisements that are displayed while users enjoy the software 
that X offers for free. X also developed software that has 
interfaces through which advertisers can bid for the best position 
in placing their ads, set prices for the ads, or develop 
advertisement campaign budgets. At the beginning of the development, 
X intended to develop the software to enable X to interact with 
third parties or to allow third parties to initiate functions on X's 
system.
    (ii) Conclusion. The software for uploading and modifying 
photographs is not developed primarily for internal use because it 
is not developed for use in X's general and administrative functions 
under paragraph (c)(6)(iii)(A) of this section. The users and the 
advertisers are third parties for purposes of paragraph (c)(6)(iv) 
of this section. Furthermore, both the software for uploading and 
modifying photographs and the advertising software are not internal 
use software under paragraph (c)(6)(iv)(B) of this section because 
at the beginning of the development X developed the software with 
the intention of enabling X to interact with third parties or to 
allow third parties to initiate functions on X's system.
    Example 9.  Not internal use software; commercially sold, 
leased, licensed, or otherwise marketed--(i) Facts. X is a provider 
of cloud-based software. X develops enterprise application software 
(including customer relationship management, sales automation, and 
accounting software) to be accessed online and used by X's 
customers. At the beginning of development, X intended to develop 
the software for commercial sale, lease, license, or to be otherwise 
marketed to third parties.
    (ii) Conclusion. The software is not developed primarily for 
internal use because it is not developed for use in a general and 
administrative function. X developed the software to be commercially 
sold, leased, licensed, or otherwise marketed to third parties under 
paragraph (c)(6)(iv)(A) of this section.
    Example 10.  Improvements to existing internal use software--(i) 
Facts. X has branches throughout the country and develops its own 
facilities services software to coordinate moves and to track 
maintenance requests for all locations. At the beginning of the 
development, X does not intend to develop the software for 
commercial sale, lease, license, or to be otherwise marketed to 
third parties or to enable X to interact with third parties or to 
allow third parties to initiate functions or review data on X's 
system. Several years after completing the development and using the 
software, X consults its business development department, which 
assesses the market for the software. X determines that the software 
could be sold at a profit if certain technical and functional 
enhancements are made. X develops the improvements to the software, 
and sells the improved software to third parties.
    (ii) Conclusion. Support services, which include facility 
services, are general and administrative functions under paragraph 
(c)(6)(iii)(B) of this section. Accordingly, the original software 
is developed for use in general and administrative functions and is, 
therefore, developed primarily for internal use. However, the 
improvements to the software are not developed primarily for 
internal use because the improved software was not developed for use 
in a general and administrative function. X developed the improved 
software to be commercially sold, leased, licensed, or otherwise 
marketed to third parties under paragraphs (c)(6)(iv)(A) and 
(c)(6)(v) of this section.
    Example 11.  Dual function software; identification of a third 
party subset--(i) Facts. X develops software for use in general and 
administrative functions that facilitate or support the conduct of 
X's trade or business and to allow third parties to initiate 
functions. X is able to identify a third party subset. X incurs 
$50,000 of research expenditures for the software, 50% of which is 
allocable to the third party subset.
    (ii) Conclusion. The software developed by X is dual function 
software. Because X is able to identify a third party subset, the 
third party subset is not presumed to be internal use software under 
paragraph (c)(6)(vi)(A) of this section. If X's research activities 
related to the third party subset constitute qualified research 
under section 41(d), and the allocable expenditures are qualified 
research expenditures under section 41(b), $25,000 of the software 
research expenditures allocable to the third party subset may be 
included in computing the amount of X's credit, pursuant to 
paragraph (c)(6)(vi)(B) of this section. If, after the application 
of paragraph (c)(6)(vi)(B) of this section, there remains a dual 
function subset, X may determine whether paragraph (c)(6)(vi)(C) of 
this section applies.
    Example 12.  Dual function software; application of the safe 
harbor--(i) Facts. The facts are the same as in Example 11, except 
that X is unable to identify a third party subset. X uses an 
objective, reasonable method at the beginning of the software 
development to determine that the dual function software's use by 
third parties to initiate functions is reasonably anticipated to 
constitute 15% of the dual function software's use.
    (ii) Conclusion. The software developed by X is dual function 
software. The software is presumed to be developed primarily for 
internal use under paragraph (c)(6)(vi)(A) of this section. Although 
X is unable to identify a third party subset, X reasonably 
anticipates that the dual function software's use by third parties 
will be at least 10% of the dual function software's use. If X's 
research activities related to the development or improvement of the 
dual function software constitute qualified research under section 
41(d), without regard to section 41(d)(4)(E), and the allocable 
expenditures are qualified research expenditures under section 
41(b), X may include $12,500 (25% of $50,000) of the software 
research expenditures of the dual function software in computing the 
amount of X's credit pursuant to paragraph (c)(6)(vi)(C) of this 
section.
    Example 13.  Dual function software; safe harbor inapplicable--
(i) Facts. The facts are the same as in Example 11, except X is 
unable to identify a third party subset. X uses an objective, 
reasonable method at the beginning of the software development to 
determine that the dual function software's use by third parties to 
initiate functions is reasonably anticipated to constitute 5% of the 
dual function software's use.

[[Page 68311]]

    (ii) Conclusion. The software developed by X is dual function 
software. The software is presumed to be developed primarily for X's 
internal use under paragraph (c)(6)(vi)(A) of this section. X is 
unable to identify a third party subset, and X reasonably 
anticipates that the dual function software's use by third parties 
will be less than 10% of the dual function software's use. X may 
only include the software research expenditures of the dual function 
software in computing the amount of X's credit if the software 
satisfies the high threshold of innovation test of paragraph 
(c)(6)(vii) of this section and X's research activities related to 
the development or improvement of the dual function software 
constitute qualified research under section 41(d), without regard to 
section 41(d)(4)(E), and the allocable expenditures are qualified 
research expenditures under section 41(b).
    Example 14.  Dual function software; identification of a third 
party subset and the safe harbor--(i) Facts. X develops software for 
use in general and administrative functions that facilitate or 
support the conduct of X's trade or business and to allow third 
parties to initiate functions and review data. X is able to identify 
a third party subset (Subset A). The remaining dual function subset 
of the software (Subset B) allows third parties to review data and 
provides X with data used in its general and administrative 
functions. X is unable to identify a third party subset of Subset B. 
X incurs $50,000 of research expenditures for the software, 50% of 
which is allocable to Subset A and 50% of which is allocable to 
Subset B. X determines, at the beginning of the software 
development, that the processing time of the third party use of 
Subset B is reasonably anticipated to account for 15% of the total 
processing time of Subset B.
    (ii) Conclusion. The software developed by X is dual function 
software. Because X is able to identify a third party subset, such 
third party subset (Subset A) is not presumed to be internal use 
software under paragraph (c)(6)(vi)(A) of this section. If X's 
research activities related to the development or improvement of 
Subset A constitute qualified research under section 41(d), and the 
allocable expenditures are qualified research expenditures under 
section 41(b), the $25,000 of the software research expenditures 
allocable to Subset A may be included in computing the amount of X's 
credit pursuant to paragraph (c)(6)(vi)(B) of this section. Although 
X is unable to identify a third party subset of Subset B, 15% of 
Subset B's use is reasonably anticipated to be attributable to the 
use of Subset B by third parties. If X's research activities related 
to the development or improvement of Subset B constitute qualified 
research under section 41(d), without regard to section 41(d)(4)(E), 
and the allocable expenditures are qualified research expenditures 
under 41(b), X may include $6,250 (25% x $25,000) of the software 
research expenditures of Subset B in computing the amount of X's 
credit, pursuant to paragraph (c)(6)(vi)(C) of this section.
    Example 15.  Internal use software; application of the high 
threshold of innovation test--(i) Facts. X maintained separate 
software applications for tracking a variety of human resource (HR) 
functions, including employee reviews, salary information, location 
within the hierarchy and physical location of employees, 401(k) 
plans, and insurance coverage information. X determined that 
improved HR efficiency could be achieved by redesigning its 
disparate software applications into one employee-centric system, 
and worked to develop that system. X also determined that 
commercially available database management systems did not meet all 
of the requirements of the proposed system. Rather than waiting 
several years for vendor offerings to mature and become viable for 
its purpose, X embarked upon the project utilizing older technology 
that was severely challenged with respect to data modeling 
capabilities. The improvements, if successful, would provide a 
reduction in cost and improvement in speed that is substantial and 
economically significant. For example, having one employee-centric 
system would remove the duplicative time and cost of manually 
entering basic employee information separately in each application 
because the information would only have to be entered once to be 
available across all applications. The limitations of the technology 
X was attempting to utilize required that X attempt to develop a new 
database architecture. X committed substantial resources to the 
project, but could not predict, because of technical risk, whether 
it could develop the database software in the timeframe necessary so 
that X could recover its resources in a reasonable period. 
Specifically, X was uncertain regarding the capability of 
developing, within a reasonable period, a new database architecture 
using the old technology that would resolve its technological issues 
regarding the data modeling capabilities and the integration of the 
disparate systems into one system. At the beginning of the 
development, X did not intend to develop the software for commercial 
sale, lease, license, or to be otherwise marketed to third parties 
or to enable X to interact with third parties or to allow third 
parties to initiate functions or review data on X's system.
    (ii) Conclusion. The software is internal use software because 
it is developed for use in a general and administrative function. 
However, the software satisfies the high threshold of innovation 
test set forth in paragraph (c)(6)(vii) of this section. The 
software was intended to be innovative in that it would provide a 
reduction in cost or improvement in speed that is substantial and 
economically significant. In addition, X's development activities 
involved significant economic risk in that X committed substantial 
resources to the development and there was substantial uncertainty, 
because of technical risk, that the resources would be recovered 
within a reasonable period. Finally, at the time X undertook the 
development of the system, software meeting X's requirements was not 
commercially available for use by X.
    Example 16.  Internal use software; application of the high 
threshold of innovation test--(i) Facts. X undertook a software 
project to rewrite a legacy mainframe application using an object-
oriented programming language, and to move the new application off 
the mainframe to a client/server environment. Both the object-
oriented language and client/server technologies were new to X. This 
project was undertaken to develop a more maintainable application, 
which X expected would significantly reduce the cost of maintenance, 
and implement new features more quickly, which X expected would 
provide both significant improvements in speed and reduction in 
cost. Thus, the improvements, if successful, would provide a 
reduction in cost and improvement in speed that is substantial and 
economically significant. X also determined that commercially 
available systems did not meet the requirements of the proposed 
system. X was certain that it would be able to overcome any 
technological uncertainties and implement the improvements within a 
reasonable period. However, X was unsure of the appropriate 
methodology to achieve the improvements. At the beginning of the 
development, X does not intend to develop the software for 
commercial sale, lease, license, or to be otherwise marketed to 
third parties or to enable X to interact with third parties or to 
allow third parties to initiate functions or review data on X's 
system.
    (ii) Conclusion. The software is internal use software because 
it is developed for use in a general and administrative function. 
X's activities do not satisfy the high threshold of innovation test 
of paragraph (c)(6)(vii) of this section. Although the software 
meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of 
this section, X's development activities did not involve significant 
economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X 
did not have substantial uncertainty, because of technical risk, 
that the resources committed to the project would be recovered 
within a reasonable period.
    Example 17.  Internal use software; application of the high 
threshold of innovation test--(i) Facts. X wants to expand its 
internal computing power, and is aware that its PCs and workstations 
are idle at night, on the weekends, and for a significant part of 
any business day. Because the general and administrative 
computations that X needs to make could be done on workstations as 
well as PCs, X develops a screen-saver-like application that runs on 
employee computers. When employees' computers have been idle for an 
amount of time set by each employee, X's application goes back to a 
central server to get a new job to execute. This job will execute on 
the idle employee's computer until it has either finished, or the 
employee resumes working on his computer. The ability to use the 
idle employee's computers would save X significant costs because X 
would not have to buy new hardware to expand the computing power. 
The improvements, if successful, would provide a reduction in cost 
that is substantial and economically significant. At the time X 
undertook the software development project, there was no commercial 
application available with such a capability. In addition, at the 
time X undertook the software development project, X was uncertain 
regarding the capability of developing a server application that 
could schedule and

[[Page 68312]]

distribute the jobs across thousands of PCs and workstations, as 
well as handle all the error conditions that occur on a user's 
machine. X commits substantial resources to the project. X 
undertakes a process of experimentation to attempt to eliminate its 
uncertainty. At the beginning of the development, X does not intend 
to develop the software for commercial sale, lease, license, or to 
be otherwise marketed to third parties or to enable X to interact 
with third parties or to allow third parties to initiate functions 
or review data on X's system.
    (ii) Conclusion. The software is internal use software because 
it is developed for use in a general and administrative function. 
However, the software satisfies the high threshold of innovation 
test as set forth in paragraph (c)(6)(vii) of this section. The 
software was intended to be innovative because it would provide a 
reduction in cost or improvement in speed that is substantial and 
economically significant. In addition, X's development activities 
involved significant economic risk in that X committed substantial 
resources to the development and there was substantial uncertainty 
that because of technical risk, such resources would be recovered 
within a reasonable period. Finally, at the time X undertook the 
development of the system, software meeting X's requirements was not 
commercially available for use by X.
    Example 18.  Internal use software; application of the high 
threshold of innovation test--(i) Facts. X, a multinational 
manufacturer, wants to install an enterprise resource planning (ERP) 
system that runs off a single database. However, to implement the 
ERP system, X determines that it must integrate part of its old 
system with the new because the ERP system does not have a 
particular function that X requires for its business. The two 
systems are general and administrative software systems. The systems 
have mutual incompatibilities. The integration, if successful, would 
provide a reduction in cost and improvement in speed that is 
substantial and economically significant. At the time X undertook 
this project, there was no commercial application available with 
such a capability. X is uncertain regarding the appropriate design 
of the interface software. However, X knows that given a reasonable 
period of time to experiment with various designs, X would be able 
to determine the appropriate design necessary to meet X's technical 
requirements and would recover the substantial resources that X 
commits to the development of the system within a reasonable period. 
At the beginning of the development, X does not intend to develop 
the software for commercial sale, lease, license, or to be otherwise 
marketed to third parties or to enable X to interact with third 
parties or to allow third parties to initiate functions or review 
data on X's system.
    (ii) Conclusion. The software is internal use software because 
it is developed for use in a general and administrative function. 
X's activities do not satisfy the high threshold of innovation test 
of paragraph (c)(6)(vii) of this section. Although the software 
meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of 
this section, X's development activities did not involve significant 
economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X 
did not have substantial uncertainty, because of technical risk, 
that the resources committed to the project would be recovered 
within a reasonable period.
* * * * *
    (e) Effective/applicability dates. Other than paragraph (c)(6) of 
this section, this section is applicable for taxable years ending on or 
after December 31, 2003. Paragraph (c)(6) of this section is applicable 
for taxable years beginning on or after October 4, 2016. For any 
taxable year that both ends on or after January 20, 2015 and begins 
before October 4, 2016, the IRS will not challenge return positions 
consistent with all of paragraph (c)(6) of this section or all of 
paragraph (c)(6) of this section as contained in the Internal Revenue 
Bulletin (IRB) 2015-5 (see www.irs.gov/pub/irs-irbs/irb15-05.pdf). For 
taxable years ending before January 20, 2015, taxpayers may choose to 
follow either all of Sec.  1.41-4(c)(6) as contained in 26 CFR part 1 
(revised as of April 1, 2003) and IRB 2001-5 (see www.irs.gov/pub/irs-irbs/irb01-05.pdf) or all of Sec.  1.41-4(c)(6) as contained in IRB 
2002-4 (see www.irs.gov/pub/irs-irbs/irb02-04.pdf).

 John Dalrymple,
Deputy Commissioner for Services and Enforcement.
    Approved: August 22, 2016.
 Mark J. Mazur
 Assistant Secretary of the Treasury (Tax Policy).
[FR Doc. 2016-23174 Filed 10-3-16; 8:45 am]
 BILLING CODE 4830-01-P