With the issuance of Treasury Decision (TD) 9786 on October 4, 2016, taxpayers at long last have the final internal use software (IUS) regulations that they have so patiently awaited since 1986. Consistent with proposed regulations issued in early 2015, the final IUS regulations broaden the scope of software development activities that are eligible under the general definition of R&D. The following discussion summarizes the major features of the final regulations and highlights how taxpayers can take advantage of the revised guidance to strengthen their R&D credit documentation. 

IUS Background

As we pointed out in Tax Advisor Weekly 2015 – Issue 4 (February 24, 2015), the road to final IUS regulations has been a long and winding one, with numerous twists, turns and dead ends. The Tax Reform Act of 1986 established that software developed primarily for a taxpayer’s “internal use” must meet a higher threshold to qualify for the Internal Revenue Code (IRC) Section 41 research credit. However, no clear guidance has been available to establish the definition of IUS or to determine what the higher threshold entailed. IUS issues have been particularly confusing over the last 15 years, as taxpayers have been forced to choose between a set of final regulations issued in 2001 (TD 8930), which were later withdrawn, and a set of proposed regulations that reserved the IUS section for future guidance. This future guidance was finally provided on January 20, 2015, when proposed IUS regulations were issued (REG-153656-03) and taxpayers were given a new set of IUS concepts by Treasury and the IRS.

By and large, the 2015 proposed regulations were considered a favorable development. As we discussed in Tax Advisor Weekly 2015 – Issue 4, the proposed IUS regulations contained new provisions regarding what constitutes IUS, introduced the concepts of “dual function software,” “third party interaction” and “third party subset,” and made significant changes to the IUS “high threshold of innovation” three-part test. Though it’s been 18 months since taxpayer comments were gathered and a public hearing was held regarding the proposed regulations, somewhat surprisingly, the final regulations remained substantially the same as what was initially proposed.

Final IUS Regulations Highlights and Their Effect on Taxpayers

What Is IUS?

The final regulations state 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.” The regulations assign general and administrative functions to three broad categories:

• Financial management: functions involving a taxpayer’s financial management and supporting recordkeeping. Specific examples include “accounts payable, accounts receivable, inventory management… disbursements… finance… and tax.”
• Human resource management: functions that include activities “that manage the taxpayer’s workforce.”
• Support services: functions that “support the day-to-day operations of the taxpayer,” such as “data processing… marketing… and government compliance services.”

These categories provide a broad definition of “general and administrative” functions and could actually expand the types of software classified as IUS. We continue to believe this is especially so for some of the specific areas included in the three categories of general and administrative functions, such as “inventory management.” However, the preamble to the final regulations states that the new dual function rules will allow “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.” As we discuss below, these third party software subsets are not subject to the more restrictive IUS rules and may offset the broad definition of general and administrative functions.

Importantly, the final regulations also clarify the types of software that are not primarily developed for internal use. The final regulations provide 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. (emphasis added)

Thus, under the final IUS regulations, there are now four types of software for Section 41 tax credit purposes. All four types can qualify for the research credit if they satisfy the appropriate requirements:

1. IUS: software developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. IUS is subject to the high threshold of innovation three-part test in addition to the research credit’s four-part test under Section 41.
2. Third party interaction software: software that enables a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system. Third party interaction software is not IUS and is only subject to the Section 41 four-part test.
3. Dual function software: general and administrative software that has subsets which include both IUS and non-IUS third party interaction software.
4. Software developed for sale, lease, license, or otherwise marketed to third parties. Software developed to be sold, leased, licensed or otherwise marketed to third parties is not IUS and is only subject to the general Section 41 four-part test.

What Are Dual Function Software and a Third Party Subset?

The dual function software provisions give taxpayers the ability to bifurcate software development activities between IUS and non-IUS. Prior to the 2015 proposed regulations, the entire “mixed” software development activity would have been treated as IUS. This is important in today’s business environment because very few software systems operate on a standalone basis.

Although the dual function software concept is a welcome addition to the IUS regulations because it should allow more taxpayers to take advantage of the research credit, it will also require taxpayers to think of new ways to document and analyze their software development projects and expenses. In particular, the dual function software concept requires a broad understanding of software system components and the intended use of those components.

The final regulations acknowledge that instances may occur where a taxpayer develops software with a general and administrative function that also enables the taxpayer to interact with third parties:

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. (emphasis added)

As a first step in documenting software development activities, taxpayers should now separate software development efforts into one of the four software types outlined above (IUS, third party interaction, dual function, or for sale). The dual function software must then be further broken down into general and administrative and third party interaction subsets. The third party interaction subset is presumed not to be IUS and is only subject to the general Section 41 four-part test. The general and administrative subset must be further evaluated to determine whether the additional three-part high threshold of innovation test is appropriate or if the taxpayer may take advantage of a new safe harbor provision.

The safe harbor provision applies to the general and administrative subset of dual function software. Under the safe harbor rules, if, at the outset of development, a taxpayer reasonably anticipates that at least 10 percent of the overall use of the general and administrative subset will enable third party interaction, then the taxpayer may include 25 percent of the qualified research expenses of the dual function software in its research credit calculation, as long as the general Section 41 four-part test is satisfied.

For example, assume a taxpayer incurs $100,000 of QREs related to the development of a new marketing software system. A subset of the system development, which represents $30,000 of the QREs, is only used to enable third party interaction. If this third party subset satisfies the general Section 41 four-part test, then the $30,000 of QREs may be included in the taxpayer’s research credit calculation. If the remaining general and administrative development subset will be used at least 10 percent of time for third party interaction, then 25 percent of the remaining $70,000 of QREs, or $17,500, may be included as QREs in the taxpayer’s research credit calculation so long as the general and administrative subset satisfies the general Section 41 four-part test.

Taxpayers should also note that the final regulations retain the third party exception exclusion. The definition of a “third party” does not include “any persons that use the software to support the general and administrative functions of the taxpayer.” The preamble to the final regulations specifically states that this excludes a taxpayer’s vendors from the narrow definition of “third parties.” Thus, if your software falls into the general and administrative function category and only allows outside interaction with your vendors, it is not third party interaction software and you must satisfy the high threshold of innovation test in order for such software to qualify for the research credit.

To qualify certain elements of general and administrative software development efforts under the dual function software rules, taxpayers should begin tracking the “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)” (emphasis added). The final regulations provide that taxpayers may use “any objective, reasonable method within the taxpayer’s industry” (such as processing time, amount of data transfer, and number of software user interface screens) to estimate the dual function software’s use by third parties.

Also important for taxpayers to note, the final regulations provide that whether software is developed primarily for internal use and the determination of the third party subset both depend on the intent of the taxpayer and the facts and circumstances at the beginning of the software development effort. However, the final regulations do provide that:

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.

Thus, taxpayers should clearly document the purpose of their software development activities at the outset and also document any improvements made to software that could allow it to be categorized as non-IUS. Taxpayers should use an objective, reasonable method to determine the third party subset and for any dual function software.

Has the IUS High Threshold of Innovation Test Changed?

The final regulations also refine certain aspects of the high threshold of innovation test. Under the final regulations, the high threshold of innovation test requires that taxpayers establish that the software development:

(1) Is innovative;

(2) Involves significant economic risk; and

(3) 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 (1) and (2) of this section.

The innovative and the significant economic risk prongs of the high threshold of innovation test remain unchanged from the proposed regulations. Both of these tests are consistent with the legislative history.

However, in what is perhaps the biggest change to the proposed regulations, the final regulations have substantially backtracked on changes made to the significant economic risk prong of the high threshold of innovation test. Under the 2015 proposed IUS regulations, “design uncertainty” was deemed to no longer establish acceptable levels of “substantial uncertainty” for meeting the significant economic risk test. “Capability” and “method” uncertainties were the only types of uncertainty that would satisfy this requirement.

The final regulations concede that design, capability and method uncertainty are inherently related and not clearly defined by the IRC or regulations. Unfortunately, rather than taking this opportunity to provide clear definitions for each type of uncertainty, Treasury only removed the capability and methodology limit from the final regulations. Additionally, the preamble to the final regulations states that Treasury and the IRS still doubt that design uncertainty alone would ever satisfy the substantial uncertainty threshold:

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

The preamble language may raise questions with the IRS going forward if only design uncertainty is identified by taxpayers documenting the high threshold of innovation requirements.

When Do These Final IUS Regulations Take Effect?

The application of the final IUS regulations are prospective only and will apply to those taxable years beginning on or after the date of publication of TD 9786 in the Federal Register (October 4, 2016). This will be a disappointment to the many commentators who requested retroactive application of the regulations. The IRS will not challenge return positions consistent with the final or proposed regulations for any taxable year that both ends on or after January 20, 2015 (date the proposed regulations were published) and begins before October 4, 2016.

For years ending before January 20, 2015, taxpayers may continue to rely on the IUS rules in TD 8930 or in the proposed regulations published in December 2001. There are a broad range of IUS exceptions in the prior guidance that can still benefit taxpayers. The incremental nature of the research credit requires that taxpayers report qualified research expenses on a consistent basis, so software projects in the prior years must be evaluated under the standards applied in the final regulations. Therefore, taxpayers that must re-compute their base years should assess whether prior regulatory guidance may still allow claims for software in the earlier years.

Alvarez & Marsal Taxand Says:

The final IUS regulations are a welcome development for most taxpayers claiming software development expenses for the research credit. The final regulations take a more modern view of software development, which broadens the range of software systems that are likely to qualify. This broadening also brings more complexity and introduces new concepts, such as dual function software, third party subsets, and third party interactions, with which taxpayers will need to quickly become acquainted.

As year-end approaches for many taxpayers, the time is right to consider how the final regulations may impact your research credit opportunity. The following questions are a good starting point for your assessment:

1. Have you appropriately classified software as IUS or non-IUS based on the latest guidance (what software is for sale or used in providing a service, what are your general and administrative functions, etc.)?
2. Can you take advantage of the third party interaction exclusion or dual function software provisions?
3. Are there software development efforts that have been excluded from credit consideration that warrant further review?
4. Where are the externally focused software systems in your organization (hint: start by looking at your website and other external port facing systems or portals)?
5. Have you reviewed your current documentation to ensure that the most appropriate uncertainty standard and IUS exclusions have been identified and applied (hint: if it says design uncertainty, clarify what the technical team thinks that means)?
6. Are there prior-year opportunities to make claims based on the 2015 proposed regulations or prior regulatory exceptions (hint: does the third party interaction provision fall within the guidelines of the computer services or non-computer services exceptions in TD 8930)?

Contact our tax professionals if you would like to receive our “Are You Maximizing Your Research Tax Credit for Software Development?” checklist, which will help ensure that your organization is in a position to properly identify and claim qualifying software development research expenditures.