SR&ED Eligibility in Technology: 3 Lessons from the CRA

On November 1st, 2018, the CRA held a presentation in Montreal regarding SR&ED eligibility, specifically tailored for the Information Communications Technology (ICT) field. This focused on a case study in blockchain, but the takeaways were applicable to all companies in the ICT sector who claim or wish to claim SR&ED tax credit.

The presentation was divided into two parts—the first being for executives, and the second being designed for technical leads, where the CRA discussed trends and issues they frequently see with SR&ED filings. This article will focus on the latter part of their presentation.

Here are our three main takeaways:

Keep All SR&ED Documentation… And Format It Carefully

One thing frequently being seen in filings with the CRA is poor record keeping in the ICT sector. Let’s face it—record keeping in software is hard—and it’s not like we have physical prototypes like those in traditional manufacturing. During the seminar, the CRA made some very useful suggestions for tech companies in what information to keep.

First, consider taking screenshots of sprint plans (usually bi-weekly, or monthly)—these can be used to help demonstrate timelines, and any notes or difficulties you are facing can then be used as contemporary information when writing your SR&ED technical report. Keeping these, or any other project planning documents you have available is looked on very favorably by the CRA.

Second, don’t just keep an issue log—if a mere issue log is submitted in an audit as supporting documentation, the CRA can evaluate the issue tracker line by line, and individual issues usually don’t look like SR&ED. Instead, consider adding in fields on your issue tracker to tag it by SR&ED project (not company project), and add a short reason when creating the issue of why this is SR&ED eligible.

Click here to learn everything there is to know about the SR&ED tax credit

Finally, if you really want to be prepared, consider creating a dedicated folder on a shared file system for each of your SR&ED projects. Then, each time a record is made, stash a dated copy in that folder. Then, once a month or quarter, sit down with your team to look back and see if any details are missing, or if any project could potentially be added. This will ensure that as the year goes on you have a good record of your SR&ED and no work goes unnoticed over the course of the year.

Don’t Write Reports Retrospectively

The CRA distinctly urged companies to keep detailed contemporary information, as they have clearly seen issues with companies writing retrospectively. There are a few big issues—looking back, it’s easy to miscategorise time, or misremember the exact details of the work that was performed, and that’s if the technical staff is still around at the time you’re claiming (which can be as far as 2 ½ years after some of the work was performed). Following the principles outlined above regarding the storage of good records ensures that even if a team member leaves, or memory fails, you’ll still be able to accurately claim your SR&ED.

If you want to take things a step further and save time when it comes to claim preparation, consider building an internal knowledge base or blog, that not just details the successes, but also explains failures, why they happened and why you learned from them. Plus, if you’re seeking a certain competitive edge, you can make the blog publicly accessible. Doing so will effectively prevent competitors from claiming SR&ED for the same advancement should their work be performed after yours.

Understand What Technological Uncertainty Really Means

One of the presenters noted that the most frequent reason they are seeing for audits resulting from technical reports is a lack of demonstrated uncertainty in the technical report. As a refresher, technological uncertainty sits at the core of every eligible R&D project. You must be able to demonstrate that due to limitations and shortcomings of the current state of the art (i.e. what is publicly available), it is uncertain as to if and how a desired result is achievable.

With that in mind, let’s use one of CRA’s examples. Here are three sample excerpts attempting to demonstrate uncertainty in a given project:

#1

There is uncertainty in whether we can achieve at least a 30% reduction in overall energy consumption of the Blockchain network by developing a new consensus mechanism. Existing mechanisms could not achieve our objective.

#2

There is uncertainty in whether we can successfully develop and integrate a new cryptocurrency into our existing Social Media Platform. To our knowledge no cryptocurrency was ever integrated into social media systems.

#3

There is uncertainty in the development of a consensus mechanism for Blockchain that reduces the energy consumption, as there is a tendency for these mechanisms to converge to centralized sets of miners resulting in an unfair distribution of mining.

Let’s take a deeper look at each of these to see why #3 is the best choice.

#1 focuses on the amount of reduction that they are seeking. During the presentation, the CRA stated that a specific target for improvement cannot be uncertainty within itself, although they do appreciate the inclusion of metrics within the report. Significantly, this doesn’t indicate any limitations or issues with existing technologies or approaches. This answer does not show why it is unclear as to if an energy reduction can be achieved, nor, by failing to show why, does it show that there would be difficulties involved in achieving it.

#2 focuses on a product challenge. From a technological perspective, the integration of cryptocurrency to reward users for making posts is a relatively straightforward problem—it involves working likely exclusively with existing tools and approaches and putting them together in a fashion that facilitates a product goal. This, therefore, does not present any technological uncertainties.

#3 on the other hand, is the best option. This sets out the limitations with the existing algorithms, and why there is a pattern that would make it uncertain as to if a different approach can be achieved. This also does not focus on product objectives, and therefore effectively sets out the technological uncertainties in the pursuit of the project.

Instill Best Practices Related to SR&ED Documentation

Consolidating modern agile methodologies with CRA’s reporting requirements has always been a challenge. Thankfully, you don’t have to adopt an onerous process to maximize your SR&ED claims year after year. Fundamentally, good management practices are enough to make a solid SR&ED process stick. Communicating the value or SR&ED to your development team, sharing the results of your claims, and consistently fine-tuning the process will help your team embrace SR&ED rather than resent it.

How R&D Partners Can Help

If you work in the ICT sector and have questions or comments about your SR&ED claim, please do not hesitate to contact Erik Partridge, Consultant at R&D Partners at 1-800-500-7733 for more information.