Date: 20000830
Docket: 98-1324-IT-G
BETWEEN:
C.W. AGENCIES INC.,
Appellant,
and
HER MAJESTY THE QUEEN,
Respondent.
Reasonsfor Judgment
Bonner T.C.J.
[1] This is an appeal from assessments of income tax for the 1991 to 1995 taxation years. By the assessments in issue the Minister of National Revenue (the "Minister") disallowed claims made by the Appellant on the basis that it had made current and capital expenditures on scientific research and experimental development ("SRED") in those years.
[2] The issue raised by this appeal is whether a taxpayer who in the 1990 to 1995 period created application software for use in its business conducted SRED within the meaning of s. 2900 of the Income Tax Regulations (the "Regulations"). The software in question was required to meet very exacting requirements imposed by the nature of the Appellant's business and the competitive environment in which that business operated.
[3] In the course of creating the software the taxpayer utilized:
a) a computer platform based on newly emerging technology, that is to say, object-oriented technology said by the Appellant to be fundamentally different and in its infancy;
b) a CASE tool, that is to say, a computer aided software engineering tool for the writing of computer code; and
c) rapid prototype methodology whereby prototypes of components of the software are created, tested and then reworked to remedy deficiencies and add new functions or capacities.
Object-oriented technology, as I understand it, brings together data structures and functions to create objects capable of further use. Rapid prototype methodology was a departure from the then traditional "waterfall" methodology in which the entire software program is created in one stroke.
[4] The software developed by the Appellant was sometimes known as the International Distributed Lottery System (IDLS). For purposes of the Appellant's SRED claim the work was broken down into development tasks or projects described as follows:
"Task Name
1 Data Entry and Fulfillment Computer System
2 Enhancements and Additional Modules for the Data Entry and Fulfillment System
3 Enhancements and Additional Software Modules for the Data Entry and Computer System
4 Enhancements and Additional Software Modules for the Order Fulfillment Computer System
5 United States Mailing System Computer Software
6 Enhanced Sales Analysis Software Module
7 Enhancements to Data Transfer Telemarketing Autodialer
8 Design and Development of International Telemarketing Software Modules
9 European Market Order Entry and Fulfillment
10 Production Scheduling System"
The descriptions may be unhelpful but the functions performed by the software system which resulted from the work done by the Appellant were described in detail in evidence adduced at the hearing.
[5] There is no dispute about the figures. The parties filed a written agreement setting out the amounts of the expenditures made in carrying out the activity. The case was fought on an all or nothing basis. Either the activity viewed as a whole constitutes SRED within s. 2900 or none of it does.
[6] The Appellant's first two witnesses gave evidence regarding the background and details of the work done. David Harlos has been, since 1995, the chief financial officer of the Appellant. From 1985 to 1995 he was an outside accountant who worked on the Appellant's file. Brian Page is a vice-president of the Appellant. He forms a bridge between technical support and business management. In 1987, he became a consultant to the Appellant
[7] The Appellant carries on the business of marketing tickets in government sponsored lottery schemes to customers throughout the world (save Canada). The Appellant's marketing activities are conducted by telephone and by direct mail solicitation. Business is carried on in a number of languages. Payment to the Appellant is accepted in a number of North American and European currencies. The Appellant offers or markets to its customers as many as 100 lottery "products" each year.
[8] The Appellant's profits are generated by service fees charged to its customers. The Appellant receives orders for tickets both by mail and by telephone. It solicits orders from established customers by telephone. It acquires customers by conducting test mailings to persons whose names are found on mailing lists which the Appellant purchases. When dealing with an established customer the Appellant's telephone agents utilize a computerized file which gives particulars of the customer's buying history, preferences and account balance. Incoming telephone orders are assigned to the telephone agents in accordance with the customer's language preference. The business is labour intensive, employing approximately 450 people, including 300 telephone agents.
[9] The Appellant has two to three million customers and it receives as many as 25,000 purchase orders in a day. The orders are recorded in the Appellant's computer system. Payment is accepted in the currency of the client's choice (but not in Canadian dollars). Acceptable methods of payment include cash, cheque, credit card and money order. Upon confirmation of payment the client is informed of the serial numbers of the tickets which have been purchased for him. Transactions must be carried out within strict time limits because tickets may not be purchased until a short time before the draw and, of course, cannot be purchased after. Following the lottery draw the winning numbers are entered in the Appellant's computer and a search of the data base is performed by the Appellant in order to identify and arrange for payment to clients who have won.
[10] The business as just described is the result of continuous evolution and change over the years. The business was started in the early 1980s. It was then a "kitchen table" operation of limited scope. It involved the sale of quick pick tickets in a single lottery. Communications between the Appellant and its customers were by mail. Now only 30 percent of the business results from mailings. The balance results from telephone calls handled at a call centre in Vancouver. During the period while the IDLS software was being developed there was a second call centre in Amsterdam. It was later closed. The Amsterdam operation was integrated with the Canadian operation, an arrangement which required a sharing of the data base and the transaction processing system. This added complexity to the IDLS. The nature of the business and the competitive environment demanded that the business be conducted with the support of a fully automated system.
[11] In the late 1980s, the needs of the Appellant's business outstripped the capacity of the technology which was then employed by the Appellant. Because of the unique nature of the Appellant's business requirements it was not possible to buy "off-the-shelf" software capable of addressing the Appellant's business requirements. The Appellant had no choice but to develop its own system in-house. The business objectives for the new system imposed the following system requirements: flexibility, scalability, instant response time, accuracy and reliability.
[12] In 1990 the Appellant purchased an IBM 400 "mid-range" computer. It also purchased an integrated CASE tool manufactured by Synon Corporation as its development environment. The IBM 400 was a new system at the time. It was selected because the manufacturer was committed to the product and it was expected that both system and manufacturer would be around for a long time. The operating system of the IBM 400 was based on "object-oriented" technology. The Appellant selected the Synon CASE tool which used object-oriented technology and offered a rapid prototype methodology and a full development environment.
[13] The Synon CASE tool used by the Appellant allows the software developer to enter specifications into the computer in ordinary language and COBOL computer code is produced. It allowed the Appellant's programmers to bypass the writing of millions of lines of Code. Without it, Mr. Page testified, the Appellant would have been looking at another ten years of work. He noted that the tool allows for the reuse of programs and allows programmers to work collaboratively.
[14] The development environment allowed the Appellant to maintain some development documentation. The Synon CASE tool self-documents, that is, it keeps a log of day-to-day operations in electronic form. The tool also enforces a methodology, which facilitated the development of the software. The Appellant encountered problems from the outset. The Appellant had to devise solutions in-house because, due to the novelty of the IBM 400 and the Synon CASE tool, there were few outside experts to whom the Appellant could turn for help. For the same reason not even the manufacturers were of much assistance to the Appellant in resolving the problems which it encountered.
[15] Mr. Page testified that the use of the CASE tool to build a system was new at the time. He described drawbacks to the CASE tool. Programmers did not like it because there is a level of abstraction. Furthermore, there were limits inherent within the tool. It had to be told exactly what the programmer wanted it to do otherwise the end result was not as desired. Testing was important not only to check the result but also to learn whether what had been done made the best use of the CPU and other resources and maintained data integrity. When a problem was encountered it was necessary to determine whether it resulted from a fault in input or an inherent limitation of the tool.
[16] There was within the AS/400 itself, a performance utility test which, once parameters were defined, permitted the comparison of two different prototype configurations and the analysis of the results. Test results were kept on the machine and later archived. Not all archived tests were kept by the Appellant because the Synon CASE tool allowed the technicians to go back and recreate any test.
[17] As already noted, the Appellant employed a rapid prototype methodology. The methodology was intended to enable the Appellant to utilize the IDLS while, at the same time, developing it. For that reason and for reasons inherent in the computer operating system and the CASE tool the Appellant proceeded to develop the IDLS in a step by step fashion using rapid prototyping rather than the more common waterfall method in which all functions of the entire system are defined at the outset and the system is fully developed and tested before being put into use.
[18] The person primarily responsible for the rejection of the Appellant's income tax claims was the witness Robert Thomas Arnold. He served as a consultant to Revenue Canada with respect to the scientific and technical aspects of the Appellant's claim. He stated that his role was to look at documents submitted by the Appellant and at the requirements of the Income Tax Act. Mr. Arnold visited the Appellant's premises and spent a day reviewing material submitted by the Appellant. He testified that he was looking for contemporary documentation setting out or defining the problem which the Appellant sought to solve and the plan adopted in order to solve it. Mr. Arnold stated the following in his Phase I Technical Review findings, Exhibit A-9:
"There is no evidence that alternate approaches were developed and tested nor is work that builds on the analysis of results of testing in a systematic way described in the technical report. The supplemental technical report (Doc H) states that technical content can be demonstrated by summarizing program changes from archival backup tapes, however, this summarization is not presented in the technical report. The overall activities are routine in nature and do not contain technical uncertainties. Although some routine work may be commensurate with the needs and directly in support of experimental development, the use of standard practice alone indicates that an experimentally based study was not necessary to resolve technical uncertainties."
Mr. Arnold did admit that the Appellant went about its work in a systematic fashion. He did not review the electronic documentation in the Synon CASE tool in order to discover whether evidence of technical content was to be found therein as the Appellant had suggested he should.
[19] I formed the impression that Mr. Arnold adopted a doctrinaire and rigid approach in his investigation of the Appellant's claim. He seems to have been unwilling to consider any evidence which was not presented to him in the form which he preferred. Although a detailed record of the hypothesis, the tests and the results ought[1] to be kept and produced as evidence of scientific research Mr. Arnold appears to have placed undue emphasis on the form in which the record is to be kept. The onus which must be discharged by a taxpayer who appeals from an income tax assessment is decreased in weight where, as here, the assessment rests on an investigation which is affected by an attitude problem.
[20] Each party produced one expert witness. Both witnesses were very well qualified in the area of software technology and development. They were however of opposing views on the question whether the Appellant's activity constituted SRED.
[21] Dr. Jacob Slonim, Dean of the Faculty of Computer Science at Dalhousie University, was called by the Appellant. Dr. Slonim indicated that in 1998 when he was first sent the material that had been submitted to Revenue Canada he was very sceptical about the Appellant's claim that SRED had taken place. It was only when he visited the Appellant's Vancouver office in December of 1998 for a period of two days, met with a number of individuals concerned, and was shown the software and how it operated that his perception started to change. He was still uncertain and requested further documentation and manuals for the hardware. In February of 1999, he visited the Appellant's Vancouver office again and investigated still further. Clearly, Dr. Slonim's conclusion rested on a careful attempt to uncover both the technological uncertainties faced by the Appellant and the steps taken to resolve them. I say uncover because little in the way of contemporary records of the activity now in issue were maintained by the Appellant (save for the record of activity capable of being recreated by the use of the Synon CASE tool).
[22] In his report, Dr. Slonim made reference to the inadequacies of the Appellant's records. He noted:
"The one disappointment, which I had, was the lack of project management and documentation that is more detailed. I understood that the project management, which would have helped me who (sic) to see where the difficulties were, was not retained at the C-W Agencies. I saw one or two pieces of documentation that indicated to me that they used the project-management tool. Furthermore, although I have a bias since I worked for IBM for ten years and know their procedures quite well, employing a project manager from IBM, who did not draw a detailed project management plan, would be most surprising. It is possible that he retained it upon his departure from the C-W Agencies. Without it, the analysis was definitely a lot more difficult to do. However, as I mentioned, because of the numerous uncertainties in this project, I have no doubt that experimental research was being conducted."
In order to deal with the inadequacy of the documentary record Dr. Slonim examined changes in the data structure and, from periodical changes in the log generated by the CASE tool, he felt that he was able to infer the changes that were being made.
[23] Dr. Slonim described the Appellant's hypothesis as follows:
" ... C-W Agencies hypothesized that the benefit gained from the object-oriented architecture would result in a higher productivity per person from the reusability of components and a decrease in system development time compared to procedurally based development methods. At the same time, there were major drawbacks: the need to manage the uncertainty of performance and scalability of the new unproven methodology. It is the scale of this system, which justifies it as experimental research."
I note here that it is not clear to me that this "hypothesis" is one which is capable of being proved or disproved by means of scientific research. It seems to me that it is simply too vague. The word hypothesis in this context is normally considered to mean a provisional concept which is not inconsistent with known facts and serves as a starting point for further investigation by which it may be proved or disproved objectively. Even if this hypothesis is one which can be tested by scientific research it does not appear that the Appellant attempted to test it. All the Appellant really attempted to do was to develop software.
[24] Dr. Slonim gave detailed evidence regarding the aspects of the IDLS system which he considered to be unique and regarding the uncertainties[2] which in his view flowed from them. Time deadlines were extremely important, languages had to be correct and there were currency issues and time zone issues which had to be dealt with. It was necessary to ensure that mailing lists contained no duplications and the customer data had to be readily accessible and capable of convenient updating. Dr. Slonim regarded as an element of uncertainty the fact that new architecture was being used by the Appellant with little knowledge of the side effects. Uncertainty was increased by the size of the system and the millions of lines of code required. He indicated that there were many unknowns arising from the interaction of different technologies and that the problems were not susceptible to easy solutions. He explained in detail the system uncertainties and advances in technology. Dr. Slonim listed many different areas of uncertainty: scalability, performance, software integration, reuse of software modules, complexity of transactions, multi-languages, system configuration restrictions, distributed operation, printing, deadlocks, processing communication speed and reliability, sales analysis, real time performance, object-oriented development, conversion problems, time zone problems, data integrity and recovery, call centre, and software engineering.
[25] Some of the uncertainties were, Dr. Slonim said, resolved with advancements in technology, some were resolved with "brute force" which Dr. Slonim described as ugly or temporary solutions and some were avoided until a more "theory - based" solution was discovered. I will note here that, as I see it, the question whether the software which the Appellant created would be suitable for use in the Appellant's business is not in itself a matter of technological uncertainty. Some areas of technological uncertainty might have been encountered in the course of the attempt to create the IDLS but, as already noted, this case was fought on an all or nothing at all basis.
[25] Dr. Slonim noted that the AS/400 machine itself had configuration restrictions which hindered the Appellant's work. The operating system database had constraints involving the maximum number of files and file size capacity restrictions.
[26] Dr. Slonim testified that in 1989-1990, the waterfall methodology was standard. The rapid prototype methodology followed by the Appellant was invented in 1984-1985 but was not widely used or popular even as late as 1991. Use of the CASE tool was not at the time standard practice. It may have been standard in university environments but only in relation to relatively small numbers of lines of code. I note here that not every departure from standard practice constitutes SRED.
[27] Dr. Slonim identified what he considered to be four major technological advances. The first was the development of a very large object oriented system using the Synon CASE tool and meeting the constraints of the Appellant's domain. He said that standard practice at the time was based on procedural languages and waterfall software development models. The second advance identified by Dr. Slonim was the use of the data driven process which he considered to be relatively new and one which required the use of methodology different from the standard process oriented one. The third technological advance was said to be the integration of the Synon CASE tool with its rapid prototype methodology at a time when standard practice was the use of the waterfall method. He noted that the CASE tool forced the Appellant to change its design methodology and software engineering practice and he argued that this constituted a significant departure from the standard practice at the time. The fourth advance identified by Dr. Slonim related to the improvement of the knowledge pool represented by the employees and consultants of the Appellant who worked on the project. He felt that the IDLS system as a whole was a new way of using computing in a new application.
[28] Dr. Ken Takagaki was called as an expert witness for the Respondent. He holds a Ph.D. degree from the University of British Columbia. He is the Dean of the School of Computing and Information Technology at the British Columbia Institute of Technology. Between 1985 and 1988, he worked on his thesis which pertained to object-oriented information systems. Part way through the audit process, Dr. Takagaki was asked by Mr. Arnold to sit in on meetings with the Appellant because communications between Mr. Arnold and the Appellant had broken down. It was Dr. Takagaki's evidence that in the 1980s software tools were developed to make it easier to use computers. CASE tools were originally developed in the 1970s. The rapid prototyping method was popular in many computers for business purposes in the early 1980s. He considered the method to be routine.
[29] Dr. Takagaki recognized the rapid pace of technological change and therefore took steps to refresh his memory as to what was available in 1990. He had reference to old university calendars to learn what was being taught, to old textbooks and he examined a curriculum to determine what professors were required to teach. In his report Dr. Takagaki identified the IDLS as an information system, described the process of development of information systems and described the tools and techniques used in the development of information systems. He stated:
"Computer science and Information technology are involved in the creation of Information Systems or Management Information Systems ...
Broadly speaking, by 1990, the automation of most business processes or procedures would be considered technically feasible, especially those common to most businesses such as payroll, personnel record management, order entry, inventory control, sales analysis, and production scheduling where the business rules are defined. A wide variety of technologies were readily available for purchase including Data Base systems, networking technology (LAN and WAN), processor hardware (mainframes and midrange as well as increasingly more powerful PC's), and software development tools including conventional languages (COBOL, RPG) and rapid development and prototyping tools such as CASE and 4GL's.
The construction of Information Systems, sometimes referred to as Information Systems Development, can be complex and difficult with significant project management risks. However, knowledge of effective methodologies or processes for the construction of Information Systems, was widely available in textbooks, university courses, or through venders (sic), consultants and experienced IS professionals.
Information systems development is a logical and systematic process by which such systems are planned, designed and constructed. The entire process is usually referred to as the Systems Development Life Cycle (or SDLC) and a specific process is sometimes called a systems development methodology.
In practice, the Systems Development Life Cycle is a dynamic, iterative process that typically includes among its components the following stages.
1. Project Initiation. The need for the project is identified (typically arising from a business requirement) and the decision is made to initiate the project. Decisions are made related to scope, budget, staffing, etc.
2. Requirements analysis. The detailed specifications and design goals for the project are determined.
3. Systems Design. The technical requirements and design solutions are developed. Models are developed for the data, processes, logical configurations and physical configurations of the system. Alternative candidate configurations are identified and evaluated.
4. Implementation. The hardware and software is procured and/or developed.
5. Testing. The system is tested, both as individual components and the integrated system as a whole.
6. Conversion. Data, procedures and other systems components are converted from the previous system (if any) to the new system. Training of staff.
7. Delivery. The system is placed into daily production.
8. Maintenance. The system is upgraded to keep pace with changes in technology or the business environment."
[30] Dr. Takagaki then went on to discuss the difficulties often encountered when developing an information system and the techniques commonly employed in surmounting them. He stated:
"Information systems can be complex and interactions among its separate components difficult to predict. Business requirements are constantly evolving and changing over time, therefore the process of systems development often occurs within a climate of environmental or business uncertainty. The systems life cycle is therefore usually iterative in that changes in the business environment or the results of a subsequent stage can cause systems developers to return to a previous one. Throughout the life cycle, there are many checkpoints and/or management reviews where project feasibility is assessed and "go/no-go" as well as "make/buy" decision points arise. In this context, another major technological uncertainty is the rapid evolution of technology, particularly hardware. Therefore, techniques and tools for rapid application development (RAD) are of interest to systems developers.
Among the various tools and techniques popular with many systems development methodologies are the following:
• Prototyping. The act of building small scale, representative or working models of the system to assist in the various phases of the SDLC, including requirements analysis, design, implementation and testing. In the context of systems development, prototyping is a routine method of incrementally developing a system and intended to accelerate the process of systems development and improve the quality of the final result.
• CASE (Computer-Aided Software Development). An integrated development tool which can be used to document requirements, assist in overall systems design, and generate software (programs and data models). Intended to accelerate the process of developing systems and improve the quality of the final result.
• Cost/Benefit Analysis. Analysis to inform the decision process related to balancing the cost of developing and operating a system and the benefits from that system.
• Feasibility Analysis. Measurement of technical, operational, economic and other feasibility.
• Benchmarking and Testing. The evaluation of products in terms of price, performance and other factors. These are particularly important since technologies are constantly changing and complex interactions can occur when they are combined. Unit testing determines how individual components work when tested in isolation. System testing determines how components work when integrated into the total system. A particular combination of components (hardware, software or both) is sometimes called a "configuration". All software which is developed during an IS development project will undergo a routine and rigorous testing procedure.
• Configuration management and systems integration. Information systems routinely combine software, hardware, data and processes from different sources to form an integrated system. Over the years, vendors and systems developers have adopted different (and sometimes inconsistent) positions with respect to achieving compatibility. Some vendors prefer to keep their products "closed" to outsiders. Others strive to keep their products "open", compatible or easily connected to products from other vendors. Regardless, the interactions between different components can be difficult to predict or can produce unexpected results and can consume a significant proportion of systems development effort.
The Systems Development Life Cycle concept and the tools and techniques listed above could be considered part of the standard practice for IS developers around the time of the claims in question. These were widely described and discussed in textbooks, professional journals, and taught as part of post-secondary Computer and Information Technology curricula. Standard business processes such as Order Entry, Payroll, Inventory Control, Production Scheduling are routinely used as examples in textbooks and college courses.
[31] Dr. Takagaki then addressed the question whether the work involved in the development of information systems necessarily involves scientific research within the meaning of s. 2900. He noted:
"Systems development can involve systematic investigation or search and may involve experimentation and/or analysis. For example, systematic investigation or search is important when determining that all the requirements for the new system has been identified during Requirements Analysis. Similarly, systematic search is appropriate when conducting cost/benefit analysis and procuring from a number of alternative vendors. Experimentation and analysis may be required during routine testing of software or when benchmarking hardware alternatives offered by vendors. However, this should be distinguished from "systematic investigation ... in a field of science or technology".
He distinguished between those information system development projects which fall within s. 2900 and those which do not.
" ... Where an ISD project utilizes a new principle or concept and the project is undertaken primarily to test the new principle or concept, it may conform to 2900(1). Or, parts of an ISD project may utilize new knowledge, principles or techniques conforming to the requirements of 2900(1)."
[32] Next Dr. Takagaki reviewed the Appellant's ten projects both individually and collectively. He noted:
"In all of their projects, CW Agencies Inc. appeared to have made efforts to follow a process of identifying requirements, creating prototypes with their CASE tool., testing, design refinement and iteration, i.e. routine systems development, using commonly applied methodologies as taught in courses or explained in textbooks of the time.
...
As would be expected from routine information systems development, all projects demonstrate the use of "systematic investigation or search" and use of "experiment or analysis". The focus of their investigations are primarily (i) defining requirements, (ii) evaluating commercial products, (iii) testing hardware configurations or (iv) routine software testing. This is in contrast to systematic investigation in computer science, which is focused primarily on new concepts, principles, technologies or techniques. I characterize these investigations as those of competent and prudent users of complex, commercially available technologies rather than those of researchers seeking to discover new knowledge, concepts or principles[3]. As such, (ii), (iii) and (iv) might be excluded as "activities with respect to ...(e) quality control or routine testing of materials, devices or products". (i) is mainly concerned with soliciting the business requirements, rules and needs of the system and will not quality (sic) as an "investigation in the field of a science or technology".
2900(1)(a)(b) Advancement of scientific knowledge. The evidence over all the projects indicates that they have all been undertaken for business reasons and not to advance scientific knowledge. The individual project descriptions are indicative of this. Similarly, there is significant reason to believe that the ten projects as a whole were undertaken for business reasons and not advance scientific knowledge.
For all ten projects, the general hypothesis advanced that the project concerned was not achievable in a cost-effective manner, given the state-of-the-art of computing technology of the day. However the cost effectiveness of any information system development project is a function of many economic variables in addition to technical or scientific factors. For example, falling hardware prices, shrewd purchasing practice, effective project management or simply a reduction in the requirements for the system can also result in cost effectiveness. As such, these hypotheses do not identify how the project as a whole constitutes "work undertaken for the advancement of scientific knowledge" in the sense of basic or applied research for the project as a whole.
2900(1)(c) Technological advancement. As indicated above, the evidence indicates that the ten projects taken as a whole were undertaken for business purposes and not for experimental development. The available documentation clearly and explicitly states in several places the business goals of individual projects and references and while there are many claims of technological advances, they do not clearly and unequivocally identify the new concepts, principles, technologies or techniques that constitute the technological advance.[4]
2900(1)(c) Creation of new or improved products or processes. The types of systems developed in the ten projects are all similar to those find (sic) in businesses across the economy. No new class of product or system has been produced although, as with most information systems, they are all heavily customized to the needs of CW Agencies Inc.
In a narrow sense, every change to the system results in a unique combination or configuration of technology. Since each project has added in some way to the overall system, in a "liberal" reading of this part of the regulation, this may constitute a new or improved configuration at minimum and possibly a "new" or "improved" information system provided that precondition to 2900(1)(c), "experimental development ..." holds, which I believe does not in this case."
Dr. Takagaki concluded:
"In my opinion, the ten projects as a whole are routine Information Systems Development projects and do not meet the requirements of 2900(1) for the following:
1. While there has been "systematic investigation ... by experiment or analysis" as set forth in the preamble of 2900(1), this has been for the purpose of determining business requirements, evaluating commercial products, testing various equipment configurations, or routine testing of software. In the first case, the investigation is not in the field of computer science. The others are excluded by exclusion (e) of 2900(1).
2. There is no evidence that the product was "undertaken for the advancement of scientific knowledge", either as (a) basic research or (b) applied research. Rather the evidence strongly demonstrates business reasons, goals and objectives.
3. There is no evidence of "(c) experimental development". The project has used commercially available products and services, and current information systems development methodologies and practices throughout. Neither do I believe a new product has been created in a generic sense. This is also the third, albeit, enhanced iteration of the system."
[33] By way of rebuttal Dr. Slonim took issue with what he said was Dr. Takagaki's main premise that the projects were undertaken for business purposes and that there was no evidence of SRED, an approach which Dr. Slonim asserted was " ... contrary to the intent of the SR & ED Program". He asserted that Dr. Takagaki failed to look at the technological issues resolved by the Appellant and referred to a 1994 publication as an indication that many aspects of the CW Agency system were not common at the time. Dr. Slonim said he was surprised that Dr. Takagaki had failed to identify any of the 21 uncertainties and speculated that Dr. Takagaki's failure to identify the uncertainties resulted from an inadequate opportunity to examine the technology utilized by the Appellant.
[34] During the period in question two definitions of SRED are found in s. 2900(1). The version applicable to the Appellant's 1991 and 1992 taxation years differs from that applicable to the 1993 to 1995 years. S. 2900(1) provides a two part requirement for experimental development. The second part was amended for taxation years ending after December 2, 1992. The first part requires that SRED be a "systematic investigation or search carried out in a field of science or technology by means of experiment or analysis". The second part for the 1991 and 1992 taxation years of the Appellant requires the "use of the results of basic or applied research" for any of several stated purposes. The second part for the 1993 to 1995 taxation years requires that the work be "undertaken for the purposes of achieving technological advancement" for any of several stated purposes. The amendment to s. 2900 was for clarification purposes only; no substantial change was intended. In the form applicable to the Appellant's 1993, 1994 and 1995 taxation years s. 2900(1) provided in part:
2900. (1) For the purposes of this Part and sections 37 and 37.1 of the Act, "scientific research and experimental development" means systematic investigation or search carried out in a field of science or technology by means of experiment or analysis, that is to say,
(a) basic research, namely, work undertaken for the advancement of scientific knowledge without a specific practical application in view,
(b) applied research, namely, work undertaken for the advancement of scientific knowledge with a specific practical application in view,
(c) experimental development, namely, work undertaken for the purposes of achieving technological advancement for the purposes of creating new, or improving existing, materials, devices, products or processes, including incremental improvements thereto, or
(d) work with respect to engineering, design, operations research, mathematical analysis, computer programming, data collection, testing and psychological research where that work is commensurate with the needs, and directly in support, of the work described in paragraph (a), (b) or (c), but does not include work with respect to
...
(f) quality control or routine testing of materials, devices, products or processes,
...
(k) routine data collection."
It is not necessary to set out the version applicable to 1991 and 1992.
[35] The correct general approach to the interpretation of s. 2900 is found in the decision of this Court in Northwest Hydraulic Consultants Ltd. v. H.M.Q.[5]:
"The tax incentives given for doing SRED are intended to encourage scientific research in Canada (Consoltex Inc. v. The Queen, 97 DTC 724). As such the legislation dealing with such incentives must be given "such fair, large and liberal construction and interpretation as best ensures the attainment of its objects" (Interpretation Act, section 12)."
[36] In Northwest the Court went on to identify three basic criteria which apply to the determination of the question whether SRED has taken place in a particular case. They are scientific or technological uncertainty, scientific or technological content and scientific or technological advancement. The Court explained those three elements or criteria in language which is well worth repeating:
"1. Is there a technological risk or uncertainty?
(a) Implicit in the term "technological risk or uncertainty" in this context is the requirement that it be a type of uncertainty that cannot be removed by routine engineering or standard procedures. I am not talking about the fact that whenever a problem is identified there may be some doubt concerning the way in which it will be solved. If the resolution of the problem is reasonably predictable using standard procedure or routine engineering there is no technological uncertainty as used in this context.
(b) What is "routine engineering"? It is this question, (as well as that relating to technological advancement) that appears to have divided the experts more than any other. Briefly it describes techniques, procedures and data that are generally accessible to competent professionals in the field.
2. Did the person claiming to be doing SRED formulate hypotheses specifically aimed at reducing or eliminating that technological uncertainty? This involves a five stage process:
(a) the observation of the subject matter of the problem;
(b) the formulation of a clear objective;
(c)the identification and articulation of the technological uncertainty;
(d) the formulation of an hypothesis or hypotheses designed to reduce or eliminate the uncertainty;
(e) the methodical and systematic testing of the hypotheses.
It is important to recognize that although a technological uncertainty must be identified at the outset an integral part of SRED is the identification of new technological uncertainties as the research progresses and the use of the scientific method, including intuition, creativity and sometimes genius in uncovering, recognizing and resolving the new uncertainties.
3. Did the procedures adopted accord with established and objective principles of scientific method, characterized by trained and systematic observation, measurement and experiment, and the formulation, testing and modification of hypotheses?
(a) It is important to recognize that although the above methodology describes the essential aspects of SRED, intuitive creativity and even genius may play a crucial role in the process for the purposes of the definition of SRED. These elements must however operate within the total discipline of the scientific method.
(b) What may appear routine and obvious after the event may not have been before the work was undertaken. What distinguishes routine activity from the methods required by the definition of SRED in section 2900 of the Regulations is not solely the adherence to systematic routines, but the adoption of the entire scientific method described above, with a view to removing a technological uncertainty through the formulation and testing of innovative and untested hypotheses.
4. Did the process result in a technological advance, that is to say an advancement in the general understanding?
(a) By general I mean something that is known to, or, at all events, available to persons knowledgeable in the field. I am not referring to a piece of knowledge that may be known to someone somewhere. The scientific community is large, and publishes in many languages. A technological advance in Canada does not cease to be one merely because there is a theoretical possibility that a researcher in, say, China, may have made the same advance but his or her work is not generally known.
b) The rejection after testing of an hypothesis is nonetheless an advance in this it eliminates one hitherto untested hypothesis. Much scientific research involves doing just that. The fact that the initial objective is not achieved invalidates neither the hypothesis formed nor the methods used. On the contrary it is possible that the very failure reinforces the measure of the technological uncertainty.
5. Although the Income Tax Act and the Regulations do not say so explicitly, it seems self-evident that a detailed record of the hypotheses, tests and results be kept, and that it be kept as the work progresses.
[37] The role of expert witnesses in cases such as this was discussed by the Federal Court of Appeal in RIS Christie Ltd. v. The Queen[6]. At paragraph 12, Robertson J.A., speaking for the Court, stated:
"What constitutes scientific research for the purposes of the Act is either a question of law or a question of mixed law and fact to be determined by the Tax Court of Canada, not expert witnesses, as is too frequently assumed by counsel for both taxpayers and the Minister. An expert may assist the court in evaluating technical evidence and seek to persuade it that the research objective did not or could not lead to a technological advancement. But, at the end of the day, the expert's role is limited to providing the court with a set of prescription glasses through which technical information may be viewed before being analyzed and weighed by the trial judge. Undoubtedly, each opposing expert witness will attempt to ensure that its focal specifications are adopted by the court. However, it is the prerogative of the trial judge to prefer one prescription over another."
[38] An odd feature of this case is that virtually all of the evidence relating to the detail of what was in fact done by the Appellant in the course of designing and writing the software was given, not by a person directly and personally involved in the process, but rather by the Appellant's expert, Dr. Slonim. As I appreciate the evidence, Dr. Slonim was compelled by the absence of a detailed project management plan to examine the results of the Appellant's work, next to examine the tools and technology used by the Appellant and, finally, to arrive at conclusions regarding the problems which he thought must have been faced by the Appellant and the steps taken to solve those problems. I note that the failure to call the project manager or some similarly placed person was never explained by counsel for the Appellant. In deciding what must in point of fact have happened, based on conjecture with regard to "the numerous uncertainties in this project", Dr. Slonim arrived at conclusions which in my view were not justified by the evidence.
[39] In my view Dr. Takagaki took a more prudent and defensible stance when, in response to questions regarding what was recorded in the electronic logs generated by the CASE tool, he noted: a) that "theoretically" it might have been possible to review the logs and to find documentation from which some sort of an advance might be inferred, and, b) that a significant amount of inference would be required.
[40] Dr. Takagaki was asked whether the very fact that a large and complex system was developed supported an inference that there had been technological advance. His response was that he had not seen anything in the documentation which would have been unknown in the technological field. No doubt the IDLS which resulted from the Appellant's work was large and complex but mere size and complexity do not support a conclusion that the work was anything more than routine information systems development.
[41] In my view, the evidence of Dr. Takagaki is to be preferred to that of Dr. Slonim. Dr. Takagaki's opinion did not rest on speculative conclusions as to what must have happened. I reject the argument that Dr. Takagaki's work was flawed in its methodology and assumption. That argument was based on the assertion that Dr. Takagaki had disqualified the Appellant's software as a whole because the Appellant had a business motivation for its activity. While I quite agree that it is contrary to common sense to exclude from the application of s. 2900 all activity undertaken with a business purpose in view I do not believe that Dr. Takagaki's conclusions rested on any such faulty premise. When his evidence is taken in context it is clear that Dr. Takagaki evaluated the Appellant's activity with a view to determining whether it was undertaken for the purpose of achieving technological advancement. He was not distracted by the Appellant's overriding commercial goal.
[42] It was also said that Dr. Takagaki erred in making a qualitative decision based on how much technical advancement was required for the work to constitute a s. 2900 activity. This criticism was directed to comments made by Dr. Takagaki with respect to the s. 2900(1) requirement that the result of research be used for the purpose of creating new or improving existing materials, devices, products or processes. The criticism is unfounded. In asserting that the IDLS was not a new class of product, Dr. Takagaki was simply noting that the IDLS was not a new product in a generic sense even though it was heavily customized. He noted that data entry online information systems built around mid-range computers such as the AS/400 with data entry terminals and custom programmed within a CASE software environment were common. The criticism might have been justified if the Appellant had been able to establish that the IDLS was in substance, even to a small degree, something more than a variation on products already in existence. I cannot find that the Appellant succeeded in doing so. The resolution of Dr. Slonim's "uncertainties" whether by avoidance or by means of "ugly or temporary solutions" does not necessarily constitute technological advancement
[43] The final criticism aimed at Dr. Takagaki's opinion related to the issue of standard practice. In advancing this argument the Appellant noted that what constitutes standard practice in a field of technology can only be evaluated by specialists familiar with that field. It was said that the evidence of Dr. Slonim should be preferred over that of Dr. Takagaki because the issue must be determined in the context of the taxpayer's circumstances. While I agree with my colleague Judge Bowman that "a technological advance in Canada does not cease to be one merely because there is a theoretical possibility that a researcher in, say, China, may have made the same advance ..."[7], I cannot find that Dr. Takagaki ignored the Appellant's context in arriving at his conclusion that "the project used commercially available products and services, and current information systems development methodologies and practices throughout".
[44] For the foregoing reasons the appeal will be dismissed with costs.
Signed at Ottawa, Canada, this 30th day of August 2000.
"Michael J. Bonner"
J.T.C.C.
COURT FILE NO.: 98-1324(IT)G
STYLE OF CAUSE: C.W. Agencies Inc. and
Her Majesty the Queen
PLACE OF HEARING: Vancouver, British Columbia
DATE OF HEARING: February 7, 2000
REASONS FOR JUDGMENT BY: The Honourable Judge M.J. Bonner
DATE OF JUDGMENT: August 30, 2000
APPEARANCES:
Counsel for the Appellant: Douglas H. Mathew
Counsel for the Respondent: Ernest Wheeler
COUNSEL OF RECORD:
For the Appellant:
Name: Douglas H. Mathew
Firm: Thorsteinssons
Vancouver, British Columbia
For the Respondent: Morris Rosenberg
Deputy Attorney General of Canada
Ottawa, Canada
98-1324(IT)G
BETWEEN:
C.W. AGENCIES INC.,
Appellant,
and
HER MAJESTY THE QUEEN,
Respondent.
Appeal heard on February 7, 2000 at Vancouver, British Columbia, by
the Honourable Judge Michael J. Bonner
Appearances
Counsel for the Appellant: Douglas H. Mathew
Counsel for the Respondent: Ernest Wheeler
JUDGMENT
The appeal from the assessments made under the Income Tax Act for the 1991, 1992, 1993, 1994 and 1995 taxation years is dismissed with costs.
Signed at Ottawa, Canada, this 30th day of August 2000.
|
"Michael J. Bonner" |
J.T.C.C.
[1] RIS Christie Ltd. v. The Queen, 99 DTC 5087
[2] Dr. Slonim seemed to use the word uncertainty to describe what I would call a challenge.
[3] I have added emphasis here because, in my opinion, this passage constitutes an accurate, comprehensive, and above all, brief description of the activity now in question.
[4] emphasis added
[5] 98 DTC 1839
[6] (supra)
[7] Northwest Hydraulic (supra) at page 1842