Eustace v. Comm’r, T.C. Memo 2001-66

By notices dated July 2, 1996, respondent determined deficiencies and additions to petitioners’ Federal income taxes as follows:

Nicholas Eustace, docket No. 21088-96
Year Deficiency
1992 $3,239
Estate of Thomas A. Eustace, Deceased, Vicky Eustace, Executor,
docket Nos. 21149-96 and 21177-96
Year Deficiency Sec. 6662(a) Addition
1990 $71,505 $14,301
1991 588 —
Estate of Thomas A. Eustace, Deceased, Vicky Eustace,
Independent Administrator and Vicky Eustace, docket No. 21150-96
Year Deficiency
1991 $721
Michael T. Eustace, docket No. 21167-96
Year Deficiency
1992 $3,346
Steven A. and Michelle L. Dye, docket No. 21168-96
Year Deficiency Sec. 6651(a)(1) Addition
1992 $3,388 $147
Robert R. and Elsa M. Eustace, docket No. 21400-96
Year Deficiency Sec. 6662(a) Addition
1990 $219,475 $43,895
1991 44,685 7,850
1992 207,428 41,486

Unless otherwise indicated, all section references are to the Internal Revenue Code for the years in issue, and all Rule references are to the Tax Court Rules of Practice and Procedure. After concessions, the issue is whether petitioners are entitled to the section 41 research credit.


When the petitions were filed, each petitioner or petitioner’s representative resided in Illinois or Indiana. Petitioners were the shareholders of Applied Systems, Inc.
(Applied Systems), an S corporation founded, in 1980, to produce computer software for independent insurance agencies.

Applied Systems had five departments: Programming (i.e., product development), customer services, sales, marketing, and operations. The programming department had four groups, each headed by a vice president: The Agency Manager (TAM), Forms/Interface Module (FIM), rating module, and advanced engineering. Of Applied Systems’ 450 employees, 26 worked on the TAM module, 25 on FIM, and 131 on the rating module. Petitioners claim that Applied Systems paid its employees $2,139,888, $2,363,089, and $3,694,097 of wages relating to the research credit during 1990, 1991, and 1992, respectively.

Applied Systems produced software for processing client and insurance policy information, invoices, insurance claims, standard insurance forms, word processing, marketing, and accounting. Some of the software calculated premiums (i.e., rated policies) and transmitted data between independent agencies and insurance companies (i.e., carriers).


In 1983, Applied Systems released the first version of TAM, a program designed to automate the day-to-day functions of independent agencies. Applied Systems sold TAM directly to such agencies. TAM consisted of three modules: The TAM module, FIM, and First Rate (i.e., rating module). During the years in issue, Applied Systems sold the TAM and FIM modules together as one product and sold First Rate separately. The software ran on IBM compatible personal computers (PC’s) and local area networks (LAN’s).

A. TAM Module

Applied Systems released the first version (i.e., series) of the TAM module in 1983 and the second and third series by 1989. The TAM module enabled an agency to search for prospective clients whose data matched certain criteria, draft personalized sales letters, generate followup reports, dial telephone numbers, track appointments, access First Rate (i.e., to calculate premiums), access FIM (i.e., to fill out forms), process insurance applications, track policy issuance, enter changes and claims, run marketing analysis reports, and process renewals.

In January 1990, Applied Systems released TAM 4.0 for a beta-test (i.e., during which agencies used the software in a working environment to identify problems not discovered during in-house testing). In September 1990, Applied Systems began to develop TAM 4.1, a series for large agencies. In 1991, Applied Systems beta-tested TAM 4.1. Throughout 1992, Applied Systems debugged TAM 4.1 and worked on TAM 5.0. In October 1992, Applied Systems decided to make TAM 4.1 its main product and adjust it for small agencies by deactivating certain features.

Applied Systems made 190 modifications to the TAM module in converting Series 4.0 to 5.0. During the years in issue, the
modifications to the TAM module included the following.

1. Rounding Numbers

Applied Systems’ clients identified rounding errors in the calculation of money amounts. Programmers traced the errors to extra decimal places in the compiler program.

2. Locking Transactions

Applied Systems programmed the TAM module for “locking” (i.e., allowing more than one user at a time to conduct transactions with a particular file).

3. Expanding Representation

Programmers expanded the representation on each byte of memory from 9 to 32 objects (e.g., agencies, branches, or departments), increasing the software’s ability to satisfy the needs of larger client agencies.

4. Managing Memory

Programmers, using software purchased from a third-party vendor, increased the memory available to run the TAM module by transferring some memory contents to disk.

5. Multitasking

Programmers, using software purchased from a third-party vendor, implemented a function, called “Big Interrupt”, that allowed users to perform multiple tasks at one time.

6. Indexing

Programmers, using software purchased from a third-party vendor, developed indexes to locate data in data bases.

B. FIM Module

In 1986, Applied Systems released the first series of FIM. FIM used Agency/Company Organization for Research and Development (ACORD), (i.e., an insurance industry association) standards to print forms and transmit data to carriers. FIM automatically inserted into a form any relevant data from existing client and policy data bases. FIM enabled an agency to send (i.e., upload) forms, and the data thereon, to carriers through an electronic interface. FIM supported single-entry multicompany interface (SEMCI), which allowed an agency to enter data only once and send it to multiple carriers. By 1989, FIM could also receive (i.e., download) data, such as insurance policies.

During the years in issue, Applied Systems integrated FIM with the TAM module by structuring data bases, configuring data, and formatting data and characters for printing. Applied Systems made 55 modifications to FIM in converting Series 4.0 to 5.0.

C. First Rate Module

Prior to the years in issue, the rating module enabled agents to rate personal insurance policies in a dozen States. In late 1988, Applied Systems purchased Alpha Touch, a rating vendor based in Bloomington, Minnesota. Alpha Touch had software that could calculate premiums relating to personal insurance written in the Midwestern States. Applied Systems used the Alpha Touch software to expand First Rate, enabling the module to calculate premiums relating to more carriers, all 50 States, and commercial, as well as personal, insurance.

During the years in issue, Applied Systems’ employees created programs applicable to carriers not already included in First Rate. The employees referred to State regulations and carrier manuals to determine the required data elements and the rating formulas. At the end of 1990, Applied Systems began work on rating programs applicable to commercial insurance. Commercial insurance rating involved more types of insurance coverage than personal insurance. From 1990 through 1992, Applied Systems created approximately 3,000 programs. Applied Systems regularly updated each program to reflect rating formula modifications each carrier made at least once a year.

D. Other Projects

During the years in issue, Applied Systems also worked on data conversion, Independence, WinTAM, Diamond, and evaluations/R&D.

1. Data Conversion

From 1990 through 1992, Applied Systems offered an electronic data conversion service to agencies switching from another automation system to the TAM module. This service
allowed agencies to use the data from their old systems without manually reentering the data into the TAM module. In a typical data conversion, Applied Systems would take the data off the old system, put it on a PC, create a program to transfer the data to data base files needed for the TAM module, and run the program to
transfer the data. In an average week, Applied Systems was converting, in 1990, four systems; in 1991, seven systems; and in 1992, nine systems.

2. Independence

In 1991, Applied Systems purchased Liberty and Leader Systems (i.e., automation vendors that were subsidiaries of carriers) and began the Independence project to integrate the software of these systems with FIM. As a result of the acquisition, Applied Systems added to its user base the customers of Liberty and Leader, based in Georgia and Indiana, respectively. These new customers could convert to the TAM module or retain their existing software, which required integration with FIM. The computer language of Liberty and Leader (i.e., COBOL) was different from that of FIM (i.e., C). Independence involved figuring out how to run FIM with, and pass data to and from, the acquired systems.

3. WinTAM

In 1992, one of Applied Systems’ competitors announced that it would release a Microsoft Windows version of its software by the year’s end. In response, Applied Systems formed a group of employees to develop a version of the TAM module for use in the Windows environment (i.e., WinTAM). Applied Systems decided to keep the TAM module in the old Disk Operating System (DOS) environment, but put it in a Windows format. This decision allowed Applied Systems to bring a Windows version to market before completing the product development. In September 1992, Applied Systems demonstrated an early version of WinTAM at an annual insurance industry convention.

4. Diamond

In the latter part of 1992, Applied Systems started to design an automation system, called Diamond, to serve large carriers (i.e., while the TAM module served independent agencies). Diamond would manage and update policies to reflect customer transactions.

5. Evaluations/R&D

Applied Systems’ evaluations/R&D work consisted of evaluating and developing, by the creation of short routines, compatibility between TAM and third–party hardware and software products.

II. Credit Claimed

On its 1990, 1991, and 1992 tax returns (i.e., Forms 1120S, U.S. Income Tax Returns for an S Corporation), Applied Systems did not claim any research credit. On December 30, 1993, Applied Systems hired a new tax manager, who determined that Applied Systems should claim research credits relating to the years in issue. The tax manager interviewed employees and delineated the employees and activities that he believed qualified for the research credit. On June 24, 1994, and August 30, 1995, Applied Systems submitted amended returns, relating to the 3 years in issue, to claim the respective research credit “that was erroneously omitted from the original filing of the Form 1120S.” On the amended returns, Applied Systems claimed research credits of $235,536, $127,426, and $289,449, relating to the wages of 227 employees in 1990, 1991, and 1992, respectively. Petitioners, pursuant to amended pleadings filed in April 1997, added the wages of 21 employees (i.e., $635,371) to their claim.


I. Definition of Qualified Research

Pursuant to section 41(d)(1), “qualified research” must meet, in pertinent part, the discovery and process of experimentation tests.

A. The Discovery Test

Qualified research must be undertaken for the purpose of discovering information which is technological in nature. Sec. 41(d)(1)(B)(i). In this case, “qualified research” is research that is undertaken to discover information that goes beyond the current state of knowledge in the computer science field. Sec. 41(d)(1)(B); United Stationers, Inc. v. United States, 163 F.3d 440, 444 (7th Cir. 1998); Norwest Corp. v. Commissioner, 110 T.C. 454, 493 (1998). In the context of section 41(d)(1)(B)(i), “discovery demands something more than mere superficial newness; it connotes innovation in underlying principle.” United Stationers, Inc. v. United States, supra at 444.

B. The Process of Experimentation Test

Substantially all of the activities of qualified research must constitute elements of a process of experimentation for a purpose that relates to a new or improved function, performance, reliability or quality. Sec. 41(d)(1)(C), (d)(3)(A). In section 41(d)(1)(C), “substantially all” means at least 80 percent of the activities that constitute a process of experimentation. Norwest Corp. v. Commissioner, supra at 497; sec. 1.41-2(d)(2), Income Tax Regs. A “process of experimentation involves something more than simply debugging a computer program.” United Stationers, Inc. v. United States, supra at 445. In this case, “qualified research” consists of activities at least 80 percent of which constitute a process of experimentation aimed at eliminating uncertainty about the technical ability to develop software. See sec. 41(d)(1)(C); Norwest Corp. v. Commissioner, supra at 496-497; sec. 1.41-2(d)(2), Income Tax Regs.

II. Parties’ Contentions

Respondent contends that Applied Systems did not conduct “qualified research” because its employees did not undertake research to discover information that is technological in nature, and substantially all of the employees’ research activities did not constitute elements of a process of experimentation. Petitioners contend that the section 41(d) definition of “qualified research” requires “only that there be significant programming changes to software”. Petitioners further contend that Applied Systems’ work meets the requirements of the discovery test, because “All computer programming relies on computer science principals [sic]”, and the process of experimentation test, because employees did “consider alternatives when adding additional functionality to the Petitioner’s [sic] computer programs.”

III. Analysis

We note at the outset that petitioners’ reconstruction of qualifying expenses was unreliable, inaccurate, incomplete, and wholly insufficient to establish what various workers did and whether such expenses qualify for the research credit. In addition, petitioners failed to have their computer expert address technical issues relevant to the case, and, as noted below, the testimony of petitioners’ witnesses further supports our conclusion that work performed by Applied Systems’ employees, during the years in issue, does not qualify for the research credit.


Most of the product development of the TAM module occurred during 1980 through 1989. In describing a “sophisticated approach” that Applied Systems had “invented” and used in the TAM module, petitioners’ programmer testified: “This would have been in the ‘80s.” During the years in issue, employees merely updated the TAM module. Solutions to problems of rounding numbers, locking transactions, and expanding representation were commonly known in the computer science field and did not present significant programming challenges. Applied Systems’ purchase and use of third-party software to facilitate managing memory, multitasking, and indexing tasks indicates that these techniques were also known in the computer science field. Petitioners’ programmer testified that he “could immediately know whether something could be made to work or whether it just wouldn’t work.”

Applied Systems’ employees performed the following tasks relating to FIM: Establishing the capability to display business forms, enter data into their blank fields, integrate the data with a data base, and print standard forms. All these tasks were feasible before 1990. Similarly, employees working on First Rate converted State regulations and carrier formulas into programs. This task is part of the normal skilled practice of software development and does not advance or refine any principles of computer science. Petitioners’ computer expert testified, relating to the expansion of the rating module: “It’s hard for me to think about writing each of those programs as constituting research.” Applied Systems’ vice president in charge of First Rate testified: “Really from 1990 to ‘92 there were minor enhancements, modifications to make things easier. There weren’t a lot of major changes.”

In essence, these tasks did not go beyond the current state of knowledge in the computer science field and did not involve a process of experimentation.

B. Other Projects

Petitioners contend that work on data conversion, Independence, WinTAM, and Diamond qualifies for the research credit. We disagree. Data conversion is commonly provided by software vendors. There was no technical uncertainty, for example, that a COBOL program could be rewritten in C, and, by 1990, the principles for converting software from DOS to Windows had been published. Petitioners’ programmer testified that, during the years in issue, Applied Systems did not fundamentally convert the TAM module from DOS, but, as “a simple plan we could do fast”, merely put the TAM module in a Windows format, so “we could start demonstrating something under Windows more quickly”. Applied Systems’ vice president testified, relating to Diamond, that employees were “trying to figure out what the product was supposed to do”, but “weren’t doing any coding” (i.e., programming), during the years in issue. Petitioners presented insufficient evidence relating to evaluations/R&D and failed to address this issue on brief.

IV. Conclusion

Petitioners fell woefully short of presenting sufficient evidence to establish, as required by section 41, that Applied Systems’ activities met the requirements for the research credit. Applied Systems did not undertake research to discover information beyond the current state of knowledge in the computer science field. Nor did Applied Systems conduct a process of experimentation aimed at eliminating uncertainty about the technical ability to develop the software.

Although the TAM module, FIM, First Rate, Diamond, etc. do not meet the requirements of section 41(d)(1), the research credit may, nevertheless, be applicable to the most significant set of elements of these products in relation to which all the requirements are met. See H. Conf. Rept. 99-841 (Vol. II), at II-72 to II-73 (1986), 1986-3 C.B. (Vol. 4) 1, 72-73. Petitioners acknowledge that they do not have the substantiation necessary to tie salaries to activities at the subcomponent level, * * * . However, the Cohen [sic] rule would apply in this circumstance, and the Court would be required to make a reasonable allocation of salaries to functionality.

The rule of Cohan v. Commissioner, 39 F.2d 540, 544 (2d Cir. 1930), does not require the Court, in this case, to make such an allocation, and we decline to do so. Accordingly, respondent’s determinations are sustained.

Contentions we have not addressed are moot, irrelevant, or meritless.

To reflect the foregoing, Decisions will be entered under Rule 155.