# Norwest Corporation and Subsidiaries v. Commissioner > United States Tax Court · June 29, 1998 · 110 T.C. No. 34 URL: https://www.frixlaw.com/law-library/cases/4331808 ## Case - **Court:** United States Tax Court - **Decided:** June 29, 1998 - **Citations:** 110 T.C. No. 34 - **Opinion:** Opinion - **Cited by:** 0 later opinions in the Frix Law Library ## Citator (automated) - No negative treatment found by the automated citator. That is not the same as a confirmation that the case is good law; read the citing cases. - Full citator and citing cases: https://www.frixlaw.com/law-library/cases/4331808 ## How later opinions describe it (automated extraction) - rejecting section 174 deduction for development of experimental house which involved the use of standard construction principles - rejecting section 174 deduction for development of experimental house which involved the use of standard construction principles ## Opinion text 110 T.C. No. 34 UNITED STATES TAX COURT NORWEST CORPORATION AND SUBSIDIARIES, Petitioner v. COMMISSIONER OF INTERNAL REVENUE, Respondent Docket Nos. 13908-92, 20567-93, Filed June 29, 1998. 26213-93.1 Between 1986 and 1991, N, a bank holding company whose affiliates provide banking and other financial services, developed or modified previously developed software for the internal management and administration of its businesses (internal use software). N seeks tax credits for increasing research activities pursuant to sec. 41, I.R.C., with respect to expenditures associated with the development of its internal use software. The parties selected 8 of 67 internal use software activities to serve as representative or sample activities to determine whether all or part of the 67 activities constituted qualified research for purposes of the tax credit. 1 These cases are consolidated for trial, briefing, and opinion solely with respect to the issue of whether petitioner's activities constitute qualified research pursuant to sec. 41, I.R.C. (the research and experimentation credit, or R&E credit). - 2 - Sec. 41(d)(1), I.R.C., sets forth four tests for qualified research: (1) The expenditures must qualify as expenses under sec. 174, I.R.C.; (2) the taxpayer must discover information which is technological in nature; (3) the taxpayer must discover information the application of which is intended to be useful in the development of a new or improved business component; and (4) substantially all of the research activities must constitute elements of a process of experimentation. In the conference report accompanying the Tax Reform Act of 1986 (TRA 1986), Pub. L. 99-514, 100 Stat. 2085, H. Conf. Rept. 99-841 (Vol. II), at II-73 through II-74 (1986), 1986-3 C.B. (Vol. 4) 1, 73-74, Congress set forth three additional tests for qualified research under sec. 41, I.R.C., for the development of internal use software: (1) The software must be innovative; (2) the software development must involve significant economic risk; and (3) the software must not be commercially available. The parties agree that in order for the representative internal use software activities to constitute qualified research for purposes of the tax credit, all seven tests must be satisfied. 1. Held: The three additional tests for qualified research in the development of internal use software enunciated in the conference report accompanying the TRA 1986 require a higher threshold of technological advancement and functional improvement than is necessary in other fields of research. 2. Held, further: One of the eight representative internal use software activities, the development of the Strategic Banking System's (SBS) customer module, satisfies all seven tests and constitutes qualified research pursuant to sec. 41, I.R.C. SBS was a concerted effort at advancing the state of technology in the field of computer science and pushed existing technology to new heights. 3. Held, further: N failed to establish that the remaining seven representative internal use software activities constitute qualified research. - 3 - Mark A. Hager, Albert G. Lauber, Julie W. Davis, Carl S. Kravitz, James Sottile IV, John R. Kalligher, and Matthew W. Frank, for petitioner. Barry J. Laterman, Paul Colleran, Michael Goldbas, Tyrone J. Montague, and Bruce G. Warner, for respondent. CONTENTS Page FINDINGS OF FACT ............................................ 7 1. Background ............................................. 7 2. Software Development Methodology ....................... 8 A. Phase 1: Request .................................. 9 B. Phase 2: Project Initiation ....................... 9 C. Phase 3: Definition ............................... 10 D. Phase 4: Logical Design ........................... 10 E. Phase 5: Physical Design .......................... 11 F. Phase 6: Development .............................. 11 G. Phase 7: Testing .................................. 11 H. Phase 8: Implementation ........................... 12 I. Phase 9: Postimplementation ....................... 12 J. Application of the Software Development Methodology. 13 3. The Eight Sample Internal Use Software Development Activities ............................................. 14 A. Strategic Banking System ........................... 15 B. Trust TU ........................................... 23 C. Success ............................................ 28 D. General Ledger ..................................... 33 E. Money Transfer ..................................... 36 F. Cyborg Payroll ..................................... 42 G. Trust Payment ...................................... 44 H. Debit Card ......................................... 46 OPINION ..................................................... 50 1. Section 41 ............................................. 51 2. Internal Use Software .................................. 56 - 4 - 3. The Seven Tests ........................................ 59 A. The Section 174 Test ............................... 60 B. The Discovery Test ................................. 64 C. The Business Component Test ........................ 69 D. The Process of Experimentation Test ................ 70 E. The Innovativeness Test ............................ 74 F. The Significant Economic Risk Test ................. 76 G. The Commercial Availability Test ................... 77 4. Summary of Internal Use Software Requirements Under the Seven Tests ............................................ 78 5. United Stationers, Inc. v. United States ............... 79 6. The Experts ............................................ 82 A. Petitioner's Expert--Dr. Drew McDermott ............ 83 B. Respondent's Experts ............................... 87 i. Dr. Randall Davis ............................ 87 ii. The Tower Group .............................. 92 7. Analysis of the Eight Sample Activities ................ 97 A. Strategic Banking System ........................... 98 B. Trust TU ........................................... 112 C. Success ............................................ 115 D. General Ledger ..................................... 117 E. Money Transfer ..................................... 118 F. Cyborg Payroll ..................................... 119 G. Trust Payment ...................................... 121 H. Debit Card ......................................... 123 Conclusion .................................................. 125 JACOBS, Judge: By separate notices of deficiency, respondent determined the following deficiencies in petitioner's Federal income taxes: Docket No. Year Deficiency 13908-92 1983 $2,605,571 1984 2,442,134 1985 29,187 1986 19,301,530 20567-93 1987 93,413 1988 3,999,398 - 5 - 26213-93 1989 10,532,064 Respondent also determined additional interest under section 6621(c)2 for 1983, 1984, 1986, 1988, and 1989. Following the filing of petitions contesting respondent's determinations, petitioner engaged Coopers & Lybrand, LLP (Coopers & Lybrand), to ascertain whether it was entitled to credits for increasing research activities pursuant to section 41 (the research and experimentation credit, or R&E credit) between 1986 and 1993 with respect to certain internal use software development activities.3 Coopers & Lybrand concluded that 67 of 118 internal use software development activities petitioner engaged in qualified for the R&E credit. On the basis of the Coopers & Lybrand study, petitioner sought and was permitted to amend its petitions to claim the R&E credit for 1986 through 1989. Subsequently, petitioner again sought and was permitted to amend its petitions in order to carry back the R&E credit from 1990 2 Unless otherwise indicated, all section references are to the Internal Revenue Code as in effect for the years in issue, and all Rule references are to the Tax Court Rules of Practice and Procedure. 3 Petitioner did not claim the R&E credit on any of its U.S. Corporation Income Tax Returns for 1986 through 1991. The engagement of Coopers & Lybrand in August 1994 followed the Department of the Treasury's issuance of proposed regulations that further defined research and experimental expenditures under sec. 174. See sec. 1.174-2, Proposed Income Tax Regs., 58 Fed. Reg. 15821 (Mar. 24, 1993). - 6 - and 1991 to 1989 and to increase the R&E credit for 1986 through 1991. For purposes of trial, briefing, and opinion, the parties have selected 8 of the 67 internal use software development activities to serve as representative or sample activities to determine the outcome of the other 59. The parties agree that $20,552,274 of the $22,658,829 in expenditures claimed by petitioner as associated with the eight internal use software development activities have been substantiated. In addition, the parties agree that the remaining 59 activities are deemed substantiated in the same ratio (90.7 percent) as the 8 sample activities. The parties further agree that if we determine that any of the 8 sample activities qualify for the R&E credit, the remaining 59 activities will be deemed qualified for the credit according to an agreed-upon formula. The sole issue we must decide herein is whether Norwest Corporation & Subsidiaries (petitioner or Norwest) is entitled to the R&E credit with respect to any or all of the eight sample internal use software development activities conducted between 1986 and 1991. Resolution of this issue requires us to interpret and apply the four statutory requirements for the credit provided in section 41, and the three additional requirements provided by Congress in the conference report accompanying the Tax Reform Act of 1986 (TRA 1986), Pub. L. 99-514, 100 Stat. 2085, specifically - 7 - relating to internal use software development activities. H. Conf. Rept. 99-841 (Vol. II), at II-73 through II-74 (1986), 1986-3 C.B. (Vol. 4) 1, 73-74 (and as adopted by the Department of the Treasury in its proposed regulations, section 1.41-4(e)(5), Proposed Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997)). FINDINGS OF FACT Some of the facts have been stipulated and are so found. The stipulation of facts and the attached exhibits are incorporated herein by this reference. Norwest Corporation, a Delaware corporation, is the common parent of an affiliated group of corporations that timely filed consolidated U.S. Corporation Income Tax Returns (Forms 1120) for the years in issue. It is a bank holding company whose affiliates provide banking and other financial services. At the time the petitions were filed, Norwest Corporation had its principal place of business in Minneapolis, Minnesota. 1. Background During the years in issue, petitioner engaged in numerous projects involving the development of internal use software--that is, software developed solely for petitioner's internal business and management purposes. Most of these projects were managed and executed by Norwest Technical Services, Inc. (NTS or Norwest - 8 - Technical Services),4 a wholly owned subsidiary of Norwest Corporation, which employed between 600 and 800 technical personnel, such as computer programmers. NTS occasionally sought the assistance of outside consultants and contractors to provide technical support for its projects. All of the eight sample activities at issue in this case involve software applications. Software enables a computer to perform specific functions by providing instructions to the computer in the form of source code. The source code is written in a programming language, often according to an architectural design, which commands the computer to perform the specific tasks. (A compilation of programs or tasks necessary to operate the software often is referred to as a system.) The source code is then converted, through the use of a compiler, into executable code that is readable by the computer. 2. Software Development Methodology To maintain discipline, structure, and standardization in the software development process, Norwest Technical Services created a formalized approach known as the Software Development Methodology (sometimes referred to as SDM). SDM was developed to prevent the need to "reinvent the wheel" by providing managers with a documented process in developing software. The result was that SDM 4 Norwest Technical Services, Inc., was formerly known as Norwest Information Services, Inc. - 9 - improved controls and managed risks. SDM was applied in developing new software by Norwest personnel and in modifying software purchased from vendors. The SDM procedures were applied to each project activity, with the exception of small maintenance projects that were grouped together for purposes of SDM. SDM involved the following nine phases, which permitted an incremental approach to funding and development: A. Phase 1: Request In the request phase, those seeking the development or modification of the software evaluate the feasibility, cost/benefits, and risks associated with the project. During this phase, the business problem to be solved is described, and potential business and technical solutions are discussed. B. Phase 2: Project Initiation In the project initiation phase, expectations regarding project scope, deliverables, approach, costs, and schedules are agreed upon, documented, and approved. Determinations are made with respect to the skills required to complete the project, and a project team is assembled. Additionally, resource commitments are made for future phases. During this phase, a Project Risk Assessment Form is completed. This form "is used to evaluate the risk associated with completing a project [and] * * * is intended to help the Project Manager determine the kinds of structure and controls that are - 10 - necessary to ensure project success." The form does not measure the project's technical risk. Rather, the form is focused on process risk; that is, whether the experience and skills of the project team will allow completion of the project within the project's parameters, as they have been determined, including time and cost. C. Phase 3: Definition In the definition phase, the business requirements and needs are analyzed and prioritized. Additionally, the project's impact on business and technical functions is reviewed. D. Phase 4: Logical Design In the logical design phase, the design (how it will be done) of the business solution is completed on the basis of the requirements (what needs to be done) set forth in the definition phase. The logical design phase performs a so-called external view of the project (that is, examining the project from a business person's perspective to determine whether the needs of the business can be met) before the development of the technical solution, because the design of the business solution will often constrain the technical solution. Also in this phase, consideration is given to whether the necessary software can be purchased. Finally, an investment decision is made, and the cost/benefit analysis (previously performed in the request phase) is verified. - 11 - E. Phase 5: Physical Design In the physical design phase, which is sometimes referred to as the technical design phase, the technical solution to the business problem described in the logical design phase is determined. The technical approach to building the system requires consideration of the interfaces; that is, how the software operates in conjunction with other applications or systems. During this phase, the tools for building the system are described, as well as the nature of the interfaces between the software and other systems, the estimates of volume that requires processing, and the timeframe for processing. F. Phase 6: Development In the development phase, physical system components are constructed, documented, and verified. During this phase, the programmers write the source code that will allow the computer to perform the required tasks, and initial plans are made for testing the software. G. Phase 7: Testing In the testing phase, the technical development portion of the project is completed. During this phase: (i) Unit testing is performed to determine whether the individual components of a system are technically ready for production, (ii) integrated systems testing is performed to determine whether all components of - 12 - a system can operate together, and (iii) acceptance testing is performed to determine whether the business user's requirements have been satisfied. Further, during this phase, the programmers correct errors in the coding process (known as debugging) as well as in the design process. Typically, the testing known as regression testing is performed on prerecorded data. The use of prerecorded data is important because the testers have known solutions and outcomes against which the software can be tested, and new methods, capabilities, and functions can be tested without risk to real (production) data. H. Phase 8: Implementation In the implementation phase, the software is placed into production (also known as going live), usually in a gradual process. During this phase, the software application is used on actual data by the end users (those who will be using the software product). It is also during this phase that the end users are trained in the use of the software. I. Phase 9: Postimplementation In the postimplementation phase, the software is maintained through continuous debugging, updating, and enhancing to meet new business needs. - 13 - J. Application of the Software Development Methodology The development of software applications does not end with any particular phase of the Software Development Methodology. The process is often iterative in that unanticipated problems are discovered in one phase that require the developers to return to a prior phase. For example, during the testing phase, the developers may learn that the software is not sufficiently scalable; that is, that it cannot handle variances in the volume of data to be processed. In such a case, the project may be returned to the physical design or development phase to reconsider the technical approach or the source code used and, after modifications, resume the testing phase. This iterative process continues until either the software is operational to the satisfaction of those involved or the project is abandoned because of either technical or business constraints. Throughout the SDM process, some form of technical risk (the risk that the project will not succeed for technical reasons) is present, even after the software is placed into production. (The risk of failure exists throughout a project because problems that arise because of volume or scale cannot be resolved until the - 14 - implementation phase.5) Norwest did not maintain any formal, documented method of reporting this technical risk. 3. The Eight Sample Internal Use Software Development Activities During the mid-1980's, Norwest made a concerted effort to expand its banking and financial services business. Between 1986 and 1991, Norwest's assets grew from approximately $20 billion to more than $38 billion (and by 1995, Norwest's assets further grew to over $75 billion). Given the anticipated growth of Norwest's business that was forecast in 1986,6 Norwest Technical Services was assigned the task of determining the necessary data processing support structure and technology to handle this expansion. The eight sample activities, and the substantiated expenses incurred by Norwest with respect to each activity for the years in issue, are as follows: 5 The testing of software for volume or scalability cannot be completed before the implementation phase because of the cost required to replicate a full production environment. 6 In 1986, petitioner expected that most States would liberalize their branch banking restrictions and permit more interstate banking services. - 15 - Activity 1986 1987 1988 1989 1990 1991 Total1 2 Strategic $451,386 $1,367,679 $2,441,576 $2,696,099 $2,260,394 $3,073,334 $12,290,468 Banking System Trust TU 373,469 623,538 551,729 742,462 649,270 650,161 3,590,629 Success --- --- 129,320 138,196 410,030 303,452 980,998 General 173,596 136,735 94,744 384,237 175,020 183,468 1,147,800 Ledger Money 85,179 173,925 193,493 224,109 125,610 180,462 982,778 Transfer Cyborg 73,881 90,923 100,683 74,991 82,056 130,714 553,248 Payroll Trust 93,265 171,334 182,047 101,704 --- --- 548,350 Payment Debit Card --- --- 22,687 435,318 --- --- 458,005 1 The total expenses for the eight activities equals $20,552,276. The $2 discrepancy for the total amount the parties agreed in their stipulation was substantiated is unexplained. 2 The expenses incurred on the Strategic Banking System project for 1986 were contract expenses paid to Electronic Data Systems Corp. A. Strategic Banking System Strategic Banking System (SBS) was a large7 joint effort by three entities to develop an integrated banking system in which a number of software applications would operate together. Electronic Data Systems Corp. (EDS) of Dallas, Texas, and Bank One, Columbus, N.A.8 (Bank One), of Columbus, Ohio, began the SBS project on August 18, 1986. The purpose of the SBS project was to develop a software system in which all information regarding the bank's financial products centered around the customer (the customer 7 By 1993, the three entities involved in developing SBS had incurred approximately $125 million in expenses and written 10 million lines of code. 8 Bank One, Columbus, N.A., is an affiliate of Banc One Corp. - 16 - module) rather than a particular account. Before the development of SBS, information relating to individual bank accounts or other financial products was not linked but rather was maintained in separate systems. Thus, when information about one account was retrieved on a computer, the user would have no way of obtaining information about other accounts owned or maintained by the customer or a related customer. The SBS project sought to change that situation by integrating all account software systems around the customer. The customer module, which would contain basic information about the customer (e.g., name, address, Social Security number, and demographics), would be integrated with deposit and loan (or credit) modules so that information relating to customer deposit and loan accounts could be readily accessed and retrieved. Because of concerns that SBS was becoming specific solely to Bank One's needs, in late 1986 Norwest was asked and agreed to join in the development of SBS to provide more of an industry perspective. In exchange for sharing in the development costs of SBS, Norwest received a perpetual license to use the system.9 9 Norwest paid a base development charge of approximately $6.5 million to Bank One (although the Participant Agreement between Norwest and Bank One required a $7 million payment) in exchange for a percentage of the royalties to be paid to Bank One by Electronic Data Systems Corp. (EDS). Further, Norwest paid $1,750,000 to EDS in exchange for a perpetual license to use SBS. (continued...) - 17 - Before joining the SBS development project, Norwest considered other alternatives. In this regard, Norwest examined commercially available software in the market, considering the products' functionality, economic benefit, scalability, and applicability to interstate banking activities. In particular, Norwest focused on a software product offered by Hogan Systems, Inc. (Hogan). Norwest ultimately rejected the Hogan product because it did not meet Norwest's volume and economic benefit criteria. Norwest also considered building its own system. It abandoned this idea, however, believing that the opportunity to enter into a development project with EDS and Bank One would enable it to achieve its goal and limit its risk. Accordingly, on December 16, 1986, Norwest entered into a Participant Agreement10 with Bank One, and a separate Participant License Agreement with EDS. Section 3.2 of the Participant Agreement between Bank One and Norwest provided for Norwest's role in the development of SBS: In connection with the development of the Financial System by EDS as contemplated under the [EDS-Bank One] Participation Agreement, Norwest will, on a timely basis 9 (...continued) As part of a separate license agreement, Norwest paid EDS $1.2 million to use the software in connection with services provided to nonaffiliated financial institutions. Under the participant and license agreements, EDS maintained all ownership rights to the SBS system. 10 The Participant Agreement was amended on Sept. 8, 1988, Feb. 8, 1992, and again in July 1992. - 18 - as requested by * * * [Bank One] so long as this Agreement shall be in effect: (a) Perform its tasks in connection with the Development Plan including providing banking expertise required from time to time by * * * [Bank One] and provide management decisions and support as reasonably required by * * * [Bank One] to develop the Development Plan. (b) Develop with the cooperation and assistance of * * * [Bank One], test data and test conditions which * * * [Bank One] will use in connection with its obligations with EDS in order to perform system testing designed to establish that each component of the Financial System functions in accordance with the applicable Functional Specifications. (c) Cooperate with * * * [Bank One], and, if requested, with EDS, by, among other things, making available as reasonably requested by * * * [Bank One], office space and services at Norwest's premises, personnel, information, approvals, and acceptances in order that the work required of EDS or of * * * [Bank One] may be accomplished in accordance with the Development Plan. EDS' primary tasks in the development of SBS were to define the technical environment for SBS, to provide the necessary tools for its development and production, and to ultimately construct the system (including the writing of the source code). Bank One's and Norwest's primary tasks were to provide the business requirements for the software (the logical design phase, which was the greatest expense for the participant banks in the SBS project). In addition, Bank One and Norwest provided the technical expertise as to how such systems should operate in a banking environment. - 19 - Ultimately, though, only EDS actually developed the technology and the source code. Bank One and Norwest employees worked with EDS employees to determine the appropriate technical environment, tools, and products for SBS. (At any given time, approximately 100 people from each entity worked on the SBS project.) Employees of the three entities met approximately every 6 weeks to review and critique the work done to date and to recommend changes to the technical design.11 As part of this process, NTS personnel conducted research and proposed solutions to design problems. As part of the logical design phase, EDS technical personnel met with Bank One and Norwest employees to learn about the banking 11 For example, Bank One and Norwest employees raised concerns about whether DB2, a relational database system EDS proposed using for SBS, could handle the volume of data the parties projected would be run on the system. Ultimately, Bank One and Norwest employees conceded that DB2 was appropriate when EDS demonstrated its success in other high-volume environments. Another concern raised by Bank One and Norwest employees related to the use of so-called dummy terminals. EDS proposed maintaining all data in a mainframe computer (which would perform all data processing and run all applications) and placing nonintelligent dummy computers at user stations (e.g., bank teller windows and desks). The dummy computers could access the mainframe's data and software applications through a special menu screen but could not perform any processing functions on their own. Bank One objected to this proposal primarily because it was already using personal computers (PC's), which enabled its users to access data from a host computer, to input new information through software applications processed locally on the PC's, and to ship the new data back to the host computer for updating. (This is known as a client-server architecture.) - 20 - business requirements and needs for the system (a process known as data modeling). The bank employees (e.g., bank tellers) would explain to the EDS personnel the types of functionality (i.e., information) that they needed to access in using the SBS system. Additionally, business analysts at Norwest examined the various functionality requirements of the bank employees and drafted design documents indicating the recommended design approaches or changes. After EDS completed the initial design and development phases, Norwest was used as the test bed for SBS. A large database of sample test data was created, and as early design releases arrived from EDS, Norwest ran SBS in its computer environment to test the software. These tests were conducted on multiple days of transactions to observe the performance of the system over a specific time span. After a test run, the results were analyzed, EDS employees were debriefed, and suggested changes to the design were made. These testing and redesigning phases continued for approximately 3 years in the case of the customer module and for approximately 4-1/2 years in the case of the deposit module. Norwest discovered hundreds of problems in the modules it received from EDS. One problem that arose in the development of the customer module was its interface link to the deposit and loan application systems already in place at Norwest during that time, which was necessary until the new SBS deposit and credit modules - 21 - were developed. Another problem that arose was the development of a so-called pointer system which allowed the end user to access information about a customer through one of various identification sources (e.g., name, account number, Social Security number, etc.). The pointer system was one of the more critical functions of the SBS software. Many of the problems were reviewed and corrected during the testing phase by Norwest technical staff, who would inform EDS personnel of the problems and recommend corrective changes to the software. (A small group of programming experts was assembled specifically to handle the SBS problems through the use of a specialized case tool called PACBASE, which was selected by EDS.) Norwest employed a repeatable testing process to isolate problems and find solutions.12 A running list of these technical problems was maintained in a system provided by EDS. Not all problems were resolved in this process, and often new problems arose from the correction of old ones. Some of the problems that arose in the development of SBS were attributable to poor programming and the 12 This was a particularly difficult process because three different entities were working on the development of SBS. Norwest had to reconcile all of the changes and discover the source of the problems. This process required the isolation of each change made by each entity for testing purposes. Often the attempts to correct one set of problems created new ones. - 22 - delivery of faulty code by EDS; others were attributable to poor technical design. Ultimately, the customer module of SBS was successfully developed (although it contained many bugs). During 1989 and 1990, it was placed into production (the implementation phase) by Norwest in its banks and used for a number of years.13 The deposit module was a technical failure. The failure was attributed to the deposit module's inability to produce the results sought by the users in 13 A test pilot program for the customer module began in Norwest's Duluth, Minnesota, bank in November 1989 and continued through early 1990. After the pilot proved successful, it was implemented throughout 1990 in Norwest's other banks around the country in what was known as release 1.2. During 1991, EDS issued a new upgraded release of SBS which required Norwest to "retrofit" the core functionality and design changes with the customization performed by Norwest in the interim period since the prior release. The upgraded release required a new round of testing and modifications by Norwest technical staff in conjunction with EDS. Many of these changes related to technical problems (such as the source code for the pointer system), and others related to nontechnical cosmetic problems (such as changing the name of a database field or the way a screen looks to the end user, or modifying reports produced by the software). A statement of work dated Oct. 10, 1992, reported: The migration of the Customer system from EDS Release 1.2 to Release 1.3.2 was completed for all Norwest banks using Customer in June of 1992. Installing Release 1.3.2 involved a massive effort of customization, testing and converting the existing data bases to the new release. Since the banks have been using Customer 1.3.2, problems have been identified. - 23 - terms of stability and reliability, as well as its inability to timely process or handle the volume of data required. Because of the failure to adequately develop the deposit module, which was supposed to work in conjunction with the customer module, Norwest abandoned SBS in 1993 and turned to an alternative system created by Hogan. Following a 5-year joint venture with IBM, Hogan developed a customer module system which performed approximately 90 percent of the functions needed by Norwest and met Norwest's critical volume requirement. After the period in issue, both the customer and deposit modules were eventually successfully implemented at Bank One. The record does not indicate the ultimate success or failure of the credit module and its implementation at Norwest or Bank One. B. Trust TU The Trust TU system consisted of a group of software applications designed to maintain trust accounts, including the tracking of assets, purchase and sale of securities, and collection and disbursement of income. The software for this system was purchased from a vendor in 1979 and installed in 1981. Norwest made numerous changes to the system in subsequent years. - 24 - Between 1986 and 1991, Norwest instituted hundreds of projects14 to improve the Trust TU system's functionality (including compliance and regulatory changes) and to reduce processing costs. These projects involved all stages of the Software Development Methodology. Between two and five senior programmers were assigned to accomplish the goal of reducing the monthly cost per trust account that was being maintained. Before 1987, the average monthly cost per account was approximately $9. By 1990, the monthly cost per account was reduced to approximately $4 or $5. The programmers were also assigned the goal of increasing the volume of trust accounts maintained in the Trust TU system. In 1986, there were approximately 25,000 trust accounts running on the system, and the number of trust accounts was increasing by 10 to 12 percent per year. It was assumed that the existing system could not handle more than 30,000 trust accounts. To accomplish both goals (reduction in cost and increased volume), NTS had to increase the speed of the so-called batch process15 that occurred each night. (During the day, the Trust TU 14 Some of the smaller projects included building reports, updating software to reflect regulatory changes, converting acquired bank trusts customers, and changing screens. 15 The batch process consists of editing information, posting information, extracting information, and producing (continued...) - 25 - system was on-line and transactions were stored. Beginning at 6 p.m., the on-line system was shut down, and the trust accounts were updated on the basis of the transactions that had occurred during the day.) There was a maximum 12-hour window to accomplish the batch process. Before the start of the project to increase the speed of the batch process, approximately 10 of the 12 hours of available time for batch processing were being used. To reduce this time and to more efficiently use the mainframe computer's disk space (where the trust account data was stored), NTS needed to determine how to increase the number of processing jobs that could be run concurrently rather than serially. To accomplish this goal, NTS developed a module of as many as 20 processes to determine which batch processing jobs had to be run concurrently and which had to be run serially. This required a determination of those processing jobs that were independent and those that were interdependent. In this respect, the jobs had to be organized in a manner so that no two jobs were updating the same account at the same time. After the module was designed and built, unit testing was performed on a subset of accounts on the mainframe computer. The test outcomes produced varied results. Some of the concurrent jobs 15 (...continued) transactions for the following day. - 26 - ran more slowly than they did as serial jobs, and others ran faster. To determine why some concurrent jobs ran more slowly, the programs that constituted the module had to be reexamined and reorganized using a different approach to the module's design. At times, different modules were considered and used to increase efficiency. Hundreds of test batch processes were performed over a 3-year period to accomplish NTS' goals. Eventually, NTS was able to reduce the total batch processing time to approximately 6 hours. The Trust TU system was abandoned when the number of trust accounts reached 40,000. In 1993, NTS switched to another system (known as Compass) which used newer technology. One of the numerous projects relating to the Trust TU system during the years in issue involved the development of an interface between Norwest's trust system and a vendor-supplied fiduciary tax reporting system called Fasttax. The interface was necessary to transfer trust account information to the tax system in order to calculate the appropriate tax and thereafter send that information back to the trust system in order that checks could be issued and remitted to the various taxing authorities. The primary concerns involved in this interface project were the accuracy of the information coming from Fasttax to the trust system and the ability to process that information in a timely manner for filing tax - 27 - returns. The development of this project followed the SDM, including extensive testing on a separate test bed. Yet another project, the Micro IS system, which was vendor supplied, was designed to automate purchases and sales of investment securities. This portfolio management system permitted a "what-if" analysis whereby the user could examine the impact of hypothetical purchases and sales. When Micro IS was purchased, it was written in Lotus (a spreadsheet program). The processing time, as much as 5 minutes, was unacceptable to NTS. Consequently, NTS suggested to the vendor that the application be written in a "higher" language, such as C, to increase the efficiency of the system. The vendor accepted the suggestion and rewrote the application for Norwest. The result, after an iterative testing process by Norwest taking approximately 6 to 9 months, was the reduction in response time to less than 5 seconds. The Micro IS system required two other notable changes. One was to increase the speed by which data could be extracted from the mainframe computer (which updated the data the night before) and sent to the Micro IS system. The trust portfolio data had to be extracted and loaded on to the Micro IS system from the mainframe each morning by 7 a.m., at which time portfolio managers arrived at work. As a result of this time constraint, the vendor had to rewrite a portion of the system in the C language. Norwest - 28 - conducted iterative testing on its accounts following the vendor's rewriting of the software. The second notable change was to increase the speed by which the purchases and sales of securities by portfolio managers could be sent from the Micro IS system to the Trust TU system. This change required the writing of polling software that essentially checked the Micro IS system every 8 to 10 seconds in order to determine the occurrence of any trades that needed to be sent to the Trust TU system. The increased speed was achieved by writing the program in a language called Clipper, after the rejection of two other languages. Each of these changes resulted in increased efficiency in the use of the Micro IS system both in terms of cost per account and speed of nightly batch processing. C. Success The Success system was designed in-house by Norwest to improve the speed and efficiency of the data processing for Norwest's equipment leasing business. It supported all aspects of leasing activity, including origination of contracts, tracking assets, invoicing customers, tracking collection, accounting, cash management, and off-line reporting. Success was developed between 1988 and 1991 by a group of 15 to 20 people within the Norwest Financial Information Services Group (NFISG), the data processing - 29 - department for Norwest Financial, Inc. (Norwest Financial), a Norwest Corporation subsidiary. Norwest Financial is in the consumer finance business and provides various types of lending products, sales finance, and revolving charge products, as well as data processing services to other unaffiliated consumer finance companies in the industry. Before the development of Success, Norwest Financial Leasing (the subsidiary of Norwest Financial for which Success was developed) used a system known as Infolease for its equipment leasing business which was not meeting its needs. The Infolease system was causing delays for the users with respect to month-end data processing which in turn required the system to be off-line for approximately 3 days. During the time the system was off-line, users had to maintain records manually, and the data could be entered only after the system was on-line and running again. If problems arose in the month-end processing, the system could be down for 7 to 10 days. NFISG lacked the expertise to maintain or enhance the Infolease system. As a result, NFISG was unable to make improvements to that system. The development of Success required NFISG to use the networking of various operating system platforms. In Norwest's leasing offices, where the end users were situated, minicomputers - 30 - were in place. Data would be input into the minicomputers, which would then send the information to a mainframe computer, known as a Tandem system. (The Tandem system was a highly reliable and scalable data processor which stored static data; that is, data which would not change on a regular basis.) The Tandem system would then send a message back to the minicomputers indicating the receipt and update of the new data. If the entered information required number crunching, the Tandem system would send the information to the transaction processing facility (TPF) known as SWIFT.16 These three systems--the minicomputers, Tandem, and the TPF--were all on-line systems, which meant that they were continuously updated and processed in real time, so that the results could be verified immediately. After a transaction or data input was completed, a real-time activity (RTA) record would be created which provided a snapshot of what had occurred. The RTA records would then be written onto a tape which was used to create off-line reporting or month-end batch processing on an IBM MVS system. During the first 6 to 9 months in the development of the Success system, NFISG personnel met with the intended end users of the system to determine their needs. These meetings, which 16 Examples of the processing performed by SWIFT included billing, aging of accounts, earnings calculations, and depreciation. - 31 - continued throughout the design, coding, and testing phases, were designed to ensure a minimum level of functionality in the new system, as well as appropriate improvements from Infolease. As part of this development process, NFISG needed to learn many aspects of Norwest Financial Leasing's business. Additionally, in the early development phases, NFISG studied the Infolease system to determine what data records needed to be maintained. The primary17 technical concern at this point was the TPF system. The existing system was designed to handle "short records"--referring to the size of the transactions--between the mainframe computer and the minicomputers. To obtain the efficiency needed, NFISG sought to create a system that could handle transactions with longer and varying sizes. As a result, NFISG examined the development of a message system that could pass information efficiently.18 Further, NFISG considered the accessibility of the data through direct-access indexing to minimize disk space and increase response time. Additionally, 17 Other issues included human interfacing--the user's ability to navigate through the system according to the screens set up on the system. Additionally, NFISG addressed off-line reporting capabilities of the system. 18 To increase efficiency in the TPF system, NFISG programmed the system using an "assembler-based" language, which is a lower level (i.e., each assembler instruction can be directly interpreted to machine language) and less descriptive language than most other programming languages. - 32 - there was concern over "error recovery" to maintain data integrity --the need to return the system to its state prior to the transaction in the event the transaction process failed. In order to address the problem of error recovery, the technical support staff developed a design through macros (code that is frequently used throughout the system and which, through standardization, ensures data integrity and reliability). All of these technical concerns were addressed and ultimately led to an initial design and conceptualization of the TPF system for Success. Following the development of a basic design of the TPF system, the project was divided into smaller projects and assigned to different analysts. Code development then began, including the development of macros. (Following the coding process, the divided projects were reintegrated for the testing phase.) Additionally, some redesigning occurred upon the discovery of concepts which did not operate as anticipated. Throughout this development phase, unit testing occurred on two separate test beds (one for the TPF system and the other for the IBM MVS reporting system) followed by systems testing (e.g., the TPF with the Tandem system) and acceptance testing for the users. This coding and testing phase lasted 1-1/2 to 2 years. Success was implemented and placed into production following the coding and testing phases, although there was some delay. As - 33 - part of the implementation phase, NFISG was required to convert the data from the Infolease system to the Success system. This required parallel operations of both systems to ensure that the data had been properly converted and that all aspects of the new system were working in accordance with the users' needs. After production began, NFISG sought to improve the response time of the minicomputers in retrieving information. Ultimately, the Success system improved speed and efficiency in the month-end processing, reducing the processing time from 3 or more days to overnight. The Success system was leased out to other leasing companies affiliated with Norwest Corporation. D. General Ledger The General Ledger (G/L) system was an integrated collection of software applications designed to support and maintain Norwest's general ledger accounts and to produce balance sheets, income statements, and other similar reports for Norwest. Approximately five NTS persons were assigned to work on the G/L system. During the years in issue, the corporate controllers who used the G/L system annually met with NTS personnel to discuss their business goals. The primary purpose of these meetings was to discuss ways to improve the source code in order to expedite the month-end closing of the corporate books. - 34 - The G/L system was based on a widely used vendor-supplied package known as Financial Control System (FCS). After purchasing the FCS G/L system, Norwest customized approximately 25 percent of the vendor code. Throughout the relevant time period, NTS needed to upgrade the system and install new vendor releases. This posed problems because of the customization work already conducted by NTS on the vendor code. The upgrading required NTS to study how to "retrofit" the new vendor code with both the old code and the customized code without sacrificing the functionality and efficiency needed. The retrofitting process involved the use of Norwest's SDM and included reiterative unit, integrated, and acceptance testing. The testing usually sought to isolate problems in the code that required debugging or rebuilding. During the retrofitting process, NTS found that the vendor code was inefficient with respect to the corporate consolidation component (consolidating and eliminating transactions of the various corporate divisions) of the software. This problem required a redesigning of the software by NTS. To accomplish this redesign, NTS examined various structures (containers for holding the data) and tools for providing similar functionality as provided in the vendor code but with greater efficiency. - 35 - Another corporate consolidation project involved automating the corporate consolidation process. Before NTS' work, the corporate consolidation process was manual, requiring corporate personnel to examine cost center reports and determine the appropriate location of transactions to appropriate accounts. The automating of the corporate consolidation process through SDM involved four or five technicians conducting extensive testing over a 2-year period. Another project with respect to the G/L involved the on-line component of the system. Every evening, the mainframe computer went off-line and updated the G/L system with transactions that had occurred during the day. However, often during the day the corporate controller's office or other Norwest personnel needed access to the G/L system to obtain on-line updates for ad hoc reporting. This presented a problem because the updating occurred at night--whereas users often needed real-time updates during the day. To accommodate the users' needs, NTS developed a "shadow file" system, which was a secondary set of files, copied from the primary files, that could be used for off-line reporting. As a result of the shadow file system, the users had access to shadow files with real-time updates. The shadow file system presented technical issues for NTS. The shadow file system worked on a DB2 database system which, at - 36 - the time, was new to both the vendor (IBM) and to Norwest. The Norwest users found DB2 to have a slow response time; consequently, as users queried the database files for access to data, the queries became backed up--each query waiting for the query ahead of it to be completed. Although the resolution of this problem was important, it involved no more than basic troubleshooting by IBM and NTS personnel. Another problem, which was similar to the one resolved by the shadow file system, involved the great number of batch jobs processed each evening. Because of the large number of users who wanted reports processed following the evening updating, the mainframe often became locked out (known as getting IO bound) so that jobs requiring access to the same data at the same time could not be completed. As a result, NTS both developed a system that provided multiple data files for the jobs to run against and created a mainframe scheduling system that allowed an organized processing of the batch jobs. There were several other, albeit smaller, projects that were addressed by NTS personnel during the years in issue, ranging from report writer customization to new releases to interface tasks. E. Money Transfer The money transfer, or wire transfer, system was a software package that enabled Norwest to move funds electronically in real - 37 - time from its accounts, through the Federal Reserve System (the Federal Reserve), to the destination financial institutions.19 (The software also permitted transfers from other institutions to Norwest.) During the years in issue, NTS was engaged in many projects20 designed to address Federal Reserve regulatory changes and Norwest's business needs. (Norwest was experiencing a large growth in the wire transfer business--20 percent or more per year.21) 19 To effectuate a wire transfer of funds, Norwest set up a contra account (also known as a due-to/due-from account) with the Federal Reserve. When a Norwest customer wanted to make a transfer, Norwest would debit the customer's account and credit its own account at the Federal Reserve. The Federal Reserve would then debit Norwest's account and credit the destination institution's account. This procedure was used for all domestic wire transfers; international wire transfers did not go through the Federal Reserve. Initially, the wire transfer system used by Norwest did not provide for international wire transferring of funds. International transfers occurred through other, antiquated, systems which were manual and paper based. Norwest converted the international wire transferring to the MoneyNet system, which provided on-line, real-time transfers and validation. This was a large project that took several months of work. 20 Some of the smaller projects included additions and changes to the screen and reporting functions of the system. 21 Norwest was processing approximately $5 to $7 billion in wire transfers per day. The expansion of this business raised critical security issues that had to be addressed any time new technology was instituted. (In fact, Norwest was the victim, on at least one occasion, of a fraudulent wire transfer ring that infiltrated the system.) Thus, any software development was constrained by security concerns. - 38 - The money transfer system was based on vendor-supplied software, known as MoneyNet, purchased by Norwest during the early 1980's. Although the MoneyNet system did not provide all of the functionality Norwest needed, following an assessment of all other software on the market, NTS determined that MoneyNet was the most viable for its long-term needs. In anticipation that changes to MoneyNet would be necessary, Norwest acquired the system's source code from the vendor. The first major regulatory change to affect Norwest was the Federal Reserve's so-called 5 p.m. rule. In general, this rule stated that all wire transfers were to be completed by 5 p.m. each business day. For years prior to 1986, the Federal Reserve did not enforce the rule, staying open as late as necessary to accommodate businesses whose systems failed or which otherwise could not complete their transfers before 5 p.m. But by the late 1980's, the Federal Reserve began strictly to enforce its rule, which required institutions such as Norwest to develop systems that were sufficiently reliable to ensure the timely transfer of the funds. The failure to complete transfers by 5 p.m. could result in severe consequences to Norwest: (1) It would be liable for interest payouts on the funds it was unable to transfer (an estimated $1 million per day); and (2) it would be potentially liable for any - 39 - business deals of its customers that were not completed because it was unable to transfer funds. In response to the Federal Reserve's enforcement of the 5 p.m. rule, NTS examined the timeliness of the MoneyNet system in terms of logging and processing the wire transfers. To protect itself in the event the system crashed, NTS developed a contingency site22 (also known as a disaster site or hot site) in which all logs of wire transfers were copied or mirrored from the production site to a second site in real time. Thus, if the production system failed, the users could simply move over to the contingency site and complete the transfers on that system. At the same time, NTS needed to quickly recover the production system from the point at which it crashed so that the users could continue logging transfers for its customers. The second major Federal Reserve regulatory change affecting Norwest was the so-called daylight overdraft rule. Often, because of the large number of transfers to and from wire institutions, many of which were not settled until the end of each business day, some institutions maintained negative balances in their Federal Reserve accounts during some part of the day, which placed a risk 22 The wire transfer system's lack of a contingency site resulted in Norwest's being cited by the Office of the Comptroller of the Currency and Norwest's internal auditors because of the potential for large losses. - 40 - on the Federal Reserve if the wire transfers were not settled. In general, the daylight overdraft rule stated that the Federal Reserve would not permit wire transfer institutions to maintain balances in their Federal Reserve accounts below a specified minimum level. The same prohibition applied to the bank's customers with respect to their bank accounts from which the wire transfers were coming and going. In response to this rule, Norwest developed (over a 9-month period) two programs (one each for the Federal Reserve accounts and for customer accounts) that monitored the wire transfers and essentially froze all transfers from an account once the minimum credit level was reached. Another project, referred to as the distributed wire project, involved Norwest's attempt to consolidate all wire transfers among its branch locations to one bank location in Minneapolis. Norwest was concerned with the manual, paper-based systems used in its branch banks, particularly in the Des Moines and Omaha branches, which had a history of crashing (which meant the systems were down until repaired) because of too much volume. NTS sought to run all wire transfers on the MoneyNet system. The bank branches were provided with a fault-tolerant system which provided protection against system crashes similar to that used in the 5 p.m. rule project's contingency site system. One technical - 41 - problem with the MoneyNet system addressed by NTS was the software's inability to take into consideration the multibanking environment of Norwest. In this regard, the software did not fully recognize all of the accounting relationships among the different Norwest banks, and thus the accounting records were often incorrect following a wire transfer. NTS allocated five or six technicians to remedy the problem. The technicians mapped out the appropriate accounting entries in order to determine which entries were not properly made following a wire transfer. They then filled in the gaps in the code. Following each change to the code, the changed code was tested and retested. The distributed wire project improved efficiency through the elimination of much of the paper process. It also improved reliability through the fault-tolerant system. During the years in issue, the vendor released upgrades of the MoneyNet software. The installation of these new releases posed compatibility problems for Norwest as a result of prior changes to the code made by NTS. The retrofitting process required a comparison of the new and old vendor codes with the NTS modifications to ensure that the required functionality was maintained. For all of the MoneyNet projects, NTS employed the SDM process, continually testing the modifications to the system to - 42 - ensure that the code worked properly and that functionality was not compromised. F. Cyborg Payroll The Cyborg payroll software was a payroll management system designed to automate the calculation and payment of wages to employees and taxes to Federal, State, and local authorities. It also maintained and processed audit reports of those payments. The Cyborg software was vendor acquired in the late 1970's, although it was originally designed in the mid-1960's. Given the age of the system, much of NTS' effort was focused on "trying to keep it running". Eventually, after the period at issue here, Cyborg was replaced by a payroll system known as Peoplesoft. Cyborg was customized by Norwest to meet its needs, including the need to make nonstandard payments to certain employees and to maintain different types of reports. NTS developed its own "method code" which permitted the users to customize payments or deductions for employees--a function not fully available on the original version of Cyborg.23 During the years in issue, there were as many as 50 discrete service projects with respect to Cyborg. They included: Payroll 23 For example, customization of the various payments and deductions was necessary to reflect different tax withholding rates in different States and to reflect the imposition of local or county taxes in some jurisdictions. - 43 - method code JL--calculating the amount of paycheck deductions for savings and investments plans; Cyborg release 34--implementation of a new vendor release of the system; payroll work facility--a mail station identifier for the users; payroll general ledger reports-- changes to the reports made from the interface with the general ledger; and payroll Cyborg yearend--customizations with respect to the yearend production of documents. Upgrades and new releases were common, particularly with respect to changes in the tax laws that required changes to the payroll system. The many customization projects involved changes to each of the three programs (the edit program, the calculation program, and the print program) that constituted the heart of Cyborg. In using the Software Development Methodology to customize the Cyborg software, NTS reviewed the old and new source codes (obtained from the vendor) to determine where the customized code could be written without sacrificing required functionality. Following the design and development phases, NTS conducted test payroll and reporting runs in order to ensure that the users' needs were met. As part of this process, in order to verify that the results were consistent, NTS tested the system both before and after the changes were made. - 44 - One area that created a problem in customizing Cyborg for Norwest's needs was the programming language for the reporting function. The three main programs of Cyborg were written in an older COBOL language (a common mainframe programming language), but the reporting program was in a language specific to Cyborg which had severe limitations. Moreover, the Cyborg language was not designed for the mainframe systems used at Norwest, but rather for personal computers. Besides customization, NTS was responsible for converting the payroll systems of the banks acquired by Norwest to the Cyborg system. The Cyborg software was not developed specifically to handle conversions of this nature. Consequently, NTS had to determine a means of converting the payroll data, or perform the conversions manually (in the case of small banks). G. Trust Payment The Trust Payment system was created in-house by Norwest in 1987 as a means for making disbursements from pension trust accounts to beneficiaries, maintaining trust account records, and reporting tax-related information. Norwest chose to build this system itself after a determination was made that commercially available trust systems were unable to meet its needs. The Trust Payment system automated many manual processes as well as providing integrated check-cutting capabilities. - 45 - Initially, NTS developed the system using DB2 technology, as indicated supra, a relatively new relational database24 offered and heavily promoted by IBM. Even though NTS had little experience with the technology, NTS used DB2 because it possessed many of the characteristics Norwest needed for its pension system. NTS experienced various problems in building the Trust Payment system. First, the system ran slowly, taking several days rather than only a couple of hours to process data and produce a batch of checks. Second, occasionally, pension checks were issued in negative dollars; that is, pensioners received checks in negative amounts. Third, the system crashed when too many users were seeking to access the same data. Ultimately, these problems were solved by the NTS personnel assigned to this area. After the Trust Payment system was implemented, NTS conducted (over a 2-year period) a thorough review of the system to determine its ability to handle timely the anticipated increase in the number of trust account checks that would need to be issued in the future. This review focused on the use of the DB2 technology and whether there was a means of making the system run faster. (The DB2 system had a reputation for being sluggish.) NTS considered several possible reasons for the slowness of the Trust Payment system but 24 In general, a relational database allows the user to store data in one table which relates to (and can be used with) other tables for reporting and updating purposes. - 46 - was sure of neither the reasons nor the solutions. The process of improving the Trust Payment system required code review, the rewriting of several Trust Payment system functions, and then testing the system to observe the processing time. If the improvements were not satisfactory, NTS went on to other approaches. Throughout this process, NTS received assistance from IBM. Although developed for in-house use by Norwest, the Trust Payment system was examined by two other companies interested in purchasing the system. H. Debit Card The Debit Card software system was built to support the issuance of Norwest's debit card product. A debit card is a financial product that permits payment of point-of-sale purchases directly from the card holder's checking (or other) account.25 To accomplish payment, a number of transactions occur, as follows: Upon presentation of the debit card to a merchant, the transaction is sent to a card association network processor (in this case Visa);26 Visa then seeks to identify the transaction as being made 25 This is as opposed to a credit card system in which the card holder makes purchases against a preestablished line of credit. 26 The card processor, in addition to routing transaction requests to the issuing bank, also performs card holder and (continued...) - 47 - with a particular financial institution's (here Norwest's) product; following recognition of Norwest as the appropriate financial institution, Visa sends a communication to Norwest seeking authorization of the transaction; Norwest then verifies that the card holder has sufficient funds in his or her account to make the purchase, authorizes the transaction, and finally debits the holder's account. Once Norwest decided to enter the debit card market in 1989,27 NTS was under pressure to complete the project by yearend so that Norwest could market the product before its competitors. At the time Norwest entered the debit card market, there were two approaches to issuing the card. The first approach was through a credit card processing system by which a third party handled all of the transactions in a credit-card-like fashion and then sent the transactions to the card issuer (Norwest) for payment and debit.28 26 (...continued) account authentication and transaction authorization. 27 Typically, projects were identified in the year prior to the time Norwest's business units wanted the projects completed. However, in the case of the debit card software project, the decision to enter the debit card market was not made until early 1989, and the goal was to complete the project by the end of that same year. 28 Under this approach, two messages are sent from the merchant: One seeking authorization and one seeking settlement. However, settlement is performed by the credit card processing company in an off-line batch job (which is usually done at (continued...) - 48 - The second approach, the one used by Norwest, involved direct access to the checking (or other) account for debiting, skipping the processing middleman. This latter approach gave Norwest greater control over the product and its use. Although by the late 1980's the credit card processing version of the debit card product had been used throughout the United States, it was not available in the nine States in which Norwest competed--and thus, Norwest chose to use the direct access approach.29 To build the debit card system and links to Visa,30 NTS, which applied Norwest's Software Development Methodology, relied on the Base 24 operating system that ran Norwest's automatic teller machines (ATM's) and the Visanet module, which was jointly developed by Visa and ACI, the vendor of Base 24. The Visanet module was necessary to connect the Base 24 operating system to the Visa debit card system. Norwest was the first bank to acquire, 28 (...continued) night). This requires extension of short-term credit by the issuing bank to the customer, a risk banks generally consider appropriate for 60 to 80 percent of their customers. 29 First Data Resources (FDR), the credit card processor used by Norwest for its credit cards, lacked experience with the debit card product at the time Norwest entered the market. Further, Norwest was not comfortable with FDR's having direct access to its checking accounts. 30 As part of their partnership in developing the debit card system, Visa provided Norwest with technical manuals, transaction simulators, and an access point communications device. - 49 - install, and test the connection of the Visanet module to the Base 24 system for the debit card product. NTS and Visa experienced problems with communications between the two systems. (Two types of communications are necessary for the debit card to operate properly: (1) A communication from Visa to Norwest seeking authorization for a purchase (this is referred to as an on-line transaction); and (2) a communication from Visa to Norwest posting the transaction to the checking account and Norwest's general ledger (known as settlement).) The most significant communication problem was with respect to the transaction posting communication, which often failed entirely-- potentially resulting in customers' purchasing goods and services without having their Norwest accounts correspondingly debited. Because the settlement information was not being received from Visa, NTS had to create its own set of transactions and run them through a test system to ensure that other systems (including the checking account and general ledger systems) that were dependent on the settlement communications operated correctly. This communication problem required a Norwest team of four or five technicians working for 4 or 5 months to redesign the code and retest the system until communications were correctly established. The introduction of the debit card product required several changes to other systems that operated in conjunction with the - 50 - debit card system. Although these changes were relatively minor in comparison to the process of connecting the Visanet module to the Base 24 system, they still required a pattern of trial and error through testing and retesting. Further, because the debit card operated on the same system that operated the ATM card, it was important for the various Norwest systems to recognize that the debit card was a distinct product. Ultimately, the debit card went into production and implementation in January 1990, as scheduled. Norwest entered the market with the debit card approximately 3 months ahead of its nearest competitor, First Bank. OPINION Our task herein is to determine whether any or all of the eight sample internal use software development activities of Norwest constitute qualified research for purposes of the tax credit provided by section 41. The parties agree that section 41 and its legislative history, combined, set forth seven tests to determine whether internal use software development activities constitute qualified research. This is a case of first impression in this Court. However, we are mindful of the recent decision of the District Court for the Northern District of Illinois in United Stationers, Inc. v. United States, 982 F. Supp. 1279 (N.D. Ill. 1997), on appeal (7th Cir., - 51 - Dec. 23, 1997), which addressed the application of section 41 to qualified research in the development of internal use software. We discuss that case infra. 1. Section 41 Section 41,31 captioned "Credit For Increasing Research Activities", provides a nonrefundable credit against a taxpayer's U.S. income tax liability as provided in section 38 (general business credits). Any excess credit may be carried forward or carried back as provided in section 39. The credit is computed as an amount equal to the sum of 20 percent of the excess of the taxpayer's qualified research expenses over a "base amount", and 20 percent of the taxpayer's basic research expenses. Sec. 41(a)-(c). Qualified expenses include those amounts paid for "in-house" research services (i.e., wages) or supplies, or "contract" research by nonemployees. Sec. 41(b). Section 41(d) defines qualified research and provides in part: SEC. 41(d). Qualified Research Defined.--For purposes of this section-- (1) In general.--The term "qualified research" means research-- (A) with respect to which expenditures may be treated as expenses under section 174, 31 The R&E credit under sec. 41 expires on June 30, 1998, with a limited exception. Taxpayer Relief Act of 1997, Pub. L. 105-34, sec. 601(a)(1), 111 Stat. 788, 861. - 52 - (B) which is undertaken for the purpose of discovering information-- (i) which is technological in nature, and (ii) the application of which is intended to be useful in the development of a new or improved business component of the taxpayer, and (C) substantially all of the activities of which constitute elements of a process of experimentation for a purpose described in paragraph (3). * * * * * * * (2) Tests to be applied separately to each business component.--For purposes of this subsection-- (A) In general.--Paragraph (1) shall be applied separately with respect to each business component of the taxpayer. (B) Business component defined.--The term "business component" means any product, process, computer software, technique, formula, or invention which is to be-- (i) held for sale, lease, or license, or (ii) used by the taxpayer in a trade or business of the taxpayer. * * * * * * * (3) Purposes for which research may qualify for credit.--For purposes of paragraph (1)(C)-- (A) In general.--Research shall be treated as conducted for a purpose described in this paragraph if it relates to-- (i) a new or improved function, - 53 - (ii) performance, or (iii) reliability or quality. (B) Certain purposes not qualified.-- Research shall in no event be treated as conducted for a purpose described in this paragraph if it relates to style, taste, cosmetic, or seasonal design factors. Section 41 excludes certain activities from qualifying for the credit, including the development of internal use software--except to the extent provided by regulations or to the extent the software is developed for use in an activity or process that otherwise qualifies for the credit. Sec. 41(d)(4)(E). The R&E credit under section 4132 was first created by Congress as part of the Economic Recovery Tax Act of 1981 (ERTA), Pub. L. 97-34, sec. 221(a), 95 Stat. 172, 227, which provided for a nonrefundable income tax credit for certain research and experimental expenditures paid or incurred by a taxpayer during the taxable year in carrying on a trade or business. The purpose of the credit was to "stimulate a higher rate of capital formation and to increase productivity", S. Rept. 97-144, at 76-77 (1981), 1981-2 C.B. 412, 438-439; H. Rept. 97-201, at 111 (1981), 1981-2 C.B. 352, 32 The tax credit was first designated sec. 44F by the Economic Recovery Tax Act of 1981 (ERTA), Pub. L. 97-34, sec. 221(a), 95 Stat. 172, 227, and was then redesignated sec. 30 by the Deficit Reduction Act of 1984, Pub. L. 98-369, sec. 471(c), 98 Stat. 494, 826, and then sec. 41 by the Tax Reform Act of 1986 (TRA 1986), Pub. L. 99-514, sec. 231(d)(2), 100 Stat. 2085, 2178. - 54 - 358, and to "encourage business firms to perform the research necessary to increase the innovative qualities and efficiency of the U.S. economy", S. Rept. 99-313, at 694 (1986), 1986-3 C.B. (Vol. 3) 1, 694; H. Rept. 99-426, at 177 (1985), 1986-3 C.B. (Vol. 2) 1, 177. ERTA adopted the definitions of "research" and "experimentation" as those terms are generally defined under section 174. ERTA sec. 221(a).33 ERTA failed to address how 33 ERTA sec. 221(a) defined qualified research as follows: For purposes of this section the term "qualified research" has the same meaning as the term research or experimental has under section 174, except that such term shall not include-- (1) qualified research conducted outside of the United States, (2) qualified research in the social sciences or humanities, and (3) qualified research to the extent funded by any grant, contract, or otherwise by another person (or any governmental entity). In TSR, Inc. & Sub. v. Commissioner, 96 T.C. 903 (1991), we considered a taxpayer's claim to the R&E credit under then sec. 44F for 1981. The taxpayer, a manufacturer of historical and fantasy games, sought the credit for its historical research into the development of the games. In considering the taxpayer's claim, we applied the plain meaning to the terms "experimental" ("relating to, or based on [experiment]") and "laboratory" ("a place devoted to experimental study in any branch of natural science or to the application of scientific principles in testing and analysis"). We ultimately rejected the taxpayer's claim because we found that the R&E credit was originally intended by (continued...) - 55 - research expenditures in developing software operated within the credit, but the House report accompanying ERTA indicated that the credit applied only where the costs were "incurred in developing new or significantly improved programs or routines that cause computers to perform desired tasks (as distinguished from other software costs where the operational feasibility of the program or routine is not seriously in doubt)". H. Rept. 97-201, supra at 114, 1981-2 C.B. at 360. This language was not adopted by the conference report which accompanied ERTA. H. Conf. Rept. 97-215, at 223 (1981), 1981-2 C.B. 481, 495. In 1986, Congress became concerned with the lack of an express statutory definition of qualified research in the R&E credit and of taxpayers' abuse of the credit. The Senate Finance Committee report accompanying the Tax Reform Act of 1986 stated: After reviewing available information and testimony on the actual use of the credit to date, the committee believes that the statutory credit provision should set forth an express definition of qualified research 33 (...continued) Congress to apply only to technological discoveries and not historical or other nontechnological research. In Yellow Freight Sys., Inc. & Subs. v. United States, 24 Cl. Ct. 804 (1991), the Court of Federal Claims considered (on a motion for partial summary judgment) whether the taxpayer's development of software programs constituted qualified research under then sec. 44F for 1983 and 1984. That court found that material facts were in dispute, and thus it did not address whether the taxpayer's activities fell within the court's understanding of research and experimentation under sec. 174. - 56 - expenses for purposes of the credit. The committee believes that the definition has been applied too broadly in practice, and some taxpayers have claimed the credit for virtually any expenses relating to product development. According to early data on the credit, the Treasury has reported, many of these taxpayers do not engage in high technology activities. S. Rept. 99-313, supra at 694-695, 1986-3 C.B. (Vol. 3) at 694-695; see also TSR, Inc. & Sub. v. Commissioner, 96 T.C. 903, 919 (1991); H. Rept. 99-426, supra at 178, 1986-3 C.B. (Vol. 2) at 178. Congress amended the R&E credit by TRA 1986 sec. 231(b), 100 Stat. 2173, to provide the definition of qualified research that now is codified in section 41(d). 2. Internal Use Software As part of the 1986 amendment to the R&E credit, Congress addressed the application of the credit to the expenditures paid or incurred in the development of internal use software. Congress did not define what it meant by internal use software, other than to indicate that the phrase refers to software that supports general and administrative functions (such as payroll, bookkeeping, or personnel management) or provides noncomputer services (such as accounting, consulting, or banking services). H. Conf. Rept. 99- 841 (Vol. II), at II-73 (1986), 1986-3 C.B. (Vol. 4) 1, 73. (The parties herein agree that each of the eight sample activities constitutes internal use software.) - 57 - In the conference report accompanying the TRA 1986, the conferees gave the Department of the Treasury responsibility for promulgating regulations relating to the application of section 41 to research with respect to the development of internal use software. In this regard, the conferees stated: The conferees intend that these regulations will make the costs of new or improved internal-use software eligible for the credit only if the taxpayer can establish, in addition to satisfying the general requirements for credit eligibility, (1) that the software is innovative (as where the software results in a reduction in cost, or improvement in speed, that is substantial and economically significant); (2) that the software development involves significant economic risk (as where the taxpayer commits substantial resources to the development and also there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period); and (3) that the software is not commercially available for use by the taxpayer (as where the software cannot be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy the first two requirements just stated). The conferees intend that these regulations are to apply as of the effective date of the new specific rule relating to internal-use software; i.e., internal-use computer software costs that qualify under the three-part test set forth in this paragraph are eligible for the research credit even if incurred prior to issuance of such final regulations. Id. at II-73 through II-74, 1986-3 C.B. (Vol. 4) at 73-74. Congress provided that these rules would be effective to guide taxpayers until the Department of the Treasury issues regulations pursuant to the quoted language. The Department of the Treasury issued proposed regulations with respect to the R&E credit for - 58 - internal use software in January 1997. The regulatory language was nearly identical to that provided in the conference report. Sec. 1.41-4(e)(5), Proposed Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997). Ordinarily, proposed regulations carry no more weight than a position advanced on brief by the Commissioner. F.W. Woolworth Co. v. Commissioner, 54 T.C. 1233, 1265-1266 (1970). However, with regard to the R&E credit under section 41, Congress has specifically expressed its position with respect to the three internal use software tests. Thus, we look to the tests as an expression of legislative intent rather than a position of the Commissioner. The proposed regulations add two features worthy of note that are not expressly provided in the conference report accompanying the TRA 1986. First, the regulations provide that all facts and circumstances shall be considered in determining whether a taxpayer satisfies the requirements for qualified research in the development of internal use software. Second, the regulations require that the software meet a "high threshold of innovation" to obtain the credit under section 41. Sec. 1.41-4(e)(6), Proposed Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997). - 59 - 3. The Seven Tests The parties agree that the combination of section 41 and the conference report accompanying the TRA 1986 results in a total of seven tests that taxpayers must satisfy to obtain the R&E credit with respect to qualified research in the development of internal use software:34 (1) The section 174 test (the research expenditures must qualify as expenses under section 174);35 (2) the discovery test (the research must be undertaken for the purpose of discovering information which is technological in nature); (3) the business component test (the research must be undertaken for the purpose of discovering information the application of which is intended to be useful in the development of a new or improved business component of the taxpayer); (4) the process of experimentation test (substantially all of the activities which constitute elements of a process of experimentation must relate to a new or improved function, performance, reliability, or quality); (5) the innovativeness test (the software must be innovative (as where the software results in a reduction in cost, or improvement in speed, that is substantial and economically significant)); 34 Tax credits are a matter of legislative grace, and the taxpayer bears the burden of proving entitlement to the credits. Rule 142(a); Interstate Transit Lines v. Commissioner, 319 U.S. 590, 593 (1943); Segel v. Commissioner, 89 T.C. 816, 842 (1987). 35 Sec. 41(d)(1)(A) provides that "qualified research" means research "with respect to which expenditures may be treated as expenses under section 174". We believe that the statutory phrase "may be treated as expenses under section 174" means that the expenditures must "qualify" for the deduction under sec. 174. See infra. - 60 - (6) the significant economic risk test (the software development must involve significant economic risk (as where the taxpayer commits substantial resources to the development and also there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period)); and (7) the commercial availability test (the software must not be commercially available for use by the taxpayer (as where the software cannot be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy tests (5) and (6))). These seven tests, however, must be applied with an understanding of some of the terminology used by Congress which is not defined. To understand these tests, we will rely on the ordinary meaning of the language used in the statute, see Commissioner v. Soliman, 506 U.S. 168, 174 (1993); United States v. American Trucking Associations, Inc., 310 U.S. 534, 543-544 (1940), as well as the legislative history surrounding the promulgation of the TRA 1986, see Landgraf v. USI Film Prods., 511 U.S. 244 (1994); Trans City Life Ins. Co. v. Commissioner, 106 T.C. 274, 299 (1996). A. The Section 174 Test The section 174 test requires that the research expenditures qualify as expenses under section 174. Section 174 generally allows as a current deduction research and experimental expenditures which are paid or incurred by the taxpayer in connection with the operation of a trade or business. Section 174 does not define the phrase "research and experimental", but the applicable regulations require that the expenditures represent - 61 - research and development costs "in the experimental or laboratory sense". Sec. 1.174-2(a)(1), Income Tax Regs. The regulations further provide: Expenditures represent research and development costs in the experimental or laboratory sense if they are for activities intended to discover information that would eliminate uncertainty concerning the development or improvement of a product. Uncertainty exists if the information available to the taxpayer does not establish the capability or method for developing or improving the product or the appropriate design of the product. Whether expenditures qualify as research or experimental expenditures depends on the nature of the activity to which the expenditures relate, not the nature of the product or improvement being developed or the level of technological advancement the product or improvement represents. T.D. 8562, 1994-2 C.B. 30, 31.36 "Product" refers to any pilot, model, process, formula, invention, technique, patent, or similar property. Sec. 1.174-2(a)(2), Income Tax Regs. On brief, respondent concedes that the expenditures associated with all eight of the sample internal use software activities "may be treated as expenses under I.R.C. § 174" (emphasis added), the language used in section 41(d)(1)(A). Respondent asserts that it is the Commissioner's policy not to disturb a taxpayer's method of accounting with regard to computer software expenditures if the 36 The 1994 regulations under sec. 174 are effective for all taxable years after Oct. 3, 1994. Because the amendments provided in the 1994 regulations only clarify the definition of research or experimental expenditures, retroactivity was unnecessary. 59 Fed. Reg. 50159, 50160 (Oct. 3, 1994). - 62 - requirements of Rev. Proc. 69-21 are satisfied. Rev. Proc. 69-21, 1969-2 C.B. at 303, states that "The costs of developing software * * * in many respects so closely resemble the kind of research and experimental expenditures that fall within the purview of section 174 * * * as to warrant accounting treatment similar to that accorded such costs under that section."37 Respondent notes that his concession of the section 174 test "does not mean, however, 37 The 1983 proposed regulations under sec. 174 provided extensive language and examples relating to the treatment of the development of computer software. The proposed regulations provided that the term "research or experimental expenditures" included the costs for developing "new or significantly improved computer software. The term does not include costs paid or incurred for the development of software the operational feasibility of which is not seriously in doubt." Sec. 1.174- 2(a)(3), Proposed Income Tax Regs., 48 Fed. Reg. 2799 (Jan. 21, 1983). This language appears to have been derived from the House report accompanying ERTA, which discussed the treatment of computer software development under the R&E credit (under then sec. 44F). H. Rept. 97-201, at 114 (1981), 1981-2 C.B. 352, 360. The treatment of computer software in the 1983 proposed regulations was criticized by commentators because the proposed regulations treated computer software differently than other products, imposing a more difficult test. 54 Fed. Reg. 21225 (May 17, 1989). The 1989 proposed regulations removed the controversial language and stated that computer software was to be treated the same as other products. Id. at 21227. Although Notice 87-12, 1987-1 C.B. 432, indicated that the IRS intended to issue regulations further explaining the treatment of computer software under sec. 174, no regulations were forthcoming. The 1993 proposed regulations only indicated that no additional conditions were to be imposed on computer software development activities, and that taxpayers could continue to rely upon Rev. Proc. 69-21, 1969-2 C.B. 303. The 1994 final regulations are silent altogether. Sec. 1.174-2, Proposed Income Tax Regs., 58 Fed. Reg. 15821 (Mar. 24, 1993). - 63 - that respondent concedes that petitioner has met the requirements of I.R.C. § 174, which is simply not an issue in this case." Petitioner objects to respondent's claim that its expenditures "may be treated" as expenses under section 174 without in fact meeting the section's requirements for a deduction. Petitioner hazards a guess that respondent wants to have it both ways; that is, respondent wants to avoid an adverse ruling on the issue (and its potential impact on other tests under section 41) without conceding that the section 174 requirements are actually satisfied. We believe that the phrase "the research expenditures may be treated as expenses under section 174" is meant to require the taxpayer to satisfy all the elements for a deduction under section 174. The legislative history of section 41 supports this requirement. See H. Conf. Rept. 99-841 (Vol. II), supra at II-71, 1986-3 C.B. (Vol. 4) at 71 ("the conference agreement limits research expenditures eligible for the incremental credit to 'research or experimental expenditures' eligible for expensing under section 174. * * * Under the conference agreement, research satisfying the section 174 expensing definition is eligible for the credit"). Thus, on the basis of respondent's concessions, each of petitioner's eight sample activities satisfies the elements for a deduction under section 174. - 64 - B. The Discovery Test The discovery test requires that the research be undertaken for the purpose of discovering information which is technological in nature. In the conference report accompanying the TRA 1986, Congress explained the discovery test as follows: The determination of whether the research is undertaken for the purpose of discovering information that is technological in nature depends on whether the process of experimentation utilized in the research fundamentally relies on principles of the physical or biological sciences, engineering, or computer science3-- in which case the information is deemed technological in nature--or on other principles, such as those of economics--in which case the information is not to be treated as technological in nature. For example, information relating to financial services or similar products (such as new types of variable annuities or legal forms) or advertising does not qualify as technological in nature. 3 Research does not rely on the principles of computer science merely because a computer is employed. Research may be treated as undertaken to discover information that is technological in nature, however, if the research is intended to expand or refine existing principles of computer science. H. Conf. Rept. 99-841 (Vol. II), supra at II-71 through II-72 & n.3, 1986-3 C.B. (Vol. 4) at 71-72 & n.3. The purpose of the discovery test is to limit the type of information discovered to that which is technological in nature, as opposed to nonscientific information, such as in the fields of the social sciences, arts, or humanities, that is specifically excluded by section 41(d)(4)(G). See TSR, Inc. & Sub. v. Commissioner, 96 - 65 - T.C. 903 (1991). Additionally, the test is intended to limit the form of discovery to the "process of experimentation", which is defined elsewhere by the conference report accompanying the TRA 1986 and which is discussed infra. Congress did not statutorily define the word "discovery". Petitioner asserts on brief that "discovery" has the same meaning as in the regulations under section 174, see sec. 1.174-2(a)(1), Income Tax Regs., directing the Court to the structure of section 41(d)(1)(B). Consequently, petitioner contends, if Norwest's activities satisfy the section 174 test, there is no need to address whether Norwest performed discovery in the context of the second test. Respondent contends that the discovery tests under sections 174 and 41 are different. For several reasons, we agree. First, the discovery test under the section 174 regulations was not adopted until 1994, 8 years after the discovery test in section 41 was created in the TRA 1986--thus, we find it difficult to conclude that Congress intended the tests to have the same meaning. Second, the discovery test under the section 174 regulations relates to "uncertainty concerning the development or improvement of a product". The discovery test under section 41, on the other hand, relates to information which is "technological in nature" and which "fundamentally relies on principles of the [hard sciences]". Thus, - 66 - the tests relate to the discovery of different information. Finally, we note that the legislative history of section 41 reveals that in 1986, Congress sought to tighten the requirements for obtaining the R&E credit because taxpayers were not using the credit for high technology purposes. H. Rept. 99-426, at 178 (1985), 1986-3 C.B. (Vol. 2) 1, 178; S. Rept. 99-313, at 694 (1986), 1986-3 C.B. (Vol. 3) 1, 694-695. Congress effectuated this goal by adding three tests to section 41, including the discovery test, but did not change the meaning of section 174 (and presumably the discovery test subsequently created under the section 174 regulations). H. Conf. Rept. 99-841 (Vol. II), supra at II-76, 1986-3 C.B. (Vol. 4) at 71, 76; see also S. Rept. 97-144, at 81 (1981), 1981-2 C.B. 412, 441. We therefore conclude that Congress intended to treat the discovery test under section 41 more narrowly than the discovery test created under section 174. The dictionary definition of "discover" is "to make known or visible" or "to obtain sight or knowledge of for the first time". Webster's Ninth New Collegiate Dictionary (1985). The legislative history of section 41 dictates that the knowledge gained from the research and experimentation must be that which exceeds what is known in the field in which the taxpayer is performing the research and experimentation--in this case, the computer science field. The fact that the information is new to the taxpayer, but not new to - 67 - others, is not sufficient for such information to come within the meaning of discovery for purposes of this test. The purpose of the R&E credit was to stimulate capital formation and improve the U.S. economy--not merely the taxpayer's business. See H. Rept. 97-201, at 111 (1981), 1981-2 C.B. 352, 358; H. Rept. 99-426, supra at 177, 1986-3 C.B. (Vol. 2) at 177. The legislative purpose of the discovery test in section 41 was to narrow the scope of the research and experimentation under section 174 to that which is technological in nature. The technological-in-nature requirement is consistent with Congress' concern that the R&E credit was not being used for high technology research before the 1986 amendments. S. Rept. 99-313, supra at 694-695, 1986-3 C.B. (Vol. 3) at 694-695; H. Rept. 99-426, supra at 178, 1986-3 C.B. (Vol. 2) at 178. Thus, Congress specifically stated that the discovery process must fundamentally rely on principles of the hard sciences--namely, physical or biological sciences, engineering, or computer science. The parties dispute the significance of note 3 of the conference report, H. Conf. Rept. 99-841 (Vol. II), supra at II-71 n.3, 1986-3 C.B. (Vol. 4) at 71 n.3, accompanying the TRA 1986. That footnote states that the research must "expand or refine" the principles of the hard sciences. Respondent contends that the phrase "expand or refine" is meant to explain the nature of the - 68 - discovery required by the taxpayer, noting the legislative history of section 41. On the other hand, petitioner contends that "expand or refine" is only illustrative and is intended to contrast the mere use of a computer which in and of itself does not necessarily involve fundamental reliance on the principles of computer science. We believe the purpose of the first sentence of note 3 ("Research does not rely on the principles of computer science merely because a computer is employed.") is to emphasize that Congress intended the R&E credit not for the use of the hard sciences per se, but for the use of the principles of the hard sciences in conducting research. "Principle" is defined as "a comprehensive and fundamental law, doctrine, or assumption". Webster's Ninth New Collegiate Dictionary (1985). Clearly, the use of a computer does not necessarily require reliance on any fundamental laws, doctrines, or assumptions. The purpose of the second sentence of note 3 ("Research may be treated as undertaken to discover information that is technological in nature, however, if the research is intended to expand or refine existing principles of computer science.") is to indicate that the taxpayer must discover information with respect to the principles of the hard sciences on which it fundamentally relies. Note 3 sets forth two means of discovering information about the principles of the hard sciences--either by "expanding", or by "refining"--either - 69 - or both of which allows the taxpayer "to make known or visible" or "to obtain sight or knowledge for the first time", the definition of discovery discussed above. Congress' goals of stimulating a higher rate of capital formation and improving the U.S. economy cannot be achieved unless the taxpayer goes beyond the preexisting knowledge of the principles of the hard sciences. Expanding or refining those principles are two, but not the exclusive, ways of satisfying these goals.38 C. The Business Component Test The business component test (which is actually part of the discovery test) requires that the research be undertaken for the purpose of discovering information the application of which is intended to be useful in the development of a new or improved business component of the taxpayer. This test was addressed by Congress as follows: Under the conference agreement, research is treated as conducted for a functional purpose only if it relates to a new or improved function, performance, reliability, or quality. (Activities undertaken to assure achievement of the intended function, performance, etc. of the business component after the beginning of commercial production of the component do not constitute qualified 38 Respondent relies on the language in TSR, Inc. & Sub. v. Commissioner, 96 T.C. 903 (1991), in which we stated that the technological-in-nature requirement amounted to a requirement of a "technological breakthrough". Id. at 920. Inasmuch as TSR, Inc. did not involve the R&E credit as it exists under sec. 41, we do not consider that language an element of the discovery test. - 70 - experimentation.) The conference agreement also provides that research relating to style, taste, cosmetic, or seasonal design factors is not treated as conducted for a functional purpose and hence is not eligible for the credit. H. Conf. Rept. 99-841 (Vol. II), supra at II-72, 1986-3 C.B. (Vol. 4) at 72. The parties do not seriously dispute the meaning of the business component test or the legislative history. Indeed, it is evident that Congress intended only that the taxpayer's activities provide some level of functional improvement, at a minimum. D. The Process of Experimentation Test The process of experimentation test requires that substantially all of the activities which constitute elements of a process of experimentation relate to a new or improved function, performance, reliability, or quality. The process of experimentation test, which is referenced in the discovery test, is explained by Congress as follows: The term process of experimentation means a process involving the evaluation of more than one alternative designed to achieve a result where the means of achieving that result is uncertain at the outset. This may involve developing one or more hypotheses, testing and analyzing those hypotheses (through, for example, modeling or simulation), and refining or discarding the hypotheses as part of a sequential design process to develop the overall component. Thus, for example, costs of developing a new or improved business component are not eligible for the credit if the method of reaching the desired objective (the new or improved product characteristics) is readily - 71 - discernible and applicable as of the beginning of the research activities, so that true experimentation in the scientific or laboratory sense would not have to be undertaken to develop, test, and choose among the viable alternatives. On the other hand, costs of experiments undertaken by chemists or physicians in developing and testing a new drug are eligible for the credit because the researchers are engaged in scientific experimentation. Similarly, engineers who design a new computer system, or who design improved or new integrated circuits for use in computer or other electronic products, are engaged in qualified research because the design of those items is uncertain at the outset and can only be determined through a process of experimentation relating to specific design hypotheses and decisions as described above. H. Conf. Rept. 99-841 (Vol. II), supra at II-72, 1986-3 C.B. (Vol. 4) at 72. Unlike the regulations under section 174, which are silent about the means of discovering information, the conference report accompanying the TRA 1986 made it clear that a more structured method of discovery is required with respect to section 41. By requiring that at the outset uncertainty exist about the ability to develop the product in the scientific or laboratory sense, the process of experimentation test is aimed at eliminating uncertainty about the technical ability to develop the product--as opposed to uncertainty as to whether the product can be developed within certain business or economic constraints, even though the taxpayer knew that it was technically possible to develop it. As evidence of the required uncertainty, Congress mandated the evaluation of more than one alternative, which in turn may require - 72 - the use of a structured process of experimentation through the continuous development of hypotheses that require testing and analysis until the method for reaching the objective is discovered. Congress did not specify that any particular number of hypotheses be developed by the taxpayer, but the more hypotheses that are developed, tested, and analyzed, the more likely the project will satisfy the process of experimentation test. This test also requires that "substantially all" of the activities constitute elements of a process of experimentation. This requirement raises two questions: (1) What does the term "substantially all" mean? and (2) what activities come within the elements of a process of experimentation? Respondent contends that "substantially all" means at least 80 percent, referring to section 1.41-2(d)(2), Income Tax Regs., which defines the term "substantially all" with respect to qualified wages under section 41 as meaning at least 80 percent of the wages paid or incurred by the taxpayer for the employee. Petitioner does not dispute respondent's proposed 80-percent test. We agree with respondent and hold that in the context of section 41, the term "substantially all" refers to at least 80 percent of the activities that constitute elements of a process of experimentation. This interpretation is consistent with the - 73 - existing definition of "substantially all" in the regulations under section 41 with respect to qualified wages. Congress indicated in the conference report accompanying the TRA 1986 those elements which constitute a process of experimentation. They include the developing, testing, and analyzing of hypotheses. They do not include activities performed after commercial production or implementation or otherwise set forth in section 41(d)(4). See H. Conf. Rept. 99-841 (Vol. II), supra at II-72, 1986-3 C.B. (Vol. 4) at 72. However, in the case of internal use software, exceptions are made for the modifications of commercially available software. See infra. Thus, at least 80 percent of the activities engaged in by a taxpayer with respect to the preproduction or implementation development of a product must involve the development, testing, and analysis of hypotheses that are designed to eliminate technical uncertainty as to the development of that product. This then raises the issue of which activities in a project are to be examined together and which are to be examined separately for purposes of section 41. Congress has provided us with some guidance in a so-called shrinking back test: The term business component means a product, process, computer software, technique, formula, or invention that is to be held for sale, lease, or license, or is to be used by the taxpayer in a trade or business of a taxpayer. If the requirements described * * * [in the first four tests under section 41] are not met with - 74 - respect to a product, etc. but are met with respect to one or more elements thereof, the term business component means the most significant set of elements of such product, etc. with respect to which all requirements are met. Thus, the requirements are applied first at the level of the entire product, etc. to be offered for sale, etc. by the taxpayer. If all aspects of such requirements are not met at that level, the test applies at the most significant subset of elements of the product, etc. This "shrinking back" of the product is to continue until either a subset of elements of the product that satisfies the requirements is reached, or the most basic element of the product is reached and such element fails to satisfy the test. Treasury regulations may prescribe rules for applying these rules where a research activity relates to more than one business component. H. Conf. Rept. 99-841 (Vol. II), supra at II-72 through II-73, 1986-3 C.B. (Vol. 4) at 72-73. We conclude that the shrinking back test must be examined on a case-by-case basis to determine which activities are part of the same product or process, and which are so discrete as to warrant a separate evaluation. E. The Innovativeness Test The innovativeness test requires that the software be innovative "as where the software results in a reduction in cost, or improvement in speed, that is substantial and economically significant". Id. at II-73, 1986-3 C.B. (Vol. 4) at 73. The parties disagree over the meaning of the innovativeness test. Respondent contends that the legislative history of section 41 mandates that we require a "high threshold of innovation", the phrase that appears in the House and Senate reports accompanying the TRA 1986, S. Rept. 99-313, at 694-695 (1986), 1986-3 C.B. (Vol. - 75 - 3) 1, 694-695; H. Rept. 99-426, at 178 (1986), 1986-3 C.B. (Vol. 2) 1, 178, and as used by the Department of the Treasury in its proposed regulations, section 1.41-4(e)(6), Proposed Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997). Further, respondent asserts that we should read this and the other internal use software tests narrowly inasmuch as they are exceptions to the general rule that internal use software activities are not eligible for the R&E credit. Sec. 41(d)(4)(E). Petitioner argues that the language in the innovativeness test is straightforward and that we should focus on its plain meaning. Petitioner analyzes the meaning of "substantial" and "significant" to reach the conclusion that these words connote a range of 5- to 20-percent improvement in the product or process. In support of this conclusion, petitioner cites several statutes, regulations, and Nabisco Brands, Inc. & Consol. Subs. v. Commissioner, T.C. Memo. 1995-127 (applying 25 percent in the context of section 1253(b)(2) and discussing the various statutes and regulations which define the term "substantial"). We do not believe that quantifying by way of a percentage that which is "substantial" and "significant" will materially assist us in determining whether the innovativeness test is satisfied. Suffice it to say, the extent of the improvements required by Congress with respect to internal use software is much greater than that required in other fields. The business component test (the third of the seven tests, which applies to all research and - 76 - experimentation under section 41) requires only a "new or improved" function, whereas the innovativeness test (which applies only to internal use software development) requires change "that is substantial and economically significant". H. Conf. Rept. 99-841 (Vol. II), supra at II-73, 1986-3 C.B. (Vol. 4) at 73 (emphasis added). We therefore agree with respondent that only a "high threshold of innovativeness" will satisfy this requirement. F. The Significant Economic Risk Test The significant economic risk test requires that the software development involve significant economic risk "as where the taxpayer commits substantial resources to the development and also there is substantial uncertainty, because of technical risk, that such resources would not be recovered within a reasonable period". Id. Petitioner contends that the significant economic risk test requires that only a 20-percent risk need exist, because of technical uncertainty, to prevent the taxpayer from recovering its investment within a reasonable period of time. Petitioner reaches this conclusion on the basis of the same analysis it used with respect to the innovativeness test. Respondent, on the other hand, emphasizes the magnitude of the technical risk as a key factor in analyzing the internal use activities under this test. Again, we find significant Congress' requirement of a substantial uncertainty. In both the contexts of the regulations under section 174 and the explanation of the process of experimentation test provided in the conference report accompanying - 77 - the TRA 1986, only uncertainty is required. The use of the word substantial here requires a further step in the context of the development of internal use software. As in the case of the innovativeness test, we believe the significant economic risk test requires a higher threshold of technological advancement in the development of internal use software than in other fields. G. The Commercial Availability Test The commercial availability test requires that the software not be commercially available for use by the taxpayer "as where the software cannot be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy [tests (5) and (6)]". Id. Although this language is fairly self- explanatory, respondent argues that a taxpayer's expenses incurred in the implementation of vendor releases of commercially available software can never satisfy this final test because the releases are commercially available. We refuse to adopt such a bright-line rule. Congress clearly anticipated that some modifications to commercially available software can satisfy the fifth and sixth tests of our seven-test analysis. We must examine those modifications, including any modifications resulting from the implementation of commercially available software, on a case-by-case basis. - 78 - 4. Summary of Internal Use Software Requirements Under the Seven Tests The higher threshold of technological advancement and functional improvement in the development of internal use software vis-a-vis other fields of research is consistent with the general rule that qualified research under section 41 excludes internal use software development. Sec. 41(d)(4)(E). Although the reasons for such discrimination are not readily apparent, they nonetheless do exist. The conclusion we draw from these higher threshold requirements is that Congress sought to limit the development of internal use software under section 41 only to those endeavors that ventured into uncharted territory.39 We are mindful, however, that 39 We recognize that commentators to the 1983 and 1989 proposed regulations under sec. 174 were concerned with language that could discourage the "evolutionary" nature of research. The Explanation of Provisions in the 1989 proposed regulations to sec. 174 states in pertinent part: A number of commentators suggested that the [1983] proposed regulations could be read to require a significant improvement for an activity to qualify under section 174. They suggested that such a reading would be overly restrictive because research and development activities may in many instances be part of an evolutionary process involving a series of minor improvements that, when taken together over a period of time, lead to a significantly improved product. The regulations proposed by this document do not include the reference to "routine" or "periodic" improvements. * * * 54 Fed. Reg. 21225 (May 17, 1989). The Explanation of Provisions in the 1993 proposed regulations to sec. 174 states in part: (continued...) - 79 - we should apply these higher threshold requirements reasonably and practically and assume that Congress set standards that are not impossible to meet. See United States v. American Trucking Associations, Inc., 310 U.S. 534, 543 (1940); Venture Funding, Ltd. v. Commissioner, 110 T.C. 236, 264 (1998) (Ruwe, J., dissenting). In applying each of the seven tests under section 41 to the facts herein, we shall consider the facts and circumstances in determining whether the taxpayer performed qualified research. 5. United Stationers, Inc. v. United States Both parties rely on the District Court's decision in United Stationers, Inc. v. United States, 982 F. Supp. 1279 (N.D. Ill. 1997), in advancing their differing positions as to whether Norwest engaged in qualified research under section 41. In United Stationers, the taxpayer, a large office supply wholesaler, sought the R&E credit with respect to eight software projects. To automate its business operations, the taxpayer acquired from a vendor a software package which it then customized to meet its particular needs. The court principally relied upon the report and recommendation of a magistrate judge to find the facts in the case, see United Stationers, Inc. v. United States, 79 AFTR 2d 97-1761, 39 (...continued) Commentators argued that the "time-line" approach of the 1989 proposed regulation was unrealistic because progress in research and development is often achieved only in small, incremental steps. * * * 58 Fed. Reg. 15819 (Mar. 24, 1993). - 80 - 97-1 USTC par. 50,457 (N.D. Ill. 1997) (report and recommendation of magistrate judge), although the court did not accept all of the magistrate judge's findings. The Government therein, as in this case, conceded that the taxpayer satisfied the section 174 test. In analyzing section 41, the District Court disallowed the credit on several grounds. First, the court concluded that the taxpayer did not discover information that was technological in nature. Applying a dictionary definition for technological ("resulting from improvement in technical processes that increases the productivity of machines and eliminates manual operations or the operations done by older machines") and [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/cases/4331808. Public record. Not legal advice.