The “dual function software,” “third party subset” and “third party interaction” concepts will change how you classify and document software development activities under Section 41.

Recently we discussed the final internal use software (IUS) regulations issued by the Treasury Department. (See Tax Advisory Weekly 2016 – Issue 33 “It’s Time to Take a Closer Look at Your Software Development Activities.”) We pointed out that a number of new concepts were introduced with these regulations. Ideally, the regulations will allow taxpayers to claim a credit for a wider range of software development. However, to take advantage of the new regulations, you will need to become familiar with the specific concepts and their relationship to your own software development activities.

In this edition of Tax Advisor Weekly, we take a practical look at these new concepts — specifically the “dual function software,” “third party subset” and “third party interaction” concepts. Through specific examples, we demonstrate how the new IUS regulations will change the way you need to classify and document software development for your research credit.

The Final Regulations — What Is IUS and What Is Not?

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.”

The Final Regulations — Dual Function Software, Third Party Interaction and a Safe Harbor

Under the final IUS regulations, there are now four categories of software. All four types can qualify for the research credit if they satisfy their independent requirements. Specifically, these categories and requirements are as follows:

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 that include both IUS and third party interaction software (see requirements in #1 and #2 above).
4. Software developed for sale, lease, license, or otherwise marketed to third parties. It is not considered IUS and is only subject to the general Section 41 four-part test.

As a first step in documenting software development activities, you should now separate software development efforts into one of these four software categories. The dual function software must then be further broken down into general and administrative and third party interaction subsets.

A 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 a taxpayer may include 25 percent of the qualified research expenses of the general and administrative subset in its research credit calculation. Still, the Section 41 four-part test must be satisfied.

According to the final regulations, 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.”

To qualify certain elements of general and administrative software development efforts under the dual function software rules, taxpayers must be able to identify the third party interaction subset. 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 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 as well as the facts and circumstances at the beginning of the software development effort. However, the final regulations provide that a taxpayer that originally develops software primarily for internal use can later makes improvements to the software. These improvements are undertaken so that the software may be sold, leased, licensed, or otherwise marketed to third parties. In this instance, the improvements will be considered separate from the existing software and will not be considered developed primarily for internal use.

The Final Regulations — Some Examples

It is helpful to illustrate how these new IUS rules operate through specific examples. A thorough analysis is critical, as it will drive how you classify and document your software development activities. Let’s assume that you develop the following software business components and then examine how the final IUS regulations treat these software development activities:

1. FACTS: A web application is created which allows potential customers to review your products, pricing, office hours and locations, and provides directions to your retail locations. The software does not allow potential customers to initiate any transactions or communicate directly with you.
   
   ANALYSIS: According to the final IUS regulations, this category of software is internal use because it is purely marketing software that does not allow third parties to initiate functions. Marketing is defined in the final regulations as a general and administrative support service. This result seems confusing because of the “or review data on the taxpayer’s system” language in the final regulations definition of third party interaction. However, the preamble to the final regulations states that marketing applications are developed primarily for internal use and that any benefits such functions provide to third parties are collateral and secondary. Because this application is IUS under the final regulations, it would need to satisfy the additional three-part high threshold of innovation test to qualify for the research credit.
2. FACTS: An application is created which allows your vendors to access your inventory management system to track your current inventory of their product. Vendors can initiate replenishment orders and shipments of the product to your locations to maintain agreed-upon inventory levels.
   
   ANALYSIS: According to the final regulations, vendors are not third parties. Therefore, this application is IUS and must satisfy the additional three-part high threshold of innovation test to qualify for the research credit. Again, this result seems perplexing because we normally think of outside vendors as third parties. However, the final regulations classify inventory management software such as that described in this example as general and administrative financial management services. The preamble to the regulations states that vendors use such software to support the conduct of a taxpayer’s trade or business and any benefit to the vendors is collateral and secondary.
3. FACTS: A web-based application is created which allows customers to browse your products, initiate orders, track shipments, initiate returns and pay for orders.
   
   ANALYSIS: This software application is a classic example of third party software that enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer’s system. In other words, this is a software application that is part of your customer-facing “front office,” rather than your internal-facing “back office.” This software is not IUS and qualifies for the research credit so long as it satisfies the four-part test under Section 41. This type of software was historically characterized as IUS under previous IUS regulations and according to other published IRS guidance.
4. FACTS: A bank creates a web-based application that allows customers to check balances, transfer money, deposit checks and make other financial transactions. In addition, this software includes a “data mining” module. This data mining module is invisible to customers. It collects customer data, such as age, location, income, etc., to allow the bank to analyze how to better market to certain demographics and increase traffic on its web page. This overall application includes 75 user interface screens that customers proactively manipulate plus 25 user interface screens that are invisible to customers and are only related to the passive data mining functions. The total cost to develop this software is $100,000.
   
   ANALYSIS: This software application will most likely be characterized as dual function software. Such software is presumed to be developed primarily for a taxpayer’s internal use. This presumption is inapplicable to the extent that you can identify a subset 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 on the taxpayer’s system (third party subset).
   
   In this case, there is a third party subset that allows your customers to initiate orders, etc. The final regulations state that you should use any objective, reasonable method within your industry to estimate the dual function software’s use by third parties. These methods include processing time, amount of data transfer and number of software user interface screens. Here, 75 percent of the software’s user interface screens are related to third party interactions. Therefore, 75 percent of the cost to develop such software, or $75,000, would be considered non-IUS and is only subject to the four-part test of Section 41. The remaining 25 percent general and administrative subset can still qualify for the credit if the subset satisfies the high threshold of innovation requirements or if it satisfies the safe harbor contained in the final IUS regulations.
   
   To qualify for the safe harbor, you must demonstrate that you reasonably anticipate that at least 10 percent of the overall use of the general and administrative subset will enable third party interaction. In this instance, you must demonstrate that 3 of the data mining user interface screens (3 out of 25 = 12.5 percent) actually allow customers to complete another interaction with the software, such as providing appropriate payment or shipment details. If the answer is affirmative, you may include 25 percent of the qualified research expenses of the general and administrative subset software in your research credit calculation (that is, 25 percent of $25,000, or $6,250), as long as the general Section 41 four-part test is satisfied.
5. FACTS: A web-based application is created which allows customers to browse your products, track shipments, initiate returns and pay for orders. It also triggers automated replenishment messages to your vendors when product levels fall below certain pre-agreed levels and provides inventory metrics to your supply chain personnel.
   
   As with Example #4, this software application will most likely be characterized as dual function software. The portion of the application that allows customers to initiate actions is a third party subset, while the part that only allows vendors to replenish inventory is a general and administrative subset. The application is developed by a 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.
   
   Examples #4 and #5 also illustrate the need for you to educate your software development teams about these new rules so they can help you prepare documentation. The documentation should allow you to reasonably determine third party interaction and satisfy the requirements of the final IUS regulations. As with all research credit documentation, it should be prepared contemporaneously with the development activities in order to provide the greatest degree of accuracy and detail. This will help you withstand IRS scrutiny under exam.
6. FACTS: A cloud-based software application is created which includes enterprise application software (accounting, sales automation, etc.) that can be accessed online and used by your customers for a one-time or monthly fee.
   
   ANALYSIS: This software is not IUS because you developed it to be commercially sold, leased, licensed, or otherwise marketed to third parties. Although cloud-based applications may reside on your servers, your customers must still pay for online access, your data storage requirements and other features (such as report writing). Thus, cloud-based applications need only satisfy the four-part test of Section 41 to qualify for the research credit.
7. FACTS: Improvements to your present inventory tracking system are created which allow you to sell the application to third parties.
   
   ANALYSIS: Whether software is developed primarily for internal use and the determination of the third party subset both depend on the actual intent of the taxpayer and the facts and circumstances at the beginning of the software development effort. Thus, the initial development of the inventory tracking system in this example would be IUS. However, the final regulations acknowledge that if you originally develop software primarily for internal use but later make improvements to the software with the intent to hold the improved software to be sold, leased, licensed, or otherwise marketed to third parties, the improvements will be considered separate from the existing software. The improvements will not be considered developed primarily for internal use. Thus, your inventory tracking system improvements will qualify for the research credit if they satisfy the four-part test of Section 41. It is essential to coordinate with your business operations and engineering groups to understand and document their actual intent.

Alvarez & Marsal Taxand Says:

The third party interaction concept will broaden the types of software and amount of expenditures that will qualify for the research credit. Many software applications that will now satisfy the third party interaction requirements would have previously been classified as IUS under earlier IRS guidance. However, this broadening also includes additional complexity and introduces new concepts such as dual function software, third party subsets and third party interactions.

You will need to quickly become acquainted with how these new concepts operate, determine an appropriate methodology that will allow you to apply them to your particular software development activities and educate your software development teams so they can help you document qualifying activities. Your software development teams may also be helpful in developing an objective, reasonable method to estimate any dual function software’s use by third parties. Such methods will be based on technical aspects of the software, such as number of user interface screens or data transferred.

Finally, you should also expect some short-term uncertainty from IRS auditors as they begin to apply these new concepts. Some of the scenarios discussed above (e.g., data mining) may eventually be subject to further technical guidance. 

Disclaimer