Revenue Canada INFORMATION CIRCULAR LOCATOR NUMBER: 858A NUMBER: 97-1 DATE: February 28, 1997 SUBJECT: Scientific Research and Experimental Development - Administrative Guidelines for Software Development Table of Contents 1 Introduction 1.1 Document purpose 1.2 Definitions 1.3 General comments on interpretation and evaluation of SR&ED 2 SR&ED Project Definition 3 The Three Criteria of SR&ED 3.1 The scientific or technological advancement criterion 3.2 The scientific or technological uncertainty criterion 3.3 The scientific and technical content criterion 4 Project Examples 5 Activity Issues 5.1 Activities that usually qualify within SR&ED projects 5.2 Feasibility study and planning 5.3 Market research versus user requirements 5.4 Testing 5.5 SR&ED project completion 5.6 The activity of documenting the SR&ED project 6 Documentation Requirements 7 Preparation of These Guidelines 1 Introduction 1.1 Document purpose This document is intended to assist taxpayers and Revenue Canada staff in interpreting how the scientific research and experimental development (SR&ED) tax incentives apply to software development. It provides interpretation of the definition of scientific research and experimental development in subsection 248(1) of the Income Tax Act (the Act) (note 1) and expands on Information Circular 86-4, Scientific Research and Experimental Development. It is directed towards software specialists involved in the management of research and development who are responsible for providing technical descriptions to Revenue Canada as part of claims for SR&ED expenditures. Note 1: At the time of printing, the proposed amendment has not been enacted to place the definition of SR&ED in subsection 248(1) of the Act, replacing the definition given by subsection 2900(1) of the Income Tax Regulations. The present guidelines are subject to the effective statutory definition of SR&ED. The discussions in this document concern only technical issues involved in determining the eligibility of work as SR&ED. Questions relating to allowable expenditures are covered in Interpretation Bulletin IT-151, Scientific Research and Experimental Development Expenditures. 1.2 Definitions The words "taxpayer" and "company" are used interchangeably in this document since most SR&ED claimants are corporations. "Taxpayer" has the meaning defined in the Act and does not imply a liability to pay tax. Software refers to the encoded instructions executed by electronic devices including computers for performing operations or functions. Science and technology relating to software are subfields of computer science and information technology. Computer science is the study of the theoretical and applied disciplines in the development and use of computers for information storage and processing, mathematics, logic, and many other areas. Information technology is the body of technical knowledge associated with collecting, storing, manipulating, and communicating information using computers and communications systems. The fields of computer science and information technology can be considered to overlap, and for the purpose of these guidelines it is not necessary to differentiate between them. SR&ED is defined for income tax purposes in subsection 248(1) of the Act, as follows: "scientific research and experimental development" means systematic investigation or search that is carried out in a field of science or technology by means of experiment or analysis and that is (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, or (c) experimental development, namely, work undertaken for the purpose of achieving technological advancement for the purpose of creating new, or improving existing, materials, devices, products or processes, including incremental improvements thereto, and, in applying this definition to a taxpayer, includes (d) work undertaken by or on behalf of the taxpayer with respect to engineering, design, operations research, mathematical analysis, computer programming, data collection, testing or psychological research, where the work is commensurate with the needs, and directly in support, of work described in paragraph (a), (b) or (c) that is undertaken in Canada by or on behalf of the taxpayer, but does not include work with respect to (e) market research or sales promotion, (f) quality control or routine testing of materials, devices, products or processes, (g) research in the social sciences or the humanities, (h) prospecting, exploring or drilling for, or producing, minerals, petroleum or natural gas, (i) the commercial production of a new or improved material, device or product or the commercial use of a new or improved process, (j) style changes, or (k) routine data collection. 1.3 General comments on interpretation and evaluation of SR&ED This document must be read and contemplated in its entirety in order to understand its meaning and intent. This is because many concepts in the characterization of SR&ED are interrelated and cannot be applied in isolation. Quoting extracts out of context is often inconsistent with a holistic interpretation. Examples are provided to illustrate important concepts. All examples are placed in boxes labelled as exhibits and are referenced in the text. They are intended to illustrate only the specific points referenced. Reading them in isolation or out of context can lead to erroneous interpretation. All examples are hypothetical but are representative of actual claims. Revenue Canada does not expect taxpayers to force their claims to fit any of the situations included for illustrative purposes in this document. By the nature of SR&ED, every claim is unique and is examined on its merits. No set of strictly factual tests can be sufficient to determine whether work is eligible as SR&ED. Hence, the opinions of individuals expert in the area in question will be required. Opinions must be based on the facts of each case. The SR&ED tax incentives are intended to encourage the performance of SR&ED in Canada. The eligibility of work as SR&ED is evaluated in terms of the process of performing SR&ED for the purpose of scientific or technological advancement in the categories of basic research, applied research, or experimental development as defined in subsection 248(1) of the Act, quoted above. SR&ED eligibility is not evaluated based on outputs, such as software products or information systems, which may or may not arise through a process that includes SR&ED. The success, failure, marketability, or commercial significance of work is not relevant to determining its eligibility as SR&ED. Work is not made ineligible because it is performed for an ultimate commercial purpose and, in fact, section 37 of the Income Tax Act requires that SR&ED expenditures be related to the business of the taxpayer. Software development can be eligible as SR&ED on the basis that it aims to advance computer science or information technology. In addition, computer programming that is commensurate with the needs, and directly in support, of an SR&ED project in any field of science or technology is a qualifying SR&ED support activity. The present document deals only with SR&ED projects that are intended to advance computer science or information technology through, or in relation to, the development of software. 2 SR&ED Project Definition An "SR&ED project" must fall within the definition of SR&ED contained in subsection 248(1) of the Income Tax Act. Such a project comprises a set of interrelated activities that collectively are necessary for the attempt to achieve the specific scientific or technological advance(s) defined for the project, are required to overcome scientific or technological uncertainty, and are pursued through a systematic investigation by means of experiment or analysis performed by qualified individuals. The SR&ED claim must be submitted showing the work structured as SR&ED projects so that Revenue Canada can make eligibility determinations. In whatever way companies choose to organize their software development efforts, the claim for tax credit purposes must only include the work that meets the SR&ED project definition above. Exhibit A gives a hypothetical example of how an SR&ED project might occur in the context of a company's product development project. Exhibit A Example of how an SR&ED project might occur within a company project. In this case, the company project is to develop a new version of a software product. Note that the SR&ED project is a subset of the company project and comprises the work focused on the technology development rather than the product features; it is not the same work described in different words. The example is intended only to illustrate SR&ED project structure; the field of work described is not an issue, nor whether the work is actually eligible. The point of the example is that the SR&ED project description can readily be evaluated to determine eligibility while the company project description cannot. Company project Project Title Property Records Management System (PRMS) Version 4.0 Objective To develop Version 4.0 of PRMS, an easy-to-use full- featured property records management system. Background XYZ Co. is a leading edge software products company. Our first PRMS product was developed in 1992. It is the most comprehensive and easy-to-use product in its class. We have installed over 100 licences to date. Project Activity This project was undertaken to develop PRMS 4.0, a new version required to maintain our competitive edge. Activities included: - review of customer requirements and competing products; - preparation of a functional specification; - development of prototypes; - design and development of: - faster query and update capability; - easier-to-use user interface; - user-defined field edits; - expanded import/export facilities; - new mail-merge utility; - multilingual capability; - alpha testing internal to XYZ Co.; - beta testing with selected customers. Advanced Features - much faster query and update capability; - re-designed easier-to-use user interface; - addition of user-defined field edits; - expanded import/export facilities; - new mail-merge utility and multilingual capability; - ability to work with databases greater than 1 GB. Project Uncertainties - uncertain what features were required by customers; - uncertain how to store user-defined edit rules; - uncertain how to provide bilingual prompts and error messages without impacting performance; - uncertain how to reduce complexity of the product; - uncertain how to access large databases faster; - uncertain how to manage random access memory. SR&ED project Project Title Using a Data Communications Approach to Improve a Custom Data Management System (DMS) Technological Objective To at least double DMS speed over that achieved in PRMS Version 3.5. Background XYZ Co. has developed a proprietary DMS as part of its PRMS product. The DMS works well with small data sets, but has excessive access times (greater than 30 seconds) with large databases (greater than 1 gigabyte (GB)). Project Activity A literature review showed that the relational data model used in the DMS could be inefficient in some circumstances. We decided to determine if a data communications model would achieve processing efficiencies, at the expense of additional storage space. A prototype packet data model DMS was created that was 75% faster than the existing data manager. Comprehensive benchmark tests were conducted to compare performance between the two data models. While some of the tables could be processed more effectively if they were in packet form, others were best managed through relational techniques. A hybrid approach involving both relational and packet data management techniques was experimentally employed in upgrading from PRMS 3.5 to 4.0. Technological Advances We developed a hybrid data management technique that improved query and update capability from greater than 30 seconds to less than 15 seconds in most problem situations. This new technique allowed PRMS to store and access databases greater than 1 GB (not possible with competing products at the time). Technological Uncertainties - impact on performance of using a data model designed for data communications in a relational environment could not be predicted; - inefficiencies resulting from a hybrid model using both relational and packet access against the same database might have reduced the improvements quantified for the prototype packet model DMS. Subsection 248(1) of the Act embodies the basic principle that SR&ED is a systematic investigation or search performed for the purpose of scientific or technological advancement. Thus, the taxpayer must define the objective or objectives of the SR&ED project in scientific or technological terms stating clearly the advance or advances to be sought, and must show that all the work performed on the SR&ED project was systematically directed towards the attempt to achieve that technological advancement. If the SR&ED project fails to achieve the intended technological advancement or branches off in a new direction, the work done can still be eligible if it meets the criteria, and a new SR&ED project with a new technological advancement goal might be initiated. The SR&ED project is tracked and claimed on the basis of the technology being advanced, not based on the benefits to the company or to users arising from the new features found in the software product or information system. Exhibit A illustrates that the taxpayer must correctly identify an SR&ED project in the context of a software product development. An information system usually addresses a business process that involves information processing and includes technology as one element. The technology may or may not have arisen through, or incorporate, SR&ED performed by the taxpayer. The SR&ED project is directly concerned only with the process of developing technology and comprises the activities that are necessary for the attempt to achieve the technological advancement. SR&ED project descriptions must be structured according to areas of science or technology. SR&ED is only indirectly concerned with the characteristics of software products, information systems, or business processes, and then only if their development requires achieving technological advancement. Management information systems (MIS) contain software programs that assist in the collection, manipulation, and presentation of data relating to the operational processes of the taxpayer's business. MIS functions include accounting, payroll, personnel records management, sales lead tracking, manufacturing or production management, inventory control, distribution, customer service, management reporting, electronic mail, electronic data interchange, and other similar software applications. Care must be taken to separate the benefits of automating or improving the operations of a business from the advances in the underlying science or technology that are being attempted. The benefits are not relevant to determining eligibility. While MIS projects may contain SR&ED, in many cases an SR&ED project will represent only a minor part of an MIS project. The SR&ED project definition is not intended to support the subdividing of SR&ED projects that have been correctly identified into smaller and possibly ineligible activities. The concept of the "set of interrelated activities that collectively are necessary..." embodied in the SR&ED project definition ensures that a project that is performed for the purpose of technological advancement is evaluated as a unit, provided that all the activities identified for the project are commensurate with the needs, and directly in support, of the attempt to achieve the technological advancement, as required by subsection 248(1) of the Act. The integration of several parts of a system may be or may include an SR&ED project. It may be valid to speak of system uncertainty, as discussed in section 3.2, at the level of the integration of the system. 3 The Three Criteria of SR&ED The three criteria for determining the eligibility of work as SR&ED are defined and explained in Information Circular 86-4. All three criteria must be satisfied in order for a project to be considered SR&ED. The three criteria are further discussed below in relation to software projects. 3.1 The scientific or technological advancement criterion A scientific or technological advance is the discovery by the taxpayer of technical knowledge that advances the understanding of scientific relations or technologies. For the purposes of this document, the advance must be in computer science or information technology. This document will usually refer to scientific or technological advancement as "technological advancement" for brevity and because this term applies to the majority of SR&ED claims. Exhibit B gives hypothetical examples of claimed technological advances that, as described and subject to the circumstances of the specific case, could or could not meet the technological advancement criterion. The taxpayer is expected to know information that is common knowledge, at the time of the work, for professional software developers familiar with the area of technology in question. A technological advance provides new knowledge, in such a setting, of the underlying computer science or information technology. That is, the new knowledge could be useful beyond the specific SR&ED project in which the advance was made. Just because a technology is new to a particular company does not, in and of itself, mean that the company is making technological advancement. A company is not expected to know a competitor's proprietary information and therefore might perform SR&ED similar to that performed by another company. Novelty, innovation, uniqueness, feature enhancement, or increased functionality in the product or process is not sufficient to demonstrate technological advancement. It is how such attributes arise (i.e., whether or not they arise through a process of SR&ED) that is important. An effort to achieve technological advancement will be accompanied by experimentation or analysis in a situation where there is technological uncertainty (as defined in section 3.2 below) about whether or how the technological advance can be achieved. It is the attempt to achieve technological advancement that is important in determining eligibility. A failure can increase knowledge of computer science or information technology by showing that a particular technological approach will not succeed. Thus, a failed SR&ED project can meet the technological advancement criterion. However, a failure (or a success) that does not result from a systematic scientific investigation and is not documented does not usually increase scientific or technological knowledge. The implementation of existing technology in a company is not evidence of technological advancement. For example, a company that implements a state-of- the-art computer system does not have SR&ED eligibility on that basis. It is only the experimental development of technology that is relevant to eligibility. Exhibit B Hypothetical examples of claimed technological advances that, as described and subject to the circumstances of the specific case, could be, or could not be, technological advances. Actual descriptions would give sufficient further details to explain why the work leads to technological advancement. Examples Possible technological advances "We developed a new approach to perform text searches in large distributed data bases." Comments: This is an indication that the taxpayer may have made an advance in computer science or information technology. "We researched possible image compression approaches without identifying an obvious solution to our requirements. We then developed, tested, and discarded various compression algorithms in an effort to find one that would meet our required specifications." Comments: Developing new algorithms in the attempt to achieve required performance indicates that the work was performed for the purpose of technological advancement, whether or not the software actually gave the desired performance. "Through experimentation, we developed a set of methods for bridging multiple teleprocessing monitors and database management system environments while ensuring data synchronization." Comments: The taxpayer had to intervene in the technology and conduct experimentation to advance the processing in a complex system "Customers required that our thermal modelling software provide more accurate estimates of the cooling requirements of micro-electronic components. Our analysis indicated that a finite element (FE) approach to estimating heat transfer to the cooling air might meet the requirements. We implemented an FE model and tested its performance through simulations and bench experiments." Comments: This could be the search for advancement in thermal modelling rather than strictly in computer science. Further information should clarify whether the software development is being claimed (a) as SR&ED in computer science or information technology, or (b) as a support activity to another field of SR&ED. Not technological advances as described "Version 5 of our retail store management software provided automatic invoice generation for corporate clients at the end of each month. This included new algorithms for the calculation of various applicable taxes. This was a new capability that meant that our software was technologically the most advanced available." Comments: This is an improved product feature. As presented, there is no indication of any technological advance. Statements such as the third sentence add no substance and should be avoided in SR&ED project descriptions. If there is a technological advancement, it should be specifically described. "The new operating system represented technological advancement to the company as its time-sharing capabilities were far more advanced than those of the operating system with which we were familiar. The project also significantly advanced our understanding of relational database technology applied to commercial applications." Comments: The use of existing technology and learning about its capabilities, even in a complex computing environment, are not technological advances. "We developed a new means to transfer data from the mainframe computer to the UNIX system via a 9-track tape drive." Comments: The taxpayer wrote a tape driver program operating under UNIX. This was routine software development for a programmer experienced in the UNIX environment. "We developed a new software system for computer-aided instruction embodying innovative object-oriented programming concepts and operating on a heterogeneous RISC workstation/personal computer network." Comments: On review of the claim, it was found that the development was achieved using commercially available application programming tools supplied in third-party software products. In contrast to the thermal modelling example above, this application (computer-aided instruction) is an ineligible area, i.e., social sciences or humanities. Therefore, in order to be eligible, the software development work would have to be SR&ED in computer science or information technology, and cannot be merely a supporting activity. Using the capabilities of existing software (such as application programming languages, graphical user interface builders, or report generation tools) as they are intended to be used and within their limitations is not, in and of itself, technological advancement in computer science or information technology. Such work could be a supporting activity if the project meets the three criteria. Extending existing programming environments, or overcoming their limitations, may give rise to technological advancement. Several areas of work, such as research in the social sciences and the humanities, are excluded from eligibility as SR&ED by subsection 248(1) of the Act. Business is generally considered to be a field of the social sciences or the humanities. Certain work within a business software development effort could be eligible as SR&ED if that work attempts to achieve a technological advancement in computer science or information technology. 3.2 The scientific or technological uncertainty criterion A scientific or technological uncertainty in software development arises when the solution, or the method of arriving at the solution, is not readily apparent to appropriately skilled and experienced software developers after they have analyzed the problem using generally known software development techniques. For similar reasons to those given in section 3.1, we will usually refer to scientific and technological uncertainty as "technological uncertainty." Exhibit C gives examples of hypothetical claimed technological uncertainties that, as described and subject to the circumstances of the specific case, could be, or could not be, technological uncertainties. Technological uncertainty can arise from the need to meet reasonable development project cost targets or product cost targets. For example, cost targets may require that technologically uncertain paths be attempted, although more costly and proven alternatives exist. Hence the existence of a technologically certain alternative does not negate the possibility of SR&ED work. Uncertainties that arise from lack of diligence or lack of appropriate expertise, such as the failure to use commonly available information, lack of programming knowledge, or lack of technical management expertise appropriate to the project (e.g., underestimating resources or budgets, or incorrectly specifying technological requirements) are not relevant to SR&ED eligibility. Only projects that involve resolving technological uncertainty can be eligible. Business risk, such as the risk of poor market acceptance or the risk of failure to achieve technical advancement objectives for other than technical reasons (e.g., the company runs out of money, loses key personnel, or abandons the project because of a new competitor), has no bearing on determining technological uncertainty. At least some source of technological uncertainty must be identified when an SR&ED project is initiated. Other technological uncertainties may become apparent at any time during the course of the SR&ED project and, depending on the situation, the work aimed at resolving them might be done under the original SR&ED project or might require a new one. Exhibit C Hypothetical examples of claimed technological uncertainties that, as described and subject to the circumstances of the specific case, could be, or could not be, technological uncertainties. Actual descriptions would give sufficient further details to explain why the work involves technological uncertainty. Examples Possible technological uncertainties "The problem was how to meet the required numerical specifications for a high- volume, interactive, distributed database. Our existing technology for multi- phase commit and record-lock synchronization would not allow us to meet the real-time, on-line data availability specifications." Comments: The claimant was a relational database management system (RDBMS) vendor. The technological uncertainty was created by the need for the company to push its technology beyond existing limits in order to meet opposing demands for database integrity and speed. "The manufacturer of the software product that we wanted to integrate into our own would not divulge the method by which it handled inter-process communication. It was unclear how we could interface the two programs." Comments: The technological uncertainty was created by the unavailability of third-party proprietary information. "Our system architecture was moving towards distributed databases and distributed processing. Viable directory services for locating distributed data in a network like ours with thousands of servers, were not available. It was uncertain how to proceed to overcome this." Comments: Given the state of software technology at the time the work was performed, this problem represented an uncertainty regarding which, if any, technological solution would succeed. "As a developer of expert system tools, we did not know whether the proposed logical architecture of our latest inference engine would give an increase in correct decision-making when measured against human experts in the target application domain." Comments: Since the success rate of human experts is given as a benchmark, the uncertainty is in computer science rather than in the application domain. The SR&ED project description expanded on the specific sources of uncertainty in information processing. Not technological uncertainties as described "Since this was a new system, the nature of the user queries could not be predicted and this created uncertainty as to which design was feasible." Comments: This is an uncertainty in how a business process will be affected by the introduction of a technology. It is not a technological uncertainty. "We were not sure if we could develop a program to calculate the highly complex financial data required. We had never done this before and we were not aware that any such system had been developed." Comments: Although complex, in this case the problem was amenable to standard software development techniques applied by competent professionals possessing sufficient skill in software development and mathematics. The second sentence is insufficient to indicate technological uncertainty. "Our company selects new technologies based on planned and advertised features and performance specifications. Each time this is done, we face the uncertainty of whether the supplier can deliver the enhanced technology and, if so, according to planned time frames." Comments: As described, this is a business risk. The description also suggests that, if there are technological uncertainties, they are borne by the supplier, not by the claimant. "The system had been designed on the assumption that orders would be filled in the same order that they were received. We were uncertain how to redesign it to process orders in a random sequence." Comments: The problem described is not a technological uncertainty. If there is any SR&ED in association with the system redesign, the specific technological problem must be stated. One type of technological uncertainty is "system uncertainty," which refers to uncertainty of the successful integration of software components or technologies. System uncertainty exists only if the integration is not achieved through routine engineering and requires changes to the basic design of the underlying technologies. System uncertainty is not necessarily related to the size of a system: it is possible for very large systems to be built using proven technologies or for a system of only two components to have technological uncertainty associated with the integration. The concept of system uncertainty does not justify a claim for the work of developing an entire system when the technological uncertainty only affects part of the system. 3.3 The scientific and technical content criterion This criterion has both methodological and personnel aspects. A systematic investigation or search by experiment or analysis must be demonstrated. This means that a systematic investigation or search must have been performed, and that the taxpayer must have documentation or records to substantiate the work claimed. The documentation requirements are described in section 6. The personnel responsible for directing and performing the SR&ED project must have the professional skills or experience commensurate with the requirements of the project. The concept of building up knowledge through a systematic investigation involving experimentation or analysis is applicable to eligible software development as to other fields of SR&ED. In eligible work, the systematic investigation must be performed for the purpose of technological advancement. These characteristics distinguish experimental development, which is eligible, from routine development, which is ineligible. Software development is normally a systematic process but it is not SR&ED if it is not experimental and is not pursued for the purpose of technological advancement. The use of formal software development methodologies and software development tools and environments do not indicate whether software development is experimental or routine. It is the presence of experimentation that is relevant. Proceeding by trial and error without an experimental plan suggests the lack of a systematic investigation. The taxpayer must document the existence of a systematic experimental investigation in any software project claimed as SR&ED. Areas of work where particular attention should be paid to this requirement are those that would reasonably be interpreted as routine development without such documentation. Examples could include claimed projects based on testing a proprietary development methodology in software development projects performed by the taxpayer, performance enhancement work, user interface development, and improving scalability in large information systems. In all such cases, the technological problem must be clearly posed, the intended technological advancement must be specific and verifiable, experimentation must be conducted, a systematic testing protocol must be established to test for the achievement of the objectives, quantitative or objective measurements must be made, and technological conclusions must be drawn. The work must be necessary for the purpose of achieving advancement in computer science or information technology rather than simply for meeting a business objective. 4 Project Examples Examples of areas of work in which eligible SR&ED projects frequently occur, or frequently do not occur, are listed for illustrative purposes in Exhibit D. Eligibility is always determined on a case-by-case basis for each project. Exceptions are expected from both the "frequently eligible" and "frequently ineligible" categories because projects will be judged to be eligible as SR&ED if they meet the three criteria and are organized into SR&ED projects. The examples in Exhibit D refer to areas of work that are claimed as giving the basis for eligibility (i.e., the core work is in these areas). The examples do not refer to activities that may support an SR&ED project. Exhibit D Examples of areas of work that frequently contain, or frequently do not contain, SR&ED projects in computer science or information technology Frequently eligible - Projects that advance information technology at the level of operating systems, programming languages, data management, communications software, and software development tools. - Research into methods of designing, developing, deploying, or maintaining software. - Software development that produces advances in generic approaches for capturing, transmitting, storing, retrieving, manipulating, or displaying information. - Experimental development aimed at filling technological knowledge gaps, as necessary to develop a software program or system. - Research and development of software tools or technologies in specialized areas of computing: examples have occurred in image processing, geographic data representation, character recognition, artificial intelligence, and many other areas. Frequently ineligible - Business application software development, customization, and graphical user interface building limited to using commercial off-the-shelf software tools and development environments. - Information system development of any size that does not go beyond using known development methods and existing software tools within their capabilities. - Routine enhancements to an existing software system, often aimed at incremental addition of features and functions. - Routine software upgrading or maintenance, such as many instances of porting software to a new operating system, converting to a new programming language, writing format translators for interfacing to third-party software systems, writing hardware device drivers, code optimization, fine tuning, and debugging. 5 Activity Issues This section deals with the qualification of specific activities that may support an SR&ED project in software or that often delimit the project, either in time or by setting the limits of business organizational functions that qualify. It is emphasised that the activities listed below relate only to the SR&ED project as defined in section 2 of this document, and not to a project to develop a software product, information system, or business process. Nothing in this section is relevant if the activities do not occur within an SR&ED project. If the project is not eligible, none of the individual activities discussed below can qualify. 5.1 Activities that usually qualify within SR&ED projects For an SR&ED project, all activities that flow systematically from the definition of technological requirements to testing and documentation qualify when necessary and sufficient for the attempt to achieve the technological advancement and resolve the technological uncertainty. Qualifying activities include: (1) technological feasibility study (subject to the further comments in section 5.2); (2) research into techniques, methods, and status of computer software as a technology, as it directly supports the intended technological advance; (3) reviews of existing, emerging, and competing technologies that are required to define the intended technological advance; (4) technical specification preparation to the extent that it is relevant to defining the technological advancement and technological uncertainty to be addressed (subject to the further comments in section 5.3); (5) SR&ED project team training directly related to the technical needs of the SR&ED project*; (6) technical analysis and design; (7) tool and process development; (8) programming; (9) testing the software that embodies the technological advance (subject to the further comments in section 5.4); (10) preparation of development documentation, usually as written by the SR&ED project technical staff (subject to the further comments in section 5.6 and section 6); and (11) SR&ED project planning and control, including software quality assurance that is essential to the SR&ED. * For companies claiming the proxy amount, this is part of the overhead included in the proxy. 5.2 Feasibility study and planning In the initial phases of a company project, a business plan is often developed that examines the technical, financial, marketing, and other (such as manufacturing and legal) aspects of the proposed company project. Only the technical planning activities can qualify as SR&ED, as specified below. The taxpayer should be able to show that the technical planning activities claimed are only those directly supporting the SR&ED project. Technical planning for an SR&ED project may include defining technological objectives, assessing technological feasibility, identifying technological uncertainties, estimating the development time, schedule and resources, and high level outlining of the technical work. The planning would not normally proceed if the technological feasibility study is not favourable. Alternatively, the technical plan may be completed but the actual experimental project is not performed. If the project does not proceed beyond the feasibility study or the technical planning, the work to prepare the feasibility study or the technical plan can only be eligible if it meets the three criteria in its own right. In an eligible SR&ED project that is actually performed, the preparation of the feasibility study and technical plan qualify. 5.3 Market research versus user requirements Market research activities do not qualify. Market research can generally be described as the study of what is available or what is desired in the market, or of market conditions. Market research activities include those directed at market development and market verification, general market identification, market demonstration, customer opinion surveys, and development of customer acceptance. The market could range from one organization to a large population of potential customers. User requirements definition is the identification of system features or functions that are required by a particular prospective user or users, and the development of a coherent set of specific functional or technological requirements. If the user requirements definition only considers the software as a "black box" to which inputs and outputs are specified, the user requirements definition does not qualify. A user requirements definition of this nature defines the functionality of the software as opposed to the technological advancement purpose or technological uncertainty that would be present in an SR&ED project. The user requirements definition qualifies only if it is part of an eligible SR&ED project, and if it specifies the technological advancement sought and the technological uncertainty faced. The user requirements definition should produce technological documentation intended for use in the design phase of the SR&ED project, rather than simply identify the required functionality. The extent of the qualifying user requirements activities must be commensurate with the needs of the SR&ED project. If a company has one or more units, sometimes called product management groups, whose functions include both market research and technical specifications development, the company must separate these activities and claim only the work of developing technical specifications for SR&ED projects, otherwise the entire effort of such units will be considered not to qualify. This does not imply that companies must generate separate documentation for technical specifications but that the cost accounting system must separate the time spent on technical specification preparation from non-qualifying activities. 5.4 Testing Qualifying testing is the activity in which the software arising through SR&ED is verified against technological advancement goals established early in the SR&ED project. Testing is usually required as part of the systematic experimental investigation as described in section 3.3. Qualifying testing can occur in many phases of an SR&ED project in software. Testing qualifies provided that, as described further in this section, (a) it is necessary and sufficient for the attempt to achieve the technological advance and resolve the technological uncertainty of the SR&ED project, (b) it is systematic, and (c) it is documented. Testing performed by the software development team that is necessary and sufficient for the achievement of the technological advance and the resolution of the related technological uncertainty and is performed in controlled conditions with feedback from all testers into the development process qualifies as a supporting activity for an SR&ED project. The testing of software by users does not qualify either as SR&ED or as a supporting activity for SR&ED. However, the associated activities of the development team in modifying the software in response to test results qualify under the same conditions as mentioned in the previous paragraph. Testing that deals primarily with user acceptance, suitability, marketability, or competitive assessment does not qualify. 5.5 SR&ED project completion The SR&ED project is complete either when the technological advancement has been demonstrated to be achieved consistently under the appropriate range of circumstances and the associated technological uncertainty resolved, or when it can be determined that the intended technological advancement will not be achieved. An SR&ED project in software development is considered to be complete not later than the earliest of when the product, program, or system incorporating the technological advancement is used commercially, made generally available to customers, accepted by the client or end-user, or employed in a way which provides beneficial use to its users, regardless of whether it still contains defects. These events represent the latest possible cut-off points: completion will often occur earlier based on the achievement of the SR&ED project's technological advancement and resolution of the technological uncertainty. If problems emerge during the use of software and the work needed to resolve them meets the three SR&ED criteria, then the work may become a new SR&ED project. The qualifying activities in either the old or the new SR&ED project do not include the activities associated with finding out that a problem exists once a product is being used commercially. Routine defect correction and maintenance do not qualify as SR&ED activities. Support activities such as training for persons other than SR&ED project team members do not qualify, nor does training of SR&ED project team members when the training is not required for a claimed SR&ED project. The training of users to test the system does not qualify. Activities normally associated with customer service or telephone support centres do not qualify. 5.6 The activity of documenting the SR&ED project Documenting the experimental process and its results are normal in all fields of SR&ED. Documenting the SR&ED investigation as outlined in section 6 by development team members qualifies as part of the SR&ED project. Writing the documentation necessary to complete qualifying testing of an SR&ED project qualifies. Examples include internal technical documentation and preliminary documentation necessary to support only the qualifying testing that is described in section 5.4. The number of copies of documentation produced must be consistent with only the qualifying testing and the company's record-keeping needs. Preparing the manuals to be supplied with the commercial product or the delivered system does not qualify within the SR&ED project. Preparing electronic documentation intended for software users, such as the on-line, context-sensitive help documentation found in many software products, is not a qualifying SR&ED activity. Preparing material to support sales or to expand markets, such as tutorials, brochures, and sales proposals, does not qualify. Large print runs or high quality printing of any documentation are usually not needed to meet an SR&ED objective and are expected to occur only after the end of, or outside, the SR&ED project. 6 Documentation Requirements This section deals with the documentation that is required as supporting evidence during an SR&ED audit by Revenue Canada. This section does not deal with the requirements of Form T661, Claim for SR&ED Expenditures Carried On in Canada that is filed as part of the tax return when claiming SR&ED expenditures. The taxpayer must be able to present evidence that the SR&ED was performed as claimed. It is the taxpayer's responsibility to maintain adequate records to support the claim. The records must be sufficient to demonstrate that the three criteria of SR&ED were met. They should reveal how the research steps of the systematic investigation correlate with the resolution of the technological uncertainties stated in the SR&ED project descriptions and should indicate which technical alternatives were contemplated through the prosecution of SR&ED. The records are expected to cover the intended technological advancement of the SR&ED project, the approach adopted, the activities performed by the technical personnel, the time spent by all individuals claimed, and the results of the efforts to achieve the technological advance. The taxpayer must be able to show that claimed activities are directly in support of an SR&ED project, particularly with regard to initial, cut-off, and support activities. Dated documents or records, however informal, created at or about the time that the work was carried out must be present as evidence of the work performed. One of the objectives of the SR&ED tax incentives is to encourage the performance of SR&ED by small companies. In this context, it is recognized that the appropriate detail and sophistication of documentation will depend on the size of the taxpayer's organization and the magnitude of the claim, and that smaller projects may have less documentation than larger projects. However, if there is no documentation or record to substantiate the project, the claim will be rejected. As a guideline, a set of documentation that Revenue Canada would typically expect to find available includes the following: (1) the earliest SR&ED project plan including project objective statement and any subsequent modifications, showing the rationale for design choices supported by factual comparison of the alternatives considered; (2) design review documents, intermediate designs, and status reports or technical meeting minutes; (3) project notebooks; (4) backup versions of commented source code or other evidence representing major phases of development and identifying the author(s) of each module and changes made; (5) "as built" system diagrams and design overviews; (6) test plan and test results as specified in sections 3.3 and 5.4; (7) personnel time records and activity reports (see below); and (8) staff resumes. Revenue Canada will consider other supporting evidence, as necessary and appropriate, in evaluating SR&ED claims. Although much project management and technical notebook information is maintained electronically, it is the taxpayer's responsibility to provide documentation or records. Every care should be taken to protect the relevant backups or to obtain paper copies before deleting files. The taxpayer must be able to substantiate the allocation of individuals' time to specific activities within specific SR&ED projects. This applies both to individuals whose time is spent all or substantially all on SR&ED and to individuals whose time is spent partially on SR&ED. For audit purposes, it must be possible to cross-reference the activity descriptions and expenditures. The number of hours or days spent on each activity by each person must be tracked and recorded at the time the work is performed in time records or activity reports. For contractual personnel, invoices that do not include, or cross-reference to, such activity information are insufficient. 7 Preparation of These Guidelines The preparation of these guidelines was initiated by the review of SR&ED in the field of information technology, announced in the 1995 federal budget. Public consultations were held by Revenue Canada and the Department of Finance Canada in the fall of 1995. Based on recommendations received, the starting point for drafting this document was Appendix B.1 of Information Circular 86- 4R2, Scientific Research and Experimental Development, combined with Part 6 of Information Circular 86-4R3. Several draft versions were prepared in late 1995 and the first half of 1996, and were reviewed by, among others, a committee representing Revenue Canada, the Department of Finance Canada, Industry Canada, and the National Research Council (NRC) as well as by a panel of experts, including members nominated by the Canadian Advanced Technology Association (CATA) and the Information Technology Association of Canada (ITAC) and consisting of: - W. Morven Gentleman, Ph.D., Institute for InformationTechnology, NRC; - George Hare, Ph.D., George Hare & Associates Inc.; - Gord Harris, Amarok Systems Inc.; - Peter Jordan, Microstar Software Inc.; - Jeffrey Laks, Newbridge Networks Corporation; - Ian U. Reid, Sierra Systems Consultants Inc. CATA, ITAC, numerous individual companies, organizations, and individuals have also contributed their ideas and time throughout this process. A draft of this document was distributed widely for public comment during June and July 1996. The submissions received have been considered in drafting the present guidelines.