R&D Binder

Short answer. Internal-use software (IUS) is software a company develops primarily for its own general and administrative functions, like finance, human resources, or back-office support. It can still qualify for the Section 41 research credit, but only after it passes an extra three-part test that ordinary software does not face. The rule exists because most internal tools are routine, and the credit is meant for genuine technical risk.

What counts as internal-use software

The label turns on who the software is for, not what language it is written in.

Software is internal-use when a company develops it primarily for its own general and administrative functions, such as finance and accounting, human resources, or other back-office support. A custom general ledger system is the classic example.

Software is not internal-use when it is developed to be sold, leased, or licensed, or when it lets third parties initiate functions or review data on the company's system. Customer-facing products sit outside the internal-use rules entirely.

The distinction matters because internal-use software has to clear an extra test before its development can count toward the credit.

The high-threshold-of-innovation test

Internal-use software has to pass three added requirements, on top of the regular four-part test.

Under Treasury Regulation section 1.41-4(c)(6), internal-use software qualifies only if the development is innovative, carries significant economic risk, and is not commercially available for use without modifications that would themselves meet the test.

Innovative means the software is intended to produce a meaningful reduction in cost, an improvement in speed, or another measurable economic improvement. Significant economic risk means the company committed substantial resources with real uncertainty, because of technical risk, about whether it would recover them in a reasonable period.

All three have to hold at once, in addition to the standard four-part test. That is a high bar, and it is where most internal-use claims are won or lost.

Why it matters for your documentation

Treating internal-use software like ordinary software is a common and expensive mistake.

If a component is internal-use and the file does not show the three-part threshold, an examiner can exclude the whole component, even when the underlying work was genuinely experimental.

The fix is to identify internal-use components up front and document the innovation, the economic risk, and the absence of an off-the-shelf alternative while the work is happening, not years later under audit.

Internal-use software still has to satisfy the ordinary tests too:

Sources

Every claim on this page traces to a primary authority. Each source below is independent and verifiable.

Get documentation built to survive an exam

R&D Binder flags internal-use components during clustering and documents the high-threshold showing where it applies, so your CPA can see which software cleared the bar and why.

Estimate your credit See the sample binder