Decoding the R&D Tax Credit for Lead Generators


In 1981, in the wake of a recession, Congress enacted a tax credit designed to reverse the accelerated trends of a diminishing domestic ability to compete with foreign markets. Thus began the American investment in research and development.

The Credit for Increasing Research Activities, more commonly known as The Research and Development Tax Credit, has broad bipartisan support in Congress, as illustrated through 30 years of progressive expansion, refinement, and more than a dozen renewals.

Today, the United States assigns nearly $9 billion a year in federal R&D Tax Credits, making it one of the most lucrative tax incentives available in this country.

In addition, more than 30 states offer their own version of the credit. In some states there are fewer limiting factors and a wider scope for which the credits may be applied, thus doubling and tripling the overall benefit and impact when captured in conjunction with the federal credit.

The concept of R&D usually conjures up visions of white lab coats and microscopes. As a result, many software companies are unaware that the government offers incentives for engaging in activities that are often misclassified by programmers as “just another day in the office.”

Additionally, those who are aware of the R&D credit often lack the proper expertise and guidance, and consequently fail to capture and/or support all eligible expenses.

Based on Past

The myth that the R&D credit is only propagated in laboratories where groundbreaking innovations or patentable products are the focus comes from the fact that for the large majority of its existence, that was a relatively accurate depiction. The traditional definitions and the tax definitions of R&D were nearly synonymous.

Congress recently recognized, however, that restrictions such as the Discovery Test had been limiting the credit’s ability to fulfill its purpose for small and medium-sized businesses.

Navigating through another recession, it was again determined that investing in R&D would expedite our recovery, so the Discovery Test was thrown out along with a documentation requirement in an effort to stimulate economic growth.

Today, for software developers, one simply needs to develop new or improved software features or functionality and go through a development process (agile, waterfall, prototyping, spiral, RAD, etc.) to qualify.

For illustrative purposes, we turn to a lead generation firm that claimed the R&D credit for a six-figure refund. LeadGenCo employs teams of programmers who develop lead generation software and perform quality assurance tests. It also employs analysts, project managers, and executives who engage in the conceptualization process and/or the supervision of the programming teams.

Its development stage using the waterfall development methodology began with a requirements definition, then moved onto specification, system and software design, implementation and unit testing, integration and systems testing, acceptance testing, and eventually settled into operations and maintenance.

Passing the Test

As with any benefit offered by the government, there are requirements that every business must meet in order to qualify.

For the R&D Tax Credit, there is a four-part test:
1. There must be an attempt to develop a new or improved business component (e.g. software).
2. It must be technological in nature.
3. There must be a degree of uncertainty.
4. There must be a process of experimentation.

New or Improved Business Components

The U.S. Tax Code describes six elements that qualify as Business Components: products, processes, techniques, inventions, formulae, and computer software.

To qualify, the goal in the development of the software must be to create new or improve existing functionality, performance, reliability, or qualities (a “permitted purpose”).

The most obvious qualifying projects are the newer ones, and with some companies, it is apparent that the tests easily will be met. If the software programming and development supports the creation of new business components, it is a simple case to support the notion that a project containing a new software module would qualify.

And while the development of new programs is worthy of focus when capturing the R&D credit, one should not overlook the development of improved software. When a new software module is ready for its intended use, by no means is the development complete. In fact, it may never be.

Companies take small steps, improving a product or process gradually. Think about how many updates a single iPhone or Android app goes through. The developers are fixing bugs, improving performance and processes, adding new features, and refining the way it communicates with the hardware and other apps.

As long as there is an improvement of the software program or a creation of something entirely new, and if the work is aimed at a permitted purpose, it will satisfy the New or Improved Business Component test.

Permitted Purpose

LeadGenCo enhanced existing software to improve its processing ability. It also expanded the types of data that the system could handle. These improvements were for a permitted purpose — to improve the functionality and performance of the software.

Not everything it did was ultimately considered qualified for R&D, such as cosmetic changes to an interface and syntax error corrections (activities which related primarily to style or taste were not eligible for the credit ), so the wages tied to those hours were not applied.

However, there were significant hours left to capture because of the type of programming in which the company was engaged.

Technological in Nature

The goal of the R&D credit is meant to incentivize technical, scientific, and engineering-based activities. Programming naturally relies on principles of computer science, making this an easy test for software companies to pass.

Examples of developmental activities eligible for R&D tax incentives:
• Developing new or improved technologies
• Developing requirements, domain, software elements, or scope analysis for a new functional software enhancement
• Evaluating and establishing functional specifications
• Designing and developing the structural software architecture
• Establishing electronic interfaces and functional relationships between various software modules
• Programming software source code
• Compiling and testing source code
• Conducting unit, integration, functional, performance, and regression testing


Defining the uncertainty faced within a project can be complex. Under current regulations, the uncertainties faced should be identified at the outset of a research project.

It will be determined that “uncertainty exists if the information available to the taxpayer does not establish the capability or method of developing or improving the business component, or the appropriate design of the business component.”

In software development, there are a wide variety of situations where uncertainty may occur. Though there may not always be significant uncertainty regarding the capability or method of developing a new or improved software program, there is typically uncertainty as to the most efficient design. The key is that all three types of uncertainty need not exist; any one area will qualify on its own.

Posted in Spring 2013.