If your team built something genuinely new, something customers had never seen before in your market, does that alone earn the R&D tax credit? A Tenth Circuit case involving a small Oklahoma software company says no, and the reasoning behind that answer is more useful than the outcome itself.
Tax and Accounting Software Corporation, known as TAASC, built and sold software to tax and accounting professionals. Between 1993 and 1994, the company developed four products and spent close to $4.3 million on the work, $1,838,756 in 1993 and $2,444,938 in 1994. TAASC claimed a research credit on those costs. The IRS disallowed it, leaving the company’s owner facing tax deficiencies of $123,764 and $192,510. He paid, then sued for a refund.
EasyACCT was an accounting program that fed data into TAASC’s own tax software, and both sides agreed it was unique in the market when it launched. Professional Tax System combined several tax prep tools into one package and was the first commercial product to allow electronic filing with both state and federal governments, while running on modest hardware. EasyTEL handled automated call routing and fax distribution on low-cost equipment. EasyMICR printed banking codes on check stock, and never caught on commercially, eventually getting folded into EasyACCT.
The district court sided with TAASC on summary judgment. The government appealed, and the case turned on two of the five statutory requirements for the credit: whether TAASC’s work involved “discovering information,” and whether it involved a genuine “process of experimentation.”
TAASC argued that discovering information simply meant building something new and useful, while the government argued that the standard required advancing the underlying principles of computer science itself.
The Tenth Circuit rejected both positions. Building something new and useful, by itself, did not automatically satisfy the discovery requirement. At the same time, the court also rejected the government’s view that taxpayers must advance computer science as a field. Instead, the court concluded that the statute required discovering information with value separate from the finished product itself.
Importantly, the court was interpreting the statute and regulations as they existed at the time. As later regulatory guidance evolved, the “discovery” requirement became less central than it was when this case was decided.
Neither TAASC nor the government had argued the case on those terms, so the record did not clearly establish whether TAASC had identified information separate from its software. Rather than deciding the issue outright, the Tenth Circuit sent it back for additional fact-finding.
The process of experimentation issue produced a split outcome.
On one point, TAASC prevailed. The government argued that using generally known programming techniques could never qualify as experimentation. The court disagreed, explaining that trying multiple established methods can still qualify if there is genuine uncertainty at the outset about which approach will succeed.
On the second point, however, TAASC’s position failed. The court distinguished uncertainty about how to achieve a result from uncertainty about whether the result was technically achievable at all. TAASC had acknowledged in its own court filings that it believed its objectives were technically feasible from the outset and that its programmers never questioned whether the products could be built. Those statements proved decisive in the court’s analysis of the experimentation requirement.
So the result was not a straightforward taxpayer victory or loss. The Tenth Circuit reversed the summary judgment entered in TAASC’s favor and remanded the case for further proceedings, while also rejecting the government’s stricter interpretation of the discovery requirement. The decision illustrates both the complexity of the law at the time and the different approaches courts were taking to these issues.
The government’s own interpretation of the discovery requirement was changing while this litigation was still underway.
As the opinion notes, final regulations issued in January 2001 continued to require research to exceed or refine the common knowledge of a field. By December 2001, however, the IRS had already proposed removing that language. Later regulatory developments confirmed that taxpayers do not need to demonstrate a revolutionary discovery to qualify for the credit.
While those changes do not alter the historical significance of TAASC, they do show that today’s framework differs in important respects from the one the court was applying in this case.
TAASC’s problem wasn’t a lack of genuine technical effort, it was that the company’s own characterization of its work, in marketing language and in litigation, undercut the very uncertainty the credit requires. That’s an easy trap to fall into, especially when a business is proud of what it built and describes it that way everywhere, including in the materials that end up supporting a tax filing.
TaxDrone.AI, built by National Tax Group (NTG), helps businesses document technical uncertainty on a project-by-project basis using the type of information the IRS expects to see when evaluating an R&D tax credit claim. The objective is to help companies understand and support qualifying activities before a claim is filed.
Being first to market or more advanced than your competitors doesn’t automatically mean your work meets the legal test for the R&D credit. Knowing the difference, and documenting it correctly, is what makes a claim hold up.
Get your free R&D tax credit estimate to see whether your work is positioned to meet today’s standards.
