The Docket · Brief · Working level
Eustace v. Commissioner: routine software development is not experimentation
The Seventh Circuit's 2002 affirmance in Eustace denied research credits for an insurance-software company's development work — ordinary coding, debugging, and feature additions are not a process of experimentation, and without evidence separating experimental work, no wages qualify.
Eustace v. Commissioner, T.C. Memo 2001-66, aff'd 312 F.3d 905 (7th Cir. 2002), is the leading authority that software development is not automatically research. Shareholders of Applied Systems, Inc., a maker of agency-management software for insurance agencies, claimed flow-through research credits for the company's development wages. The Tax Court denied the credits and the Seventh Circuit affirmed: the work — adding features, debugging, keeping a mature product current — was competent professional programming, not a process of experimentation under Section 41(d), and the taxpayers offered no evidence separating any genuinely experimental fraction from the routine whole.
The dispute
Applied Systems employed a large development staff continuously improving its established products: new features requested by customers, bug fixes, performance work, and adaptation to changing operating environments. The S corporation's shareholders claimed research credits treating essentially the whole development function as qualified research. The IRS disallowed the credits, arguing the company was doing what every successful software firm does — maintaining and extending a commercial product with known tools and techniques — and that nothing in the record identified projects involving technological uncertainty resolved through systematic experimentation.
The holding
The Tax Court found the development work did not constitute qualified research. The company's programmers were skilled and the work was commercially valuable, but the record showed no hypotheses about technological alternatives, no designed evaluations, and no uncertainty beyond the ordinary challenges of professional software work. The Seventh Circuit, per Judge Easterbrook, affirmed, emphasizing that debugging and incremental enhancement of an existing product line is the antithesis of the pioneering-uncertainty model the credit targets, and that the taxpayers could not carry their burden of showing which activities, if any, were experimentation or what expenses attached to them.
The reasoning that matters
Two propositions carry the case's citation weight. First, the process-of-experimentation prong screens out routine development even when the four-part test's other elements are arguably present: software is technological in nature and a product improvement is a business component, but adding a feature by applying known methods involves no evaluation of alternatives to eliminate uncertainty. The court distinguished hard work from uncertain work — a deadline is not a hypothesis. Second, aggregation kills claims. Because the taxpayers claimed the development function wholesale and offered no way to identify or quantify any experimental subset, the court had no basis to allow a partial credit. This is the substantiation edge of the case: even if some Applied Systems project somewhere involved genuine experimentation, the absence of project-level evidence made the claim indivisible, and an indivisible claim dominated by routine work fails as a whole.
What it means for claims today
Eustace remains the government's anchor citation in software exams a quarter-century on, and its logic reappears in Little Sandy Coal's substantially-all arithmetic. The defensive prescriptions follow directly. Claim at the project or business-component level, not the department level, and be prepared to identify the technological uncertainty each component presented at the outset — a demand now formalized in Section G of the redesigned Form 6765. Exclude, visibly, the maintenance, bug-fix, and adaptation work that Treas. Reg. §1.41-4 and Section 41(d)(4) place outside the credit; a claim that self-screens routine work is far more credible on the experimental remainder. And document the alternatives-and-evaluation story per project, because Eustace's real holding is evidentiary: the taxpayer who cannot separate experimentation from routine development gets the routine-development answer. Note that the qualification question is independent of deductibility — since 2025, domestic software development costs are immediately deductible under Section 174A whether or not they support a credit claim.
Related cases on the site
Norwest is the contemporaneous internal-use software decision; Siemer Milling is the same failure of proof outside software; Suder shows structured software-and-hardware development qualifying on a documented record. See the four-part test explained for the framework, the research credit case law map for the doctrine, and research credit audit defense for meeting an Eustace-based exam position.
Frequently asked questions
- What did Eustace v. Commissioner decide about software development and the research credit?
- Eustace v. Commissioner, T.C. Memo 2001-66, aff'd 312 F.3d 905 (7th Cir. 2002), held that Applied Systems' work enhancing its insurance-agency software — adding features, fixing bugs, porting and maintaining code — was not a process of experimentation under Section 41(d), so the shareholders' claimed credits were denied in full.
- Is software development automatically qualified research?
- No. Eustace is the standard citation for the rule that writing software is not inherently experimentation. Development qualifies only where the taxpayer faced genuine technological uncertainty and can show a systematic process of evaluating alternatives — and can distinguish that experimental work from routine coding, debugging, and maintenance in its records.