Software work can qualify for the R&D credit, but software built mainly for your own use gets extra scrutiny. If you are building internal tools, it helps to know where the line is before you start documenting.

What counts as internal-use software

Under the Treasury regulations (see 26 CFR 1.41-4), software is generally internal use when it is developed for the general and administrative functions of running the business, such as financial management, human resources and support services. Software developed to be sold, leased or licensed to customers is not internal use.

Software that is not subject to the extra test

• Software you develop to sell, lease or license

• Software used in qualified research itself or in a production process

• Software that lets third parties interact with your business or initiate functions on your system, under the rules for third-party use

Software that does both, serving your back office and also supporting third-party interaction, is called dual-function software. The regulations give ways to separate the third-party part, and there is an optional safe harbor when the two cannot be separated.

The extra test: high threshold of innovation

Internal-use software has to meet the usual four-part test and also a higher standard, called the high threshold of innovation. In summary, the software must be:

• Innovative, meaning it is intended to reduce cost or improve speed by an amount that is substantial and economically significant

• Developed with significant economic risk, meaning you commit substantial resources and there is substantial uncertainty because of technical risk

• Not commercially available, meaning you cannot buy, lease or license it for your needs without changes that would meet the innovation standard

The IRS and Treasury have said a revolutionary discovery is not required, but the standard is still a high one for most routine business software.

Where internal tools often land

• A custom system that solves a problem no off-the-shelf product addresses may qualify, with strong documentation

• A tool built by configuring a commercial product usually does not qualify

• A dashboard that reports on data you already have is rarely enough on its own

• A tool that sits inside a product you sell is generally not treated as internal use

What to document

• The business problem and why existing products did not solve it

• The technical uncertainty and the approaches you tried

• Who built it and what they did

• Testing, iterations and what failed

• The expected gain in cost or speed, and how you estimated it

Why this matters for your claim

If internal-use software makes up a large share of your development effort, how you classify it can change the size of the claim. We sort projects early so the claim rests on the work that clearly qualifies, and we flag the items that need more support.

Not sure which of your projects are which? A free 5 to 10 minute screening is a good first step, and you can read more in the software guide or on what qualifies.