R&D Tax Credit Opportunities for Insurance Companies

The Federal Research & Development (R&D) Tax Credit is designed to provide a compelling incentive for businesses that invest in research and innovation. Originally introduced in 1981, the credit has undergone many refinements which have expanded its application to more businesses and industries. The R&D credit offers a dollar-for-dollar reduction of federal tax liability. Despite the credit’s generous tax benefits, there are still companies hesitant to claim the credit due to several myths about the credit.

Insurance companies often overlook the R&D credit because most do not believe that they perform any qualified research and development. However, this cannot be further from the truth. In fact, software development is the most common qualifying activity for insurance companies. This is especially true as the industry moves towards greater technology integration to streamline traditional business processes (i. e. claims management, customer service, etc.). To help clients, prospects, and others, JLK Rosenberger has provided a summary of the key details below.

Software-Related R&D Expenses

Since software development projects will most likely qualify for the R&D credit, it is important to understand which expenses can be taken towards the credit calculation. Typically, this includes a mix of expenses paid to employees performing R&D activities and contractors used in conjunction with these activities. More specifically, for the purposes of the R&D credit calculation, any employee wages paid when performing eligible R&D activities and expenses for outside development consultants paid on an hourly basis relating to qualified R&D, may be used.

Any cloud lease or other rental expenses associated with the eligible R&D activity may also be examined for credit calculation. This can include using a cloud-based environment for development work or designing and using a mirrored virtual environment to test new coding configurations. Of course, there may be other qualifying expenses, but those need to be identified on a case-by-case basis. Finally, all activities must be performed in the United States to qualify.

Eligible Software Activities – Insurance Industry

Eligible software activities are generally those that interface with third-party applications as opposed to those used primarily for internal purposes. Development efforts should focus on designing, coding, and testing for new and improved products or functionalities. This means investment in custom software development that integrates claims management, policy compliance, quoting, and risk analysis functions with third-party applications will likely qualify as these types of activities only need to pass the Four-Part Test under the Tax Code in §41(d).

Applications used primarily for internal purposes, such as human resources and other management functions may also be eligible, but the threshold for qualification is much higher. In addition to passing the Four-Part Test, software developed only for internal use must also meet three additional requirements laid out in Federal Regulations §1.41-4(c)(6)(vii) known as the “High Threshold of Innovation Test.” For this test, the taxpayer must prove that (1) the software is innovative; (2) developing the software involved significant economic risk; and (3) the software is not commercially available in the market. The tax experts at JLK Rosenberger can help navigate you through the documentation and support required to claim your custom internal use software development expenses.

The IRS has provided examples of software development activities typically considered eligible for R&D. These include:

• Developing new or improved software, such as operating and other systems, applications, certain compilers, and platforms;
• Custom programming and coding activities related to:
  • New or improved software programs or applications.
  • Improving the functionalities, performance, or reliability of an application;
  • System integration, such as getting the interfaces of different electronic and software platforms to be able to communicate with, send, and retrieve data from other software applications;
  • Functional enhancements to existing software applications or products;
• Developing user requirements that define the functionality of the software;
• Developing functional or design specifications, or test parameters;
• Developing new or improved architectures, software algorithms, or database management techniques;
• Development of specialized technologies, such as artificial intelligence, image processing, or speech recognition;
• Integrated hardware and software design-related activities; and
• Quality assurance testing during the development process, such as alpha, beta, performance, stress, regression, module, systems, and integration.

Ineligible Software Activities

The IRS also identified activities that are gray areas as well as those that are ineligible for R&D. The following lists software development activities that are riskier to include and typically not qualified; however, due to the complex nature of the R&D credit, before excluding any activities, one should discuss with an R&D tax expert at JLK Rosenberger. These activities include:

• Project management and planning related to resource planning, gathering estimates, budgeting, and scheduling;
• Software maintenance or debugging activities;
• Implementation of commercially available products, such as choosing between off-the-shelf products, such as:
  • Types of database management systems or computer manufacturers;
  • Enterprise resource program suppliers (i. e. SAP, Oracle, PeopleSoft);
  • Different web portal platforms;
• Software application configurations for commercially available products, such as:
  • Selecting among vendor-defined options or modifying product defaults;
  • Bundling existing individual software products into a single product suite;
• Upgrading to newer versions of hardware or software, or installing new vendor-issued releases;
• Reverse-engineering activities related to learning how an existing application works;
• Data validation and re-writing existing code for compatibility with a new hardware or software platform that is akin to upgrades (i. e. has no new application architecture) and where the original program code is directly converted into the new language constructs;
• Changing to a different or newer technology where the features of the old and new technology are similar in nature, such as converting from a hierarchical database technology to a relational database technology;
• Software developed as an embedded application, such as in cell phones, that does not involve new software or custom coding, but rather the software already included in the system to execute the new application; and
• Graphical user interface activities focusing on how a screen or feature looks versus functionalities.