Many companies assume that if they built something custom, wrote code nobody else has, spent real money on a project their team is proud of, it must qualify for the R&D tax credit. One of the more instructive cases in this area shows why that assumption is often wrong, and it’s worth understanding before you file, not after an audit letter arrives.
In United Stationers, Inc. v. United States, the nation’s largest wholesale distributor of office supplies modernized its invoicing, pricing, forecasting, ordering, and warehouse systems, all in a single year, and claimed $156,457 in research credit for the work. The IRS denied the claim. USI sued for a refund and ultimately lost at both the district court and the Seventh Circuit. The courts concluded that the company’s projects did not satisfy the statutory requirements for the credit.
USI licensed a base software package and used it as a foundation to write eight custom applications covering invoicing, customer ordering, pricing and marketing, inventory forecasting, and warehouse operations. Some of the systems gave customers limited direct access, order entry and invoice lookups mainly. None of the software was developed for commercial sale.
The court identified three primary reasons.
First, there was no real “discovery.” USI had modified and built on top of existing software rather than expanding or refining the underlying principles of computer science. Using a computer to solve a business problem isn’t the same as researching something new about computers.
Second, and this is the part that trips up the most businesses even today, there was no process of experimentation. USI argued that debugging counted, since it involves testing and fixing code. The court didn’t buy it. Routine debugging, by itself, generally does not satisfy the experimentation requirement.
Here’s where the distinction becomes important. USI’s project records reflected uncertainty about whether customers would adopt the software, whether the investment would generate sufficient returns, and whether the new systems would improve operations. Those were legitimate business questions. The court, however, distinguished those from uncertainty about whether the software could be technically developed. Business uncertainty and technical uncertainty are not the same, and the R&D credit focuses on the latter.
Third, the internal use software rules applied. Because the software primarily served USI’s own operations, the projects faced additional qualification requirements. The court concluded that those requirements had not been met.
One of the more practical lessons from the case is that documentation alone likely would not have changed the outcome. The court’s reasoning focused on whether the projects themselves involved qualifying technical uncertainty, rather than whether the company had sufficient records. Good documentation remains essential, but it cannot compensate for projects that do not otherwise satisfy the statutory requirements.
A few things have shifted since 1998, though it’s worth being precise about what they actually change.
In 2016, the IRS finalized updated internal use software regulations that draw a clearer line for software allowing customers to interact directly with your systems, closer to what Unilink did for USI. That kind of software is no longer automatically folded into the internal use category the way it was here. The same regulations also confirm that a “revolutionary” discovery isn’t required, only genuine technical uncertainty.
More recently, the 2025 tax law created Section 174A, restoring immediate expensing for qualifying domestic research costs. Beginning with 2026 returns, Form 6765 also requires more detailed project-level reporting for many taxpayers. While these developments do not change the fundamental qualification tests, they reinforce the importance of evaluating each project individually before a claim is filed.
If you’re evaluating whether a software project qualifies:
These are exactly the kinds of distinctions that companies often struggle to evaluate internally. Determining whether software development involved qualifying technical uncertainty requires looking beyond the amount of code written or the size of the project.
TaxDrone.AI, built by National Tax Group (NTG), is designed to review projects individually against current IRS standards rather than relying on broad assumptions. The objective is to help businesses understand which projects are likely to qualify before a claim is filed.
Before claiming the R&D tax credit, evaluate whether your software development actually involved qualifying technical uncertainty under today’s rules, rather than assuming customization alone is enough.
Get your free R&D tax credit estimate and understand which parts of your development work are most likely to support a defensible claim.
