Norwest v. Commissioner: internal-use software and the consistency rule

Norwest Corp. v. Commissioner, 110 T.C. 454 (1998), is a bank-holding-company case that shaped two durable pieces of research credit law. First, it was among the earliest full merits decisions on internal-use software — software developed for the taxpayer's own back-office operations — applying a demanding, legislative-history-driven standard that prefigured the high-threshold-of-innovation test now codified at Treas. Reg. §1.41-4(c)(6). Second, it enforced the consistency rule of Section 41(c): qualified research expenses in the base period must be determined on the same basis as in the credit year, so a definitional win in the credit year is also a definitional adjustment to the base.

The dispute

Norwest, a large bank holding company, claimed research credits for dozens of software development projects — deposit systems, loan servicing, item processing, and similar internal banking applications — along with other technology work. The IRS challenged qualification, arguing the projects were routine business software adaptation, and disputed the computation, contending Norwest had not determined base-period QREs consistently with its expansive credit-year claims.

The holding

The Tax Court analyzed representative projects and held that most of the internal-use software work did not qualify. Drawing on the legislative history of the 1986 Act, the court required internal-use software to clear additional hurdles beyond the ordinary four-part test — in substance, that the software be innovative, involve significant economic risk of unrecoverable development resources, and not be commercially available for the taxpayer's use. Ordinary development of banking applications using known techniques failed. A minority of projects with genuine technical risk fared better. On computation, the court held Norwest to the Section 41(c)(6) consistency requirement: to the extent the credit-year QRE definition changed, base-year amounts had to be redetermined on the same basis.

The reasoning that matters

The internal-use software analysis mattered because the statute itself, in Section 41(d)(4)(E), makes such software presumptively non-qualified "except to the extent provided in regulations" — and in 1998 there were no final regulations, leaving the court to construct standards from congressional intent. Norwest's three-factor framework — innovation, significant economic risk, commercial unavailability — proved sticky: after nearly two decades of proposed rules, the final 2016 regulations adopted a recognizably Norwest-shaped high threshold of innovation test, while narrowing what counts as "internal use" in the first place (software for third-party interaction is excluded from the category).

The consistency holding rests on the credit's incremental architecture. The credit rewards spending above a base derived from historical QREs; if the taxpayer counts a category of spending in the credit year but not in the base, the "increment" is definitional, not real. The court treated symmetric determination as mandatory, not elective.

What it means for claims today

The internal-use software chapter now runs through Treas. Reg. §1.41-4(c)(6): first classify the software (internal-use versus third-party-facing or commercial), then apply the high-threshold-of-innovation test where required. Claims for ERP configuration, back-office systems, and internal tooling still fail most often exactly where Norwest's projects did — known methods, low technical risk, available alternatives.

The consistency rule has, if anything, grown in reach. Under the alternative simplified credit, the base is the prior-three-year QRE average, so every credit-year definitional position has an immediate three-year mirror: an examiner who removes a QRE category from the claim year must remove it from the base years (which helps the taxpayer), and a taxpayer who adds a category to the claim year must add it to the base (which shrinks the increment). Credit studies that recompute the claim year without touching the base are structurally noncompliant, and the computation faces its first check on Form 6765 itself. The mechanics are summarized in the IRS research credit overview.

Related cases on the site

Eustace is the companion software case denying credits for routine development on qualification grounds; Union Carbide and Suder show the ordinary four-part test that non-internal-use software must still meet — see the four-part test explained. Norwest's place among the doctrines, and the computation cases generally, are mapped in the research credit case law map.