United Stationers, Inc. v. United States is an important historical decision on the federal research tax credit and software developed for a taxpayer’s own operations. The Seventh Circuit affirmed the denial of the credit in 1998 under standards that preceded major changes to Treasury regulations. This study examines the case, related decisions, and the distinction between its historical discovery requirement and the rules governing modern software research claims.

The Statutory and Legislative Foundation of the Research Tax Credit

Congress introduced the research credit in the Economic Recovery Tax Act of 1981 to encourage investment in research. Initially temporary and repeatedly extended, it became permanent under the Protecting Americans from Tax Hikes Act of 2015. Eligibility depends on statutory requirements and exclusions; commercial importance or substantial development spending does not establish qualification.

Section 41(d) applies the qualified research requirements separately to each business component. A component may be a product, process, computer software, technique, formula, or invention used in the taxpayer’s business or held for sale, lease, or license. Where a component fails the requirements, the regulatory shrinking-back rule may require examining a qualifying subset.

The Four-Part Test for Qualified Research Activities

These are eligibility requirements, not separate evidentiary burdens of proof. Qualifying activities must also survive the exclusions in § 41(d)(4), and expenses must satisfy § 41(b). The internal use software exclusion has statutory exceptions, including software used in qualified research or a qualifying production process, as well as regulatory provisions.

Factual Background of United Stationers, Inc. v. United States

United Stationers was an office-supplies wholesaler seeking to improve operational efficiency during rapid growth. It developed eight related software projects in fiscal 1988 using file structures and data-access elements from a purchased package called DCS. DCS could not meet its requirements without modification, so the company developed application code around those elements.

Analysis of the Eight Software Projects at Issue

The appellate opinion identifies the following projects. Their business objectives explain their functions but do not, by themselves, establish qualified research.

For the fiscal year ended August 31, 1988, the appellate opinion describes an allowed § 174 deduction of $156,457 and an amended claim for a § 41 credit of the same amount. After the IRS took no action, the company sued for a refund. An allowed research deduction did not establish entitlement to the separate credit.

The District Court’s Denial of the Credit

The district court’s 1997 decision, 982 F. Supp. 1279, largely adopted a magistrate judge’s recommendations. It found that the company failed the discovery and experimentation requirements and, independently, the conditions for overcoming the internal use software exclusion.

The Discovery Hurdle

The district court distinguished the application of existing technological information from the discovery of qualifying information. Although the software was technological in nature, the court considered the development an application and modification of existing knowledge. This reasoning belongs to the historical framework and should not be presented as the current regulatory test.

Failure of the Process of Experimentation

The court distinguished uncertainty about anticipated business benefits from uncertainty about the means of developing the software. The project summaries described possible operational improvements and investment returns but did not adequately establish technical uncertainty in the development process.

The distinction remains useful: testing whether a system delivers a desired economic benefit is different from evaluating technical alternatives to resolve uncertainty concerning capability, method, or appropriate design. Nevertheless, routine debugging is not a universal label that decides eligibility. Activities must be examined under the applicable rules and their actual technical purpose.

The Seventh Circuit’s Affirmation and the Discovery Rule

The Seventh Circuit affirmed on December 24, 1998, in United Stationers, Inc. v. United States, 163 F.3d 440. It applied a demanding interpretation of technological discovery alongside the experimentation and internal use software requirements.

The Broad Effect Standard

The appellate court expected research to expand or refine computer-science principles and have an effect beyond improvements specific to the taxpayer’s operations. That interpretation was stricter than the later Treasury regulations. Describing it as a literal requirement that every qualifying product be unprecedented anywhere in the world would overstate the holding.

The restrictive approach created difficulties for software claimants, but it did not produce universal denial of software research credits. Norwest, discussed below, illustrates that some software research qualified even within that historical framework.

Scientific Method and Trial and Error

United Stationers rejected the proposition that ordinary software debugging automatically constitutes experimentation. The court nevertheless stressed the factual nature of § 41 disputes and avoided a categorical bright-line rule. Under current regulations, systematic trial and error can constitute a process of experimentation when it evaluates alternatives to resolve technological uncertainty. A formal laboratory setting or a particular label for the development methodology is not required.

Comparison with Related Jurisprudence: Norwest and Eustace

Norwest Corp. v. Commissioner and Eustace v. Commissioner help place United Stationers in its historical setting. Their holdings should be read with attention to the tax years, evidence, and regulations involved.

The Norwest Decision

In Norwest Corp. v. Commissioner, 110 T.C. 454 (1998), the Tax Court accepted qualifying research for the customer module of the Strategic Banking System. The project sought to integrate customer information across banking systems while handling substantial data volumes. Evidence of design alternatives, repeated testing, and technical challenges supported the result.

The holding was narrower than allowing every activity within the entire Strategic Banking System. The court did not accept the deposit and credit modules on the record before it, and it excluded certain customization and later activities. Accordingly, describing the outcome merely as one whole project qualifying out of eight obscures the component and activity distinctions.

The Eustace Decision

In Eustace v. Commissioner, 312 F.3d 905 (7th Cir. 2002), the Seventh Circuit affirmed denial of credits for insurance software development. It applied United Stationers to a record that did not establish the required scientific research and technological uncertainty. The court also acknowledged that forthcoming regulations could change the governing approach.

Internal Use Software and the High Threshold of Innovation

United Stationers treated the programs as developed primarily for internal use under the historical totality-of-the-circumstances approach. This included DRRS and Unilink despite their customer-access features. It is therefore inaccurate to characterize all the original software as purely internal or to assume that customer interaction was absent in the 1980s.

The Three-Part Innovation Test

The historical exception drew on legislative history and proposed regulations. Current Treasury Regulation § 1.41-4(c)(6)(vii) sets out three additional requirements for internal use software seeking qualification through the high-threshold route:

• Innovation: Successful development would produce a substantial and economically significant cost reduction, speed improvement, or other measurable improvement. The standard measures anticipated improvement, rather than requiring uniqueness or novelty.
• Significant economic risk: Substantial resources are committed, and technical risk creates substantial uncertainty about recovering them within a reasonable period. Current regulations do not require uncertainty about whether the final result could ever be achieved.
• Commercial availability: Software cannot be purchased, leased, or licensed for the intended purpose without modifications that themselves satisfy the innovation and significant-economic-risk requirements.

In United Stationers, commercial unavailability was stipulated and the finding of innovation survived appellate review. The company nevertheless failed the technical-risk requirement. Substantial expenditure and uncertainty about economic returns did not substitute for the necessary technical evidence.

Documentation of Innovation

The practical lesson concerns the substance of the project evidence. Records should explain the technical challenges, alternatives evaluated, activities performed, and anticipated measurable improvements. General statements that benefits were uncertain cannot establish every requirement. Specific evidence is more useful than retrospective descriptions that simply repeat statutory terminology.

The Regulatory Shift: T.D. 9104 and the Revised Discovery Standard

T.D. 9104 was published on January 2, 2004, and its general research rules apply to taxable years ending on or after December 31, 2003. It removed the requirement to advance the common knowledge of skilled professionals. Its preamble also addressed IRS treatment of consistent positions for earlier years; historical software claims require attention to the separate internal use software guidance.

Uncertainty Based on Information Available to the Taxpayer

Under the revised rules, uncertainty exists when information available to the taxpayer does not establish the capability or method for developing or improving a component, or its appropriate design. Research may use existing technologies and still qualify. However, something being new to the taxpayer is not enough: the experimental activities, permitted purpose, exclusions, and expense requirements still matter.

A modern evaluation of United Stationers could not simply reproduce its profession-wide discovery requirement. That does not establish that its claims would succeed today. The evidence concerning experimentation, the classification of particular software functions, and the remaining statutory requirements would still need examination.

The Impact of FedEx v. United States

In its June 9, 2009 partial-summary-judgment order in FedEx Corp. v. United States, the Western District of Tennessee allowed FedEx to rely on the revised discovery standard together with the internal use software provisions of the 2001 final regulations for the disputed historical years. The court rejected the IRS’s attempt to require the older discovery standard through Announcement 2004-9.

That order resolved the governing legal standards. It did not hold that all FedEx development costs automatically qualified, and it did not reduce § 41 eligibility to only two tests. Claims about a subsequent settlement or a universal government concession should not be inferred from the order.

The 2016 Internal Use Software Regulations: T.D. 9786

T.D. 9786, published October 4, 2016, clarified internal use software, third-party interaction, and dual-function software. Its rules generally apply to taxable years beginning on or after that date, with specified reliance provisions for earlier development periods.

Redefining Internal Use

The regulations focus on software developed for general and administrative functions that facilitate or support the taxpayer’s business, including financial management, human resources management, and support services. Software developed for commercial marketing or qualifying third-party interaction is outside that definition. Intended use at the beginning of development and the relevant facts govern classification.

The Dual-Function Safe Harbor

A separately identifiable subset that only enables third-party interaction is excluded from the internal use presumption. For remaining dual-function software or a dual-function subset, the safe harbor permits inclusion of 25% of otherwise qualified research expenditures if anticipated third-party interaction accounts for at least 10% of use and the other conditions are satisfied.

The estimate must use an objective, reasonable method within the taxpayer’s industry, based on expectations at the beginning of development. Processing time, data transfer, or interface-screen counts may be appropriate. Three customer-interaction screens out of 25 would equal 12%, but that calculation supports the threshold only if screen count reasonably measures the relevant software’s anticipated use. The safe harbor does not automatically qualify 25% of all development spending and is not itself a 25% tax credit.

Modern treatment of software resembling DRRS or Unilink would require examining its intended third-party functions and any separable elements. Customer interaction can change the classification analysis, but it does not establish that an entire integrated system avoids the internal use rules or satisfies the general research tests.

Modern Implications for Documentation and the Process of Experimentation

The old profession-wide discovery standard is absent from current regulations, but a process of experimentation remains essential. A project’s cost, complexity, or use of skilled developers alone does not demonstrate that requirement.

The Siemer Milling Precedent

In Siemer Milling Co. v. Commissioner, T.C. Memo. 2019-37, the Tax Court rejected research-credit claims where the evidence did not establish the necessary process of experimentation. Assertions about engineering or trial and error were insufficient without evidence explaining the actual evaluation of alternatives.

Useful records identify the uncertainty, the alternatives considered, the method of evaluation, the results, and the resulting design decisions. Modeling, simulation, and systematic trial and error are possible methods; every project need not employ all of them or use a single prescribed sequence of formal hypotheses.

Documentation for Software Development Life Cycles (SDLC)

Agile, Scrum, or another development framework can produce useful evidence, but adopting a framework does not prove qualification. Design revisions, technical tickets, test results, engineering notes, and relevant personnel records should connect the component’s uncertainties to the research activities and claimed expenses.

Contemporaneous records are valuable, but no single document format universally determines entitlement. Taxpayers must retain records sufficient to substantiate the credit and follow the filing requirements applicable to the particular year and type of cla