Software and the Technological Uncertainty Criterion
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.
The Strategy
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.
Links
- Guidance on Eligibility of Software Projects for SR&ED Tax Credits and Developing and Documenting Claim ”
- IC 97-1 Scientific Research and Experimental Development - Administrative Guidelines for Software Development ”
- IC 97-1 Scientific Research and Experimental Development - Administrative Guidelines for Software Development ”


