In the article entitled Revised Guidelines for Software Development Projects, we discussed generally the technical guidelines of claims as related to software projects. In this article we will expand on one of the three necessary eligibility criteria, namely that of Technological Advancement. Subsection 248(1) of the Income Tax Act, states: “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 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, …”.
Each of the three components of the definition requires that a scientific or technological advancement must be sought. In general, an advancement is the discovery of new scientific or technological knowledge that increases (the taxpayer’s) understanding of scientific relations or technologies. It is important to note that simply creating new software products or processes is not, in and of itself, technological advancement. It is HOW (by what process) the advancement was achieved that is important. In this case, it must be through a process of experimentation or analysis where there is technological uncertainty. It is key to understand the difference.
In our experience, one area where software claims are denied, is because they have been submitted on the basis of having developed a new software product or a software product with new functionality or features. To make the case, they should have been submitted on the basis of achieving a technological advancement which was embodied in the new software product. It is up to the claimant to identify the difference. Fortunately, the new Information Circular (I.C. 97-1) provides some useful examples of technological advancements (which have been paraphrased below):
1. Development of a new approach to perform text searches in large distributed data bases. (Advances knowledge on text search methods).
2. Research into possible image compression approaches to solve a specific technological uncertainty. None were found. The claimant then developed, tested and discarded several compression algorithms. (Advances knowledge on compression approaches. Note this meets the criterion even though they failed).
3. Development of a set of methods for bridging multiple teleprocessing monitors and data base management system environments while ensuring data synchronization. (Advances knowledge of processing in a complex environment).
It also lists some examples which are NOT technological advancements as stated (again paraphrased):
1. Development of a new software product for a retail environment including algorithms for the calculation of various applicable taxes. (Improved product functionality, not technological advancement).
2. The claimant used a new operating system whose features represented technological advancement for the company compared to another operating system previously used. (Use of, or learning about existing technology is not an advancement).
3. Development of a new tape driver operating under UNIX. (Standard and routine programming for an experienced programmer).
4. Development of a new software system for computer aided instruction embodying innovative object oriented programming concepts and operating in a heterogeneous RISC workstation/PC environment. (On review of the claim, it was found that the development was achieved using industry available application programming tools. Additionally, the field of computer-aided instruction is in an ineligible field of the social sciences).
Since technological advancement is one of the MUST criteria, very carefully identify the advancements you are seeking so as to be sure they are not simply routine development, use of existing tools, improved product features or are activities in an ineligible field of work. Consider the advice of a knowledgeable consultant.
Revenue Canada will allow SR&ED claims where the taxpayer demonstrates three requisite criterion - technological advancement, uncertainty and content. If a project fails to satisfy one of these three criteria it will disqualify as SR&ED. In this article we identify issues related to technological content. We have discussed the other two criteria, namely uncertainty and advancement, on other pages in this web site.
The Income Tax Act defines SR&ED to embody, among other things, a systematic investigation or search in a field of science or technology by means of experiment or analysis. Revenue Canada takes this to mean that a valid SR&ED project must exhibit technological content. Further, the technological content requirement has three elements; a scientific or experimental methodology, documentation and the experience of personnel. The first two, methodology and documentation have been sanctioned by the courts. The third, experience of personnel, has yet to be tested in the courts.
Experimental or analytical methodology
Revenue Canada regards the methodology requirement to incorporate a systematic search or investigation involving the formulation of a theory or hypothesis, testing this hypothesis by experiment or analysis, and a statement of logical conclusions. The process of experimentation or analysis includes all activities that flow systematically from the definition of technological requirements to testing and documentation. According to Revenue Canada the following activities will qualify as SR&ED when they are necessary and sufficient in attempting to achieve technological advancement to resolve the technological uncertainty.
Documentation
Revenue Canada requires that documentation must be prepared on a contemporaneous basis to demonstrate that SR&ED activities have actually occurred. For example, the types of documentation they would expect to see on an audit of an information technology project would include:
Revenue Canada stated policy is that the appropriate detail and sophistication of documentation will depend on the size of the taxpayer’s organization and the magnitude of the claim. Smaller projects may have less documentation than larger projects, and smaller companies are to be given more leeway in these requirements. However, if there is no documentation or record to substantiate the project, the claim will be rejected.
Experience of Personnel
In order to meet the experience requirement Revenue Canada takes the position that the personnel responsible for directing theSR&ED project must have the professional (technical) skills or experience commensurate with the needs of the project.
Specific Software Issues
Software development involves a systematic process progressing from operational or system analysis, through functional specifications to technical specifications, programming, testing and debugging prior to commercial use. It could be argued that software development always meets the methodology element of the technological content criteria. However many claims are rejected because they do not shown or cannot show that the methodology was experimental or analytical in nature.
In order to support a valid claim, records should indicate that the work should show that the work differs from routine development. Evidence of differentiation between routine and experimental work is the existence of technological uncertainty toward which the work is addressed, and evidence that there have been iterative attempts to resolve this uncertainty.
Where a problem is resolved successfully on the first attempt, the activities are generally considered to be routine development. In such cases there is a greater need to substantiate an experimental or analytical methodology. Also, where an inexperienced developer might use an iterative process, their work would not qualify on the basis of inappropriate experience.
In additional, there can be audit issues where projects make use of powerful development environments and tools which can forego the need for formal development methodologies. This often leads to inadequate documentation of the SR&ED activities and hence the rejection of a claim. Even where experimentation is conducted using these development tools there is a risk that the work may be judged to be “blind trial and error”, and not involving a systematic investigation.
Revenue Canada generally takes the position that user interface development, adding new functionality, performance enhancement projects, porting or migrating to new platforms, or work on management information systems and projects that involve issues of scale will generally be considered in the nature of routine development. Where these types of projects involve qualifying work, it is useful to substantiate a claim at the time of an audit, with a formal development methodology, along with contemporaneously prepared documentation.
It would be prudent to ensure that appropriate documentary records are created. Revenue Canada expects to see such records as project plans, design review documents, project notebooks, evidence of major phases of the development showing the iterations, test plans and test results, and personnel time and activity records. Further these records must differentiate between SR&ED activities including the needed support activities and other non-eligible routineactivities. Other supporting evidence as necessary and appropriate may be accepted. Electronic versions are acceptable.
To have a valid SR&ED project claim, Revenue Canada looks for the existence of three criteria, Scientific or Technological Advancement, Scientific/ Technological Uncertainty and Scientific/ Technological Content.
Revenue Canada’s administrative guideline on software development, IC97-1, states “A scientific or technological uncertainty in software development arises when the solution, or 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”.
It is important to understand the difference between technical uncertainty and technological uncertainty. Technical uncertainty, which will not meet the RCT criterion, can be any technical question that may be present if proper analysis of a problem has not been conducted, such as the non-existence of a functional specification, or perhaps a question on how to perform complex mathematical calculations. Both these issues can be resolved by proper technical analysis. In other words, there is nothing about the technology which renders these questions technologically uncertain. It is well known that computing technology can perform complex mathematical calculations. If the mathematical representation can be written, the computer can be programmed to execute it. Nor does the absence of a functional specification, in and of itself, imply a technological barrier exists. It simply implies some necessary analysis has not been performed. Note that these two simple examples exist at the level of the application not at the level of the technology.
A technological uncertainty, on the other hand, implies that once a technical analysis has been done (say a functional specification has been prepared or the mathematical equations have been written) and there is an uncertainty as to whether it is technologically feasible to achieve the objective, or it is unknown how it can be achieved using standard approaches, then we have a valid uncertainty for an SR&ED claim.
Several examples of technological uncertainty have been offered in IC 97-1. The first example speaks to an uncertainty by a data base development company that needed to achieve new high volume real time data availability and data base integrity objectives in their technology which their existing approach was unable to achieve. There was no standard approach known in the industry that the vendor could use to solve this problem.
Another example given is an uncertainty that was created by the unavailability of a commercial vendor’s proprietary information which was needed by the claimant to achieve an interprocess communications objective.
A third example cites an uncertainty about viable directory services for locating distributed data in a network of thousands of servers. There was uncertainty as to whether any approach could solve this problem.
IC 97-1 also gives several examples of uncertainties which do not meet the technological uncertainty criterion.
The first cites the claimant to be uncertain as to the nature of the user queries and this gives rise to an uncertainty as to a feasible design. This is not technological uncertainty but an uncertainty about a business process which, once resolved, would eliminate the technical question. If however, the claimant went on to define the nature of the queries and attempted a design based on this knowledge and subsequently discovered a technological problem to exist which on the surface was not resolvable based on standard knowledge available, then that would be eligible uncertainty.
A second example cites a claimant’s uncertainty as to whether some commercially available software technology will meet its own published specifications and this gives rise to an uncertainty by the claimant as to how to deal with this in their development project. This is a business risk and simple testing can resolve the technical question. If, however, the claimant then went on to attempt to resolve any existing shortcomings and discovered standard approaches would not work, that again would present eligible uncertainty.
A third example cites a highly complex mathematical calculation must be performed and the claimant is unsure whether they can do that. This speaks more to inexperience than it does to technological uncertainty. Again, if the claimant attempted a resolution and discovered they were not able to achieve the needed precision or speed using standard industry knowledge or approaches. This again would give rise to a valid uncertainty.
Note that the three examples of ineligible uncertainty as stated all might actually be eligible if presented later in the development process, that is, after the industry standard approach has been shown to fail.
Many development projects have both technical and technological uncertainties. Be careful not to jeopardize eligible project claims by inappropriate statements which speak to technical or business risks and not to technological risk.
The long awaited Science and Technology review for software development projects has been completed - and not much is different - save some new administrative guidelines [8]. Indeed, (RCT) took some pains to point out that after a thorough review of the Act, it was concluded that the existing legislation adequately covered software development. If there was a problem, it would be addressed through more thorough enforcement of existing rules - particularly the requirement for adequate documentation.
RCT in conjunction with the Canadian Advanced Technology Association (CATA) delivered a series of seminars across Canada to inform interested parties on the new guidelines. Members of Braithwaite attended several sessions in different venues.
The seminars followed a predictable agenda. First there was the usual material about Regulation 2900 highlighting the three necessary criteria - Scientific or Technological Advancement, Uncertainty and Content.
ADVANCEMENT - It was pointed out that the advancement criteria for software development could only be met if new knowledge was produced in fields of computer science or information technology. In other words, development of a new software product per se would not meet this criterion.
UNCERTAINTY - The uncertainty must be stated at the outset of the (SR&ED) project and the solution or method of arriving at the solution must not be readily apparent for knowledgeable practitioners. It is expected the claimant should know what is common knowledge in the field. System uncertainty was also discussed. It is eligible but must also create an advancement.
CONTENT - This criterion is met if the process by which the solution was arrived at shows evidence of a systematic search or investigation (for the advancement) by means of experiment or analysis performed by appropriately skilled people. The analysis must be theoretical analysis of a scientific or technological problem and not routine systems or requirements analysis.
This was followed by a presentation defining the SR&ED project. A SR&ED project starts at the point where the Uncertainty is defined and stops at the point where all steps to its resolution are known. A project also stops if the original technological objectives are aborted or changed.
A model was used to help define the differences between a SR&ED project and a business initiative. At the base is the field of Computer Science. The next level is Information Technology. On top of these two are three more layers - the business process, the firm and finally the commercial environment. Only projects meeting the three criteria in the bottom two layers will be considered.
There was also a clearer definition of the software Industry segments. These included shrink wrap software developers, custom application developers, systems integrators, software development as a part of another product and finally scientific/technical software. All of these, including MIS developments, may have eligible projects if they meet the three criteria. In other words, there are no excluded categories of eligible software development.
These new guidelines contain a lot of information and will provide the reader with some good insights. Review the new guidelines before filing a new claim, or before attending an audit meeting with RCT.
Since RCT has agreed the program still applies to software development projects, review all such projects for SR&ED content, with a view to filing a claim. Particularly important would be a review of software development done by financial institutions who did not claim during the moratorium period.
Links:
[1] http://www.cra-arc.gc.ca/taxcredit/sred/publications/ap9501r-e.html
[2] http://www.cra-arc.gc.ca/taxcredit/sred/publications/858a-e.html
[3] http://www.cra-arc.gc.ca/taxcredit/sred/publications/softguide01-e.html
[4] http://www.cra-arc.gc.ca/taxcredit/sred/publications/858a-e.html
[5] http://www.cra-arc.gc.ca/taxcredit/sred/publications/softguide01-e.html
[6] http://www.cra-arc.gc.ca/taxcredit/sred/publications/858a-e.html
[7] http://braithwaite.ca/main3.cfm?id=B110CF02-80C6-EFE0-D772C2A03B88D879
[8] http://www.cra-arc.gc.ca/taxcredit/sred/publications/softguide01-e.html
[9] http://www.cra-arc.gc.ca/taxcredit/sred/publications/softguide01-e.html
[10] http://www.cra-arc.gc.ca/taxcredit/sred/publications/858a-e.html