Norwest Had Millions at Stake. Only 1 of 8 Internal Software Projects Qualified
Between 1986 and 1991, Norwest Corporation developed and modified numerous internal-use software systems. A later Coopers & Lybrand study identified 67 of 118 software development activities as potentially qualifying for the research credit.
When the dispute reached the Tax Court, the parties agreed to test eight representative activities and use the results to determine the treatment of the remaining 59 under an agreed formula.
Only one of the eight qualified.
The case, Norwest Corp. v. Commissioner, 110 T.C. 454 (1998), is an important example of why expensive, complicated, or business-critical software does not automatically qualify for the R&D tax credit.
Eight Projects Went to Trial. One Met the Test.
The eight representative projects covered a broad range of banking technology, including:
- A customer data integration system
- A trust accounting system
- An equipment leasing system
- A general ledger system
- A wire transfer system
- A payroll system
- A pension disbursement system
- A debit card system
These projects were treated as internal-use software under the rules applicable to the years at issue. The court evaluated each against the general research credit requirements and the additional requirements applicable to internal-use software at the time.
For internal-use software, those additional requirements included whether the software was innovative, involved significant economic risk, and was not commercially available for the taxpayer’s intended use without the required modifications.
The result was stark: the Strategic Banking System customer module qualified, while the other seven did not.
Why the Strategic Banking System Qualified
The Strategic Banking System, or SBS, was the clear outlier.
Norwest worked with Electronic Data Systems and another bank to develop a system that could integrate information about a customer’s various accounts. Existing systems could not handle the volume of data required or provide the customer-centered architecture the project called for.
The development effort lasted about three years and involved extensive testing. The project generated hundreds of unresolved technical problems, and an internal audit raised serious questions about whether the system would succeed.
The three participating companies ultimately spent an estimated $125 million on the effort.
The court found that the project involved genuine technical uncertainty and significant economic risk. The development team had to evaluate alternatives and experiment to determine whether the desired system could actually be developed.
Those facts helped the project satisfy the applicable requirements.
The important point is that the $125 million investment did not make the project qualifying research by itself. The spending supported the economic-risk analysis, but the court also looked at the underlying technical uncertainty, experimentation, innovation, and availability of alternatives.
Why the Other Seven Projects Failed
The other seven projects had different facts, but several shared a common problem: Norwest was often applying existing technology, modifying commercially available software, or using established approaches to solve implementation problems.
For example, the Cyborg payroll system involved a customized third-party package.
The Financial Control System, used for general ledger functions, was purchased software that was already being used by more than 30 of the top 100 U.S. banks. Norwest made substantial modifications to the system, but the court still found that the work did not satisfy the applicable requirements.
The debit card project also relied on technology that was already widely used in the banking industry. The court found insufficient technical risk to satisfy the applicable standard.
In its discussion of the trust accounting project, the court used the term “cookbook” to describe work that could be accomplished through established methods rather than through research involving the required level of uncertainty.
Norwest’s own expert, Dr. Drew McDermott, acknowledged that some of the work fell within the bounds of computer science as taught in textbooks.
The projects were not necessarily easy. They required skilled employees, significant implementation work, customization, testing, and substantial business resources.
But those facts were not enough.
Hard Work Is Not the Same as Qualified Research
That is the part of Norwest that businesses can easily miss.
A project can be:
- Expensive
- Technically complicated
- Important to the business
- Time-consuming
- Built by highly skilled engineers
- Heavily customized
and still fail to qualify for the R&D tax credit.
The relevant question is whether the claimed activities satisfy the requirements of qualified research.
For software, that means looking at whether the taxpayer faced genuine technical uncertainty, evaluated alternatives through a process of experimentation, and developed or improved a business component in a way that satisfies the applicable rules.
The IRS’s current software audit guidance similarly emphasizes that a taxpayer must establish both uncertainty and a process of experimentation. Simply showing that uncertainty was eventually eliminated is not enough.
In other words, difficulty alone is not the test.
The Discovery Test Changed After Norwest
There is another reason Norwest needs to be read carefully today: the rules have changed since the case was decided.
Norwest applied a much stricter version of the discovery requirement. At the time, the rules focused on whether the research was intended to obtain knowledge that exceeded, expanded, or refined the common knowledge of skilled professionals in the relevant field.
Treasury and the IRS later revised the general research credit regulations. The final regulations issued in 2004 abandoned that separate “common knowledge of skilled professionals” discovery requirement and instead focused on whether the research was undertaken to eliminate uncertainty concerning the development or improvement of a business component.
Importantly, the 2004 regulations did not finalize the internal-use software rules. Treasury and the IRS continued to develop separate guidance for software subject to the internal-use software exclusion.
So Norwest should not be read as though its exact discovery standard remains the test for every R&D claim today.
What Changed for Internal-Use Software
The current internal-use software framework is more specific.
Under today’s regulations, software developed primarily for internal use generally must first satisfy the requirements for qualified research and must not otherwise be excluded. It must also satisfy the high threshold of innovation test, unless an applicable exception applies.
That test generally requires the taxpayer to establish that:
- The software is innovative.
- Development involves significant economic risk because substantial resources are committed and there is substantial uncertainty, because of technical risk, that those resources will be recovered within a reasonable period.
- The software is not commercially available for the intended use without modifications that would themselves satisfy the innovation and economic-risk requirements.
The current rules also distinguish between internal-use software, non-internal-use software, and dual-function software. Software that enables interaction with third parties can receive different treatment, and certain dual-function software may qualify for a limited safe harbor if specific requirements are met.
The current regulations apply the internal-use software rules to taxable years beginning on or after October 4, 2016, with specific transition rules for earlier years.
Purchased Software Does Not Automatically End the Analysis
Norwest is especially relevant for businesses that build around commercial software.
But the lesson is not that customization automatically fails.
Instead, businesses should ask what the claimed development actually involved.
If a company purchases a platform and simply configures it, implements it, or applies established functionality, the work may not satisfy the requirements for qualified research.
But if the company encounters substantial technical uncertainty that cannot be resolved through readily available solutions and performs qualifying experimentation to resolve that uncertainty, the analysis can be different.
The same principle applies to integrations, modifications, and internally developed tools.
The question is not simply:
“Did we build or modify software?”
It is:
“What technical uncertainty existed, what alternatives were evaluated, and what did the development team have to discover or resolve through experimentation?”
What Norwest Means for Software Claims Today
Norwest remains useful because it shows how closely the facts matter.
A company can spend millions developing an internal system and still fail to qualify if the work primarily involves applying known technology or established methods.
At the same time, software does not have to represent a revolutionary invention to qualify under today’s rules. The current regulations specifically recognize that qualifying internal-use software can involve existing technology used in new ways, provided the applicable requirements are satisfied.
That makes project-level analysis important.
For each software project, businesses should be able to identify:
- What technical uncertainty existed at the beginning
- What alternatives the team considered
- What experimentation was performed
- What technical issues had to be resolved
- Whether commercially available software could meet the intended requirements
- Whether the project falls within internal-use software rules or another software category
- What wages and other qualified research expenses are connected to the qualifying activities
Where TaxDrone.AI Fits
TaxDrone.AI helps businesses evaluate software development projects against the requirements that actually apply to the claim, rather than assuming that expensive or difficult development automatically qualifies.
For companies with a mix of vendor customization, implementation work, integrations, and genuinely uncertain technical development, that distinction matters.
The goal is to identify and document the qualifying work before a claim is filed, rather than trying to reconstruct the analysis after an IRS examination begins.
The Norwest Lesson
Norwest is not a story about a bank that spent millions and simply got denied.
It is a case about the difference between building something difficult and performing qualifying research.
Of the eight representative projects tested, only one satisfied the applicable requirements.
For businesses developing internal software today, the lesson is straightforward: start with the technical facts, identify the uncertainty, understand which software rules apply, and document how the development team worked to resolve that uncertainty.
That is a much stronger starting point than assuming that cost, complexity, or business importance is enough.
Want to Know Which of Your Software Projects May Qualify?
If your business develops or modifies internal software, TaxDrone.AI can help you evaluate the activities, related costs, and supporting documentation behind your potential R&D tax credit claim.
Find out what your R&D activity could actually qualify. Get your free R&D tax credit estimate today.
