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.
J.T.C.C.
Email this Content