The federal research tax credit is a well-established planning tool that in the authors' experience is often one of the largest tax incentives available to U.S. companies engaging in product development, manufacturing, and process technology. Companies annually reduce federal and, in many cases, state tax liability by the costs incurred to develop or improve products, processes, and software.
However, financial institutions and other providers of financial services delivered or facilitated through software platforms and web-based programs have historically underused the research credit. Part of the reason for this is that whether software developed for internal business use or for interaction with customers is eligible for the credit has been a highly contested IRS issue. Previously, the uncertainty in this area could be blamed on a lack of clear guidance and inconsistent IRS regulations and administration.
Hence, financial service companies that have invested in technology focused on unique financial modeling and enterprise tools, data security mechanisms, and diverse modules developed to provide improved services to customers have routinely failed to include those costs in calculating their research credit. In many instances, these organizations missed the opportunity altogether to claim the research credit.
On Oct. 3, 2016, the IRS issued final regulations on the treatment of internal-use software for purposes of calculating the research credit (T.D. 9786). The final regulations largely mirror the taxpayer-friendly proposed regulations (REG-153656-03) issued in 2015 with some changes.
Because of the new regulations, service-based companies investing in technology now have support for the position that those costs are eligible for the research credit. This development is especially important for financial services companies but applies to all companies using technology to provide services that rely on data collection and analytics, and any company that has invested in technology to increase operational speed or efficiency, or to reduce cost.
The proposed and final regulations focus heavily on whether a software program qualifies as internal-use software. Both internal-use software and non-internal-use software are eligible for the research credit, but internal-use software requires a heightened level of innovation and risk to qualify.
The new regulations further expand and clarify the types of software that fall outside of the higher-scrutiny internal-use category, which significantly enhances the ability of U.S. companies to include technology development programs in their research credit calculations. Nonetheless, taxpayers must provide documentation to prove their programs qualify.
One final note: Whether software is developed for internal use or some other purpose, costs for programs or projects that did not succeed may qualify for the research credit. As is true for all research credit costs, failed or partially failed projects are often rife with eligible research credit costs.
Following is a summary of the major clarifications, changes, and new definitions introduced by the 2015 proposed regulations, along with additional changes contained in the 2016 final regulations.
DEFINITION OF INTERNAL-USE SOFTWARE
Proposed regulations
Software is developed by (or for the benefit of) the taxpayer primarily for 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.
General and administrative functions are further defined as:
- Financial management functions: Programs involving the taxpayer's financial management and supporting recordkeeping.
- Human resource management functions: Programs developed to manage the taxpayer's workforce.
- Support services functions: Software developed to support the taxpayer's day-to-day operations, such as data processing or facilities services.
Final regulations
The final regulations adopted the proposed regulations discussed above defining administrative and management functions software, which does not qualify for the credit, without significant changes.
SOFTWARE THAT IS NOT INTERNAL-USE SOFTWARE
Proposed regulations
Software is not developed primarily for internal use if it is developed only 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.
Final regulations
The final regulations expand the definition of software not classified as internal-use software by including a catchall exclusion: Software is not developed primarily for the taxpayer's internal use and therefore may qualify for the research credit 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.
To further clarify the software uses falling outside of a purely "back office" function, the final regulations noted again that general and administrative functions are those providing support to a taxpayer's day-to-day operations in carrying on business regardless of the taxpayer's industry. Benefits that these software programs provide to third parties are collateral and secondary to the internal function.
- Example: A financial services company investing in human resource administrative software widely used in a variety of industries to track employee attendance would be evaluated differently than a financial services company investing in unique human resource software that gathers time data associated with various customer service activities to evaluate the efficiency of customer service phone lines and customer satisfaction. The former is software used for a function (attendance) required regardless of the industry, whereas the latter represents a program that extends beyond general and administrative functions and enables enhanced services to the company's customers.Further, 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.
- No physical transfer requirement: The final regulations added an example to clarify that "software that is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties," and thus is not internal-use software, may include hosted software and other software even if there is no transfer of a copy of the software.
TAXPAYER INTENT AND THE FACTS-AND-CIRCUMSTANCES TEST
Proposed regulations
Whether software is developed primarily for internal use depends on the taxpayer's intent and the facts and circumstances at the beginning of the software development project, program, task, or activity.
If a taxpayer originally develops software primarily for internal use but later makes improvements to the software with the intent to externally market the improved software, 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 but later makes improvements to the software with the intent to use it in general and administrative functions, the improvements will be considered separate from the existing software and will be considered developed primarily for internal use.
Final regulations
The final regulations adopted the proposed regulations without substantive change.
DUAL-FUNCTION SOFTWARE
Proposed regulations
The proposed regulations introduced the concept of "dual function software" as a solution to instances where software developed by a taxpayer is used both internally and externally.
When a taxpayer creates software for both internal and external use, the 2015 proposed regulations created a presumption that the taxpayer developed the dual-function software primarily for the taxpayer's internal use.
However, this presumption does not apply to the extent that a taxpayer can identify a subset of elements of dual-function software that is not internal-use software, but rather 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). If the taxpayer can identify a third-party subset of the overall program, the portion of qualified research expenditures allocable to the development of that particular subset, module, or function is not subject to the internal-use software rules.
Final regulations
The final regulations adopted the proposed regulations without change.
DUAL-FUNCTION SOFTWARE SAFE HARBOR
Proposed regulations
The proposed regulations provided taxpayers with a safe harbor to apply to modules or functions within dual-function software remaining after identifying the third-party functions. The safe harbor allows a taxpayer to include 25% of the qualified research expenditures of the dual-function subset in computing the amount of the taxpayer's credit. To meet this safe harbor, the dual-function subset must constitute qualified research, and the use of the dual-function subset by third parties or by the taxpayer to interact with third parties must be reasonably anticipated to constitute at least 10% of the dual-function subset's use.
Final regulations
The final regulations adopted the safe harbor in the proposed regulations but modified it to clarify that the safe harbor can be applied to the dual-function software or the dual-function subset after the application of Regs. Sec. 1.41-4(c)(6)(vi)(B).
DEFINITION OF THIRD PARTY
Proposed regulations
"Third party" is defined to include any corporation, trade or business, or other person not related to the taxpayer, other than persons using the software to support the taxpayer's general and administrative functions in operating the taxpayer's trade or business. This definition is intended to classify software developed for interaction with vendors as non-internal-use software.
Final regulations
The final regulations adopted the proposed regulations' definition of "third party" without change.
HIGH THRESHOLD OF INNOVATION: SIGNIFICANT ECONOMIC RISK
Proposed regulations
Internal-use software is eligible for the research credit if it satisfies the high-threshold-of-innovation test. The high-threshold-of-innovation test consists of three parts:
- The software is innovative in that it 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;
- Developing the software involves significant economic risk in that the taxpayer commits substantial resources to its development and there is a substantial uncertainty, because of technical risk, that those resources would be recovered within a reasonable period; and
- The software is not commercially available for use by the taxpayer in that it 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 required that substantial uncertainty exists only 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.
Final regulations
The final regulations retain the three-part high-threshold-of-innovation test but clarify that taxpayers can establish substantial uncertainty through design uncertainty, that a "revolutionary discovery" is not required to meet the high-threshold-of-innovation test, and that the test does not apply to certain types of software.
- Design uncertainty: In what is potentially the most significant change from the proposed regulations, the final regulations remove the references to capability and method uncertainty, clarifying that substantial uncertainty can be established by demonstrating capability, method, or design uncertainty in developing or improving the software. This new more expanded definition is critical, as design uncertainty is a more reasonable standard to meet in the context of software development. However, the preamble to the final regulations states that the IRS believes "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."
- Revolutionary discovery not required: The proposed regulations also contained a statement that "[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 final regulations removed this statement to clarify that a revolutionary discovery is not required to meet the high-threshold-of-innovation test.
- Affirmation of historical internal-use software exclusions: The final regulations revised language to clarify that the high-threshold-of-innovation test does not apply to three additional types of software:
- Software developed for use in an activity that constitutes qualified research;
- Software developed for use in a production process for which the Sec. 41(d)(1) requirements are met; and
- A new or improved package of software and hardware that the taxpayer developed together as a single product.
EFFECTIVE DATE
The final regulations apply to tax years beginning on or after Oct. 4, 2016, the date they were published in the Federal Register. However, the IRS will not challenge any return that is consistent with the regulations for tax years ending on or after Jan. 20, 2015, and beginning before Oct. 4, 2016.
About the authors
Ellen E. Ernst (eernst@howardandhoward.com), Zachary J. Hendricks (zhendricks@howardandhoward.com), and Gina Staudacher (gstaudacher@howardandhoward.com) advise clients on corporate taxation with emphases on accounting methods, IRS controversy, international incentives, global research tax credits, and fixed assets for the Howard & Howard Law Firm. Ernst and Hendricks practice at the Chicago office, while Staudacher practices out of the Royal Oaks, Mich., office.
To comment on this article or to suggest an idea for another article, contact Sally P. Schreiber, senior editor, at Sally.Schreiber@aicpa-cima.com or 919-402-4828.
AICPA resources
Article
- "IRS Issues Reasonable Internal-Use Software Regulations for the Research Tax Credit," The Tax Adviser, April 2017
