SR&ED – A Plain-Language Eligibility Quiz and Self-Assessment
Determining eligibility is one of the most difficult parts of the SR&ED process, especially when deciding which projects could be eligible for SR&ED and which would be considered to be ‘routine development’.
These questions are based on an older version of the Self-Assessment and Learning Tool, however, they provide a very basic understanding of eligibility for SR&ED.
SR&ED Self-Assessment
The SR&ED Self-Assessment and Learning Tool comprises two PDF documents.1 Each PDF is made up of a series of questions that determine the eligibility of projects, dependent on the answers provided by the user. The questions cover all the basic requirements of the SR&ED program, however, the questions use very specific terminology that a person new to SR&ED may find confusing.
In order to make the SR&ED self-assessment process more accessible, we’ve compiled a basic list of questions below. Depending on the split between ‘a’ and ‘b’ answers, you should be able to determine whether a project should be considered for an SR&ED claim.*
Plain Language SR&ED Eligibility Questions:
1. How do the desired capabilities compare to similar products and/or technologies that already existed at the onset of the project?
a) It is very similar to an open-source project, or we are integrating widely-used methods in straightforward combinations to produce a better product/service. Most of the knowledge is publicly available and relatively mature/proven.
b) All information related to this development/capability is either locked, in a proprietary format or is non-existent. Similar products may exist, but they are limited with respect to <Technology A>, which is absolutely essential in our desired application. The technology may be an active area of research in university institutions and has never been proven to work in the situation that we were planning.
2. Did you employ experienced engineers/technologists to perform the research and development?
a) Not really. All of our employees are recent graduates or have limited experience in the area that we were researching. We needed to spend a lot of time during the year training and learning about the new technology before we could begin to develop extensions of the technology and apply it to our business practices. (Remember: Time spent training/learning is not eligible for SR&ED). Some of our research employees have non-technical educational degrees (e.g., B.A., B.Comm. etc.), and have limited on-the-job training with our technology.
b) Yes. Our staff consists entirely of very experienced personnel who have an in-depth understanding of the technology of interest. In addition, any less experienced personnel are closely supervised by a technical manager who has considerable experience and offers guidance/advice on a regular basis. All employees have a technical background, from an educational/theoretical view and from work experience.
3. Did you anticipate that ‘routine procedures’, if followed for the entire duration of the project, would be sufficient to resolve the problem?
Note: The CRA considers ‘routine development’ to consist of generally-accepted practices and procedures, which experienced scientists/technicians (e.g. over 3 years of experience in the industry) would follow when solving a problem.
a) Yes, the standard practice would be sufficient to resolve all issues related to the product.
b) No, standard practice would not be sufficient. We were researching areas/technologies that are not usually integrated with the technology we normally work with, or it was clear that following routine steps would not allow us to solve the technological puzzle. We would require developing a new workflow/method in order to have a chance of solving the challenges. Our project involved tasks that even very experienced engineers (over 10 years) would find challenging.
4. What was preventing you from developing this new capability?
a) Only time/effort was required to develop the technology. All of the obstacles were routine in nature, and would only require bug-fixing and routine optimization to result in our final objective. The workflow timeline was straight and easy to see; there was little doubt that we would be able to solve the problem. Alternatively, every anticipated problem could be solved using a ‘technical’ solution, as opposed to technological – e.g. a slow server response could be solved by replacing the architecture with new hardware/firmware.
b) There were significant technological obstacles that we would need to overcome to realize our objectives. Each obstacle had very limited documentation associated with it, or it had never been researched in this approach before. As such, we did not know how exactly we were going to overcome each obstacle, and there were many branching decision points which were dependent on the results of our discoveries during the year. Routine development and bug fixing would not be sufficient to solve the problem; new/unique/unusual intermediate methods would likely be required in order to resolve each of these obstacles.
5. Did you develop a project plan and sketch out a schedule for how you initially anticipated the project would be conducted?
a) No, we did not plan things out very well. We had our initial knowledge and an end goal, but we had no idea how to get there. As such, we tried random technologies and trial and error techniques to see if we were getting closer or not. We performed limited systematic investigation and rarely formulated hypotheses related to the work.
b) Yes, we developed an initial project plan, with an approximate route mapped out for the investigation. Every time we gained new information, we evaluated the road map and adjusted to adapt to the new knowledge. When alternatives existed for each method, we conducted thorough evaluations and testing to determine which approach would best fit our requirements. We documented all of these decisions, and impacted the following steps. Periodically throughout the process, we formulated hypotheses with respect to how a given experiment/test would resolve.
6. What documentation was kept during the process?
a) We kept very limited documentation. Notes were frequently passed on scraps of paper and were subsequently shredded. Meeting notes were made on whiteboards, but were quickly erased with only a few notes saved. E-mails between developers exist, but were mainly used for scheduling purposes, and have limited technical detail. No documentation of the initial search for similar products/technology exists. We paid all employees a flat salary, and did not keep records for how each employee split their time between development and marketing/sales activities.
b) Considerable contemporaneous documentation exists. All developers maintained an up-to-date task list on a service such as GitHub, Zoho, Basecamp, etc. Major development tasks were recorded in these systems, and lab books/notebooks for each developer may exist. All test data and simulation results are saved in one central location or are otherwise accessible. Evidence showing that, at the onset of the project, no similar technology or product existed is available; this evidence could include saved Google searches, screenshots of competing products, saved third-party developer discussions and others. Detailed timesheets are available which clearly show how much time each employee spent on R&D activities.
7. At the end of the reporting period, had you measurably increased your company’s knowledge base?
a) Not measurably. We spent the majority of the period training/learning new development, or performing maintenance/upkeep on the existing systems we had in place. We gained very limited new knowledge, and what we did gain was through standard evolutionary process improvements as opposed to the development of a new technology.
b) Yes, the activities performed during the period increased our technical knowledge base. We did not necessarily meet all of our objectives (or even any of our objectives), but our systematic processes allowed us to gain new knowledge about our industry and related technology. A null-result is still a net knowledge gain. We may or may not have increased society’s knowledge base (this is not a requirement for SR&ED), but we gained knowledge within the constraints of our business.
7 Questions. How did you do?
Add up the number of times you answered b) to get an idea of whether your project is eligible:
7/7 – You’ve made some great advancements! Your work is most likely eligible for SR&ED.
6/7 – Take a look at the question to which your answer was a). See what you can do to change your answer to b) in order to increase eligibility.
5/7 – Your project may be eligible for SR&ED.
4/7 – Your project is high risk for SR&ED and may not be eligible.
3/7 – Have you been focusing more on business development this year? Your project is probably not eligible for SR&ED.
2/7 – You’re chances are slim. Think about other projects that may be eligible.
1/7 – Maybe next year? Time to get your company setup for future SR&ED claims.
0/7 – Better luck next time, you’re not eligible for SR&ED.
Conclusion
This information and SR&ED self-assessment is offered as a guide. Only the CRA can definitively define eligibility and accept SR&ED projects. Once you’ve met the initial requirements highlighted in this quiz, you must continue to refine your internal processes to justify your SR&ED costs to the CRA.