Clevor Technologies Inc. v. The Queen: Implications for Software and SR&ED
Clevor Technologies Inc. v. The Queen: Implications for Software and SR&ED
On August 14, 2019, the Tax Court of Canada (TCC) delivered a ruling on a software-related Scientific Research and Experimental Development (SR&ED) investment tax credit (ITC) claim. In the case of Clevor Technologies Inc. v. The Queen, Justice Bruce Russell denied the SR&ED ITCs of Clevor Technologies, stating that the company did not identify a technological uncertainty, used “trial and error” approach (which is not accepted as a valid SR&ED methodology), and lacked evidence of testing results.
This article will take a closer look at this case to provide the following:
- An overview of the case against Clevor Technologies Inc. (“Appellant”)
- Key arguments & lessons learned from Justice Russell’s ruling
Clevor Technologies Inc. v. The Queen: An Overview
The case was unusual as the president of the company is now deceased and the daughter – who does not have formal computer or software development training and had not been employed by the Appellant at any relevant time – was the sole witness despite having no personal or direct knowledge of the Appellant’s activities in 2013 relevant to this appeal. It was left unexplained why the Appellant did not call to testify any current or former employees of the Appellant who had had any significant involvement in the Appellant’s activities in 2013 underlying this SR&ED claim.
The Appellant appealed a reassessment of their SR&ED investment tax credit claim for the 2013 taxation year. The CRA denied $72,046 of SR&ED eligible expenditures as well as an ITC of $24,991. The Appellant claimed two projects were eligible for SR&ED investment tax credits during this taxation year.
Prior to 2013, the Appellant developed a sophisticated project management software named the “Clevor Schedule Optimizer” (CSO). The CSO software could determine the timing and sequencing steps for optimal completion of the project when variables were input to the system. Both SR&ED projects under review dealt with the CSO software.
The first project stemmed from the CSO software interfacing with third-party software that provided the “front end” to the customer in the linked operation of the two applications. In early 2013, one of the front-end applications, Oracle’s Primavera, released a new version with an updated “application programming interface” (API). The new API blocked CSO from integrating with Primavera, Oracle published a reference of its API changes, but they were insufficient for the necessary code changes for CSO to be compatible with the new API.
The Appellant’s hypothesis was:
[t]he hypothesis generated was that the changes made to the API that affect [the Appellant’s] integration could be determined if developers systematically tried various combinations of XML items [an aspect of API code] and added/removed different item fields to eliminate the errors, and warnings, generated when a partial XML file was used to update a project in Primavera 6. The knowledge gained from this systematic investigation improves our understanding of the new schema file and help[s] [the Appellant’s] future integration work.1
While the Respondent argued that learning about third party products does not establish a technological advancement, Judge Russell stated:
that conceivably technological advancement might be found in the development, through scientific methodology and not standard processes or routine engineering, of some new process for ascertaining the unpublished content of the new P7 API code.2
Judge Russell also ruled that the hypothesis and experimentation presented by the Appellant was trial and error, and therefore routine engineering, which is not considered an approved method of experimentation for SR&ED eligible projects. Judge Russell ruled that the Appellant did not identify a technological uncertainty that could not be resolved by a method outside of routine engineering; additionally, there was a lack of evidence to any testing results.
The second project was “work seeking to incorporate the ‘best lateness and overhead calculation’ to enhance CSO’s ability to calculate optimal timelines for concurrently run projects.” The Appellant explained that in their analysis some projects were significantly delayed while others were on time due to lateness cost rate setting and a lack of project duration control. The Appellant proposed five courses of conduct which were submitted as “hypotheses”:
- Lateness – use a lateness cost interest to the lateness cost calculation;
- Lateness – use a compound lateness cost interest to the lateness cost calculation;
- Minimize fragmentation – use a standardized project overhead cost;
- Minimize fragmentation – implement a critical path analysis to find the reason from duration point of view;
- Minimize fragmentation – implement bottleneck resource analysis to find the reason from resource point of view.3
The Appellant tested the first three using multiple datasets for different cases where it was able to conclude that the incorporation of a compound lateness cost and standard overhead cost created the best results emulating human decisions.
The Respondent argued that there was no technological uncertainty and the Appellant used an established methodology “metaheuristics” to solve their issues. The Respondent provided an expert witness, Dr. Pandey, to explain his reasoning. The Appellant did not provide any expert witnesses.
Judge Russell accepted the expert witness provided by the Respondent. The judge ruled that the Appellant failed to prove there was any technological uncertainty for these projects and, therefore, they were not SR&ED eligible projects. The case was dismissed.
Justice Russell’s Ruling: Key Arguments & Lessons Learned for Software and SR&ED
This case was unique in that the owner of the company, while this project was being developed, died and the Appellant was unable to provide an expert witness; however, it may be significant for future software-related SR&ED cases.
There are a few key takeaways that stand out regarding software and SR&ED.
- Trial and error/routine engineering: Judge Russell’s ruling that systematically trying various combinations of code was deemed trial and error as this is a common testing practice in the software industry. The burden of proof of the five questions used to determine SR&ED ITC eligibility applies to computer science like the other fields.4 This ruling could impact future SR&ED eligible claims.
- Technological uncertainties: The Appellant was unable to prove they had identified a technological uncertainty and sought to reduce or eliminate that uncertainty through experimentation or analysis; consequently, Judge Russell ruled that the Appellant did not establish a technological uncertainty. The burden of proof lies with the taxpayer to prove that SR&ED related activities have been carried out.
- Contemporaneous documentation: The Appellant was unable to provide testing results for their claims. Maintaining a well-organized and complete collection of documentation is imperative for the success of SR&ED applications in the unfortunate event that the primary researcher is no longer available, for various reasons up to and including death.
Computer science and software development have become essential to new or improved products/services in many sectors including SR&ED. It is imperative that rulings such as this one are carefully monitored, as they can have a significant impact on how software-related claims are processed at the CRA.