Internal-use software and the high-threshold-of-innovation test: five examples

Software built primarily for a company's own general-and-administrative functions — financial management, HR, support services — must clear three hurdles beyond the ordinary four-part test before its costs count toward the research credit. Treas. Reg. §1.41-4(c)(6) requires that the software be innovative, that its development involve significant economic risk, and that no commercially available alternative would serve without substantial modification. Software sold to customers, or that lets third parties interact with the taxpayer's systems, escapes the regime entirely.

The three extra prongs

The regulations at eCFR Title 26 define each prong. Innovative means the software is intended to result in a reduction in cost or improvement in speed that is substantial and economically significant. Significant economic risk means the taxpayer commits substantial resources with substantial uncertainty, because of technical risk, that they will be recovered within a reasonable period. Not commercially available means no existing product could be used for the intended purpose without modifications satisfying the first two prongs. All three must be met — in addition to, not instead of, Section 41(d).

Five projects, tested

A comparative summary, before the detail:

1. ERP implementation. A distributor licenses a major ERP suite and spends $2M on configuration, data migration, and standard integrations. Fails. The software is commercially available and works as designed; configuration involves business judgment, not technological uncertainty. This is the most commonly — and wrongly — claimed project type.

2. Warehouse routing engine. A retailer builds, from scratch, a real-time optimization engine to route pickers through fulfillment centers, after concluding no vendor product could handle its constraint set without a ground-up rewrite. Development consumed 18 months with genuine uncertainty whether the latency targets were achievable. Passes: novel algorithmic work (innovative, targeting a measurable double-digit labor-cost reduction), real technical risk to substantial committed resources, and no commercial substitute.

3. KPI dashboard. Finance builds an executive dashboard on a commercial BI platform — data pipelines, visualizations, scheduled refreshes. Fails. The work is capable and useful, but nothing about it is technologically uncertain, the cost-reduction case is soft, and the BI platform is the commercially available tool doing the heavy lifting.

4. Customer portal. A logistics company builds a portal where customers book shipments, track loads, and pull documents. Not internal-use software at all — third parties initiate functions on the taxpayer's systems, so under Treas. Reg. §1.41-4(c)(6)(iii) only the ordinary four-part test applies. Whether it passes that test depends on the usual experimentation analysis covered in software development and the R&D credit.

5. Fraud-scoring model. An insurer develops an in-house machine-learning system to score claims for fraud, after vendor tools proved unable to handle its data at acceptable false-positive rates. Passes: model architecture and feature engineering involved systematic experimentation, the projected loss-avoidance is substantial and quantified, resources were committed under real technical uncertainty, and the commercial alternatives were evaluated and rejected in writing — the exhibit an examiner will ask for.

The IRS research credit overview flags internal-use software as a distinct category but leaves the three-prong analysis to the regulations. Document the commercial-alternative evaluation and the risk assessment contemporaneously; both are factual questions the taxpayer bears the burden of proving.