Avoiding the pitfalls of claiming the R&D tax credit for software development

Intro

Attempting to determine and document your R&D tax credit can be quite daunting for any business.  This is true for businesses who are unsure they qualify, and equally true for businesses who know they qualify, but struggle with how best to identify and document their qualifying activities. 

For businesses claiming the credit for software engineering, the process can be further complicated by the sometimes-seemingly abstract nature of coding and the variety of activities involved in developing a codebase. But it doesn’t have to be!

The purpose of this article is to:

(1) Provide a clear framework for how any software development company should approach claiming the R&D tax credit, and

(2) Highlight the most common pitfalls of doing so, to help you avoid them!  

Otto von Bismarck once wrote“...the wise man learns from the mistakes of others''.  So, here’s to learning from others. 

R&D Tax Credit Basics

(If you’re already well versed in basics of the R&D tax credit, feel free to skip to the next section.)

The rules for claiming the R&D tax credit are complex and can be quite intimidating.  Before we provide a useful framework and discuss the common pitfalls, a brief summary of the credit and general rules is in order:

• The formal name for the R&D tax credit is the “Credit For Increasing Research Activities.”And it is, in fact, just that, a credit offered to companies that increase their Qualifying Research Expenses (“QREs”) over a historical baseline amount.

  • The U.S. federal R&D tax credit has been around for over 40 years.
    

  • QREs generally refer to employee wages, contract research expenses (think outside service providers or 1099 contractors), supplies used in development (think physical prototype expenses), and cloud computing expenses allocable to development (think Google Cloud or AWS).
    

  • The credit takes the form of a general business credit that can be used to offset taxable income.
  • All or a portion of the credit may instead be used to offset the FICA portion of a company’s payroll taxes. This option is limited to only companies that meet the definition of a Qualified Small Business (“QSB”) under IRC Section 41(h) and make a timely filed election.
    
• The R&D credit is available to companies in virtually any industry as long as they are attempting to develop or improve a product, process, computer software, technique, formula, or invention which is either held for sale, lease, or sale or that is used by the taxpayer in a trade or business of the taxpayer (IRC Section 41(d)(2)(B)). The IRS refers to the “thing” a taxpayer is attempting to develop or improve as a “business component”.

It’s important to note: when a company determines their qualifying research expenses, such analysis must be performed separately, by business component.  Many simply ignore this requirement. We’ll dive into this in more detail later.

For expenses on a business component to qualify, the associated activities must meet certain requirements, commonly referred to as "The Four-Part Test".  These requirements are laid out in IRC Section 41(d)(1) and are summarized below:

• The Section 174 Test: The qualifying research must be of a character that may be treated as “specified research or experimental expenditures” under IRC Section 174.
• The Discovering Technological Information Test: The qualifying research must have been undertaken for the purpose of discovering information which is technological in nature.
• The Business Component Test: The application of the qualifying research must be intended to be useful in the development of a new or improved business component of the taxpayer.
• The Process of Experimentation Test: Substantially all of the activities of which constitute elements of a process of experimentation for the purpose of: 
  • Developing a new or improved function; or
  • Improving performance, reliability, or quality. 

In addition to IRS Regulations and relevant case law, the IRS has also issued Audit Guidelines on the Application of the Process of Experimentation for all Software, which outlines how examiners should approach an audit of any company claiming an R&D tax credit specifically for their software development efforts.

Key observations about the IRS Audit Guidelines 

While the credit is not limited to any specific industry, any taxpayer claiming the credit must demonstrate that the research activities engaged in to develop or improve a business component meet the Four-Part Test.  

Equally as important, this analysis must be performed on a business component-by-business component (“BCxBC”) basis. We’ll continue to emphasize this, because it represents perhaps the most common and significant pitfall made by taxpayers!  A few key observations regarding the IRS Audit Guidelines:

💭  Thing No. 1: The IRS posits that there are many common software development activities that will generally never qualify for the credit, such as: project planning/management, estimating resources, routine QA activities, etc. While they do not specifically assign a risk factor to these they are presumably not qualifying as they are of only indirect benefit to the research. 


💭  Thing No. 2:  The IRS also posits that there is a distinction between a software development uncertainty, that is resolved through a “process of experimentation”, and a software development uncertainty that is resolved by “other means”.  The following example is provided therein: “a taxpayer may have to configure a software application, and may be uncertain about which configuration choices to make. This uncertainty, in and of itself, does not indicate that the taxpayer subsequently engaged in a process of experimentation to eliminate the configuration uncertainty. The activities undertaken to eliminate the configuration uncertainty are determinative.”


💭  Thing No. 3: The IRS also posits that in addition to software development uncertainties, “there are other types of uncertainties, namely business and project uncertainties.” The following elaboration is given therein “Business uncertainties could, for example, be whether or not potential customers will react favorably to the new product, and/or whether or not the product will be competitive. Project uncertainties could be whether or not the existing staff is adequately trained to use a technology, and/or whether the project can be completed within a given schedule and budget. Such uncertainties do not meet the requirements of I.R.C. § 41(d)."


💭  Thing No. 4: The IRS also provides a summary of the common software development activities and categorizes them into risk categories:

• High risk -- the 17 activities in this category usually fail to qualify
• Moderate risk -- the 5 activities in this category  often fail to qualify 
• Low risk -- the 4activities in this category rarely fail to qualify
  

The simple math (not weighted for prevalence) is that about 85% of the activities outlined by the IRS are at moderate or high risk of not qualifying.

As evidenced in the IRS audit guidelines referenced in the previous section, the IRS’ overriding argument could be paraphrased as the following: just because a company is developing software, does not automatically mean that everything their engineers do qualifies as research per the IRS rules.

The takeaway is this: Just because a company is developing software does not automatically mean that everything each engineer does qualifies for the R&D credit. Even if you are an early stage software company (even pre-release of your first product), an IRS agent will likely challenge the nature of your qualifying activities and attempt to carve out any activities they argue do not qualify.  

The 2 most common pitfalls of claiming the R&D credit for software engineering

1) Simply ignoring the BC x BC requirement

Many R&D tax credit providers use a high-level, estimate-driven approach whereby they simply allocate the amount of time they think each individual employee (or contractor) spent on a general bucket they call  “qualifying activities.” They make no effort to create the required nexus (i.e. link) between the person, their activity, and the qualifying business component(s) they worked on. 

Third-party R&D credit providers will push this oversimplified approach for two reasons:

(1) ignoring the rule is just plain easier than doing an in-depth analysis, and
(2) they're playing what's referred to in the accounting/tax world as "the audit lottery."

That is, they're banking on only a small number of clients (if any at all) ever getting audited and therefore, cut corners to make engagements more profitable (you can take that to the bank!). 

Bottom line: Oversimplification and estimates will set you up for failure under IRS audit. Ignore at your own peril! 

2) Assuming everything software engineers do qualifies as research, without regard to the IRS rules

The effect of falling into the high-level estimate trap described in pitfall #1 is that such an approach also renders you vulnerable if you're ever audited in the future. You haven’t adequately identified the nature of qualifying or non-qualifying activities, which means there's no way to defend them.

As is clearly demonstrated by the IRS Audit Guidelines, the IRS will challenge the activities deemed qualified for a software development company, even for early-stage companies.   

So, what then should software companies do to avoid this second trap?  They could use a more robust survey methodology that attempts to provide a much more meaningful and granular breakdown of the activities performed by each individual on each business component. This approach would help mitigate some risk, but in our experience the downsides are two-fold:

(1) It relies on estimates being made long after the activities themselves were performed- often many months or even years. The IRS has routinely deemed such estimates as being insufficient and/or biased/self-serving.

(2) It can be prohibitively time-consuming and disruptive to implement. Such an approach requires substantial education about the types of activities that qualify or don't according to the IRS rules, and can be highly disruptive to your organization’s day-to-day operations.  

So you’re damned if you do (try to implement a more robust and detailed survey-based approach) and damned if you don’t (i.e. you rely on estimates).

TaxCredit.ai is the smartest way for software businesses to claim the R&D credit

We’ve built a platform powered by machine learning (“ML”) that does all of this automatically for you.

How it works

✅ The TaxCredit.ai platform connects directly with the most popular version control and project management platforms that your engineering teams already use. We're compatible with GitHub, GitLab, Microsoft Azure DevOps, Jira, Asana, Trello, Monday.com, Basecamp, and more.

✅ The TaxCredit.ai platform takes your engineering data and runs them through our own proprietary machine learning algorithm that classifies each Git commit or task into qualified or excluded activity categories based on the IRS qualification rules. 

✅ The TaxCredit.ai platform allows for the most efficient and detailed review of software engineering activities and allows for adjustments to be made to the results before being finalized.  

✅ The TaxCredit.ai platform generates contemporaneous documentation supporting your tax credit claim (creating the nexus between individuals, their activities, and the qualifying business components they work on). 

Benefits of using TaxCredit.ai

✅ The TaxCredit.ai platform allows the user to substantially reduce the level of effort needed to accurately calculate and document their R&D credit.

✅ The TaxCredit.ai platform frees the user from the dependency on high-level estimates. 

✅ The TaxCredit.ai platform leverages your actual engineering data as the basis for determining your credit, meaning the resulting credit calculations are highly defensible.  

✅ The TaxCredit.ai platform automatically generates contemporaneous documentation to protect your tax credit claim. 

Why trust TaxCredit.ai?

✅ We've partnered with 30+ accounting firms (B2B) as the software provider for their R&D credit practice. 

✅ We've successfully piloted our software with multiple R&D tax credit practices at internationally renowned accounting firms.

We would love the opportunity to help your software business claim the credit. See how it works by scheduling a demo or consultation with us here.