More Financial Institutions than ever before will claim the R&D Tax Credit in 2018
As the 2018 tax season quickly approaches, financial institutions and their trusted advisors will look into various strategies to help bring savings to the bottom line. One potential tax savings tool that should not be ignored this year is the R&D tax credit. That’s because there have been many recent favorable changes made to the credit which now broadens its applicability for all taxpayers.
As it relates specifically to financial institutions, 2016 final regulations relating to Internal Use Software (IUS) development have drastically expanded the utilization of this incentive and have significantly reduced the controversy that has historically plagued it. It’s because of these final regulations that banks, insurance companies, brokerages and investment firms investing in the design, development and implementation of client systems such as online banking, online investment services, web-based insurance quoting services and mobile applications now face fewer qualification requirements for credit eligibility than in years past.
While these final regulations vastly and favorably impacted the previous regulations in several areas, for the sake of this blog post, we’re going to focus solely on the change in definition of IUS and provide you with a real-world example of why this new definition is now so beneficial for the financial industry.
If you are interested in obtaining a full in-depth overview on these final regulations, be sure to download our detailed article here.
Definition of IUS prior to 2016:
Before we delve into the definition of IUS, it’s important to note that for any project to qualify for the R&D tax credit, it must meet a 4-part test. However, for some software development projects, specifically those that were categorized as IUS, they had to meet three additional requirements often referred to as the 7-part test or the “High Threshold of Innovation” test. Simply put, as a taxpayer, you did NOT want your software development project to be classified as Internal-Use, as it was much harder to meet the eligibility requirements needed to claim the credit. (Again, for the sake of this blog post, we are not going to get into the nuances of these tests but if you are interested in learning more about the differences between them, be sure to download our detailed article here.)
Therefore, the definition of “Internal-Use” is extremely important, as it will determine the credit eligibility requirements which must be met by a taxpayer conducting software development. Prior regulations (and there were more than one set of regulations to contend with) provided the following definition of “internal-use” software:
Unless computer software is developed to be commercially sold, leased, licensed, or otherwise marketed, for separately stated consideration to unrelated third parties, computer software is presumed developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use.
The sole focus of this definition is on the commercial treatment of the software, while ignoring the function of the software itself. This created inconsistent treatment among taxpayers R&D claims, as some taxpayers did not wish to, or were not able to charge their customers separately for each of the software applications that were being developed for use in conducting their business. Thus, the commercial focus of these regulations grossly expanded the reach of the term “internal-use”, and created unfair and inconsistent treatment between taxpayers based on how they marketed their software applications.
Today’s Definition of IUS:
The 2016 regulations revised the definition of IUS, and added a separate definition for Non-IUS for further clarification. These revisions can be summarized as follows:
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.
The regulations provided that the determination of whether the software will be categorized as IUS or non-IUS will be based on the taxpayer’s intent and facts and circumstances at the beginning of the software development.
This new definition is a vast improvement to earlier versions, in that it focuses on the function of the software and provides clarification as to which functions are not IUS. This definition will make it easier for financial institutions to claim the research credit for many of their software development projects and properly defend them if audited by the IRS.
Real World Example:
The financial institution industry is one that these new regulations will significantly and favorably impact. A good example of the type of development which should now be classified as non-IUS is mobile online banking application software development.
As financial institutions generally will not charge their customers for the use of these services, past regulations would have treated them as IUS, and thus subject to a significantly higher burden of credit eligibility. Based solely on commercial treatment of the service, the development would not be credit eligible, unless it met those three additional more stringent eligibility requirements. Given the lack of clarity surrounding these tests in the past, the taxpayer may not be able to support that the development met all these requirements.
Under the new regulations, the function of the mobile online banking application would be considered non-IUS, as it is not intended for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. In addition, the application would certainly enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system, and thus specifically non-IUS per the regulations. The result is that only the general 4-part test would apply to this development, a much lower burden of proof than would be required under the previous regulations.
_
As you can see, there is a much greater opportunity today for companies investing in the design, development and implementation of client systems to claim the R&D tax credit.
