Critical SR&ED Mistakes: Product Names
Reference Article (>5 Years Old)
Using product names in an SR&ED technical narrative is a common mistake when writing SR&ED claims.
When preparing an SR&ED claim for a project that has taken a substantial amount of time, it is often natural to try to “sell” it to the Canada Revenue Agency by focusing on its features and why it is a great commercial product. However, the Eligibility of Work for SR&ED Investment Tax Credits Policy states that “ʽ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 […] but does not include work with respect to […] the commercial production of a new or improved material, device or product or the commercial use of a new or improved process.” If you try to sell your product or the third-party product used in the development of your project in your SR&ED technical narrative, it may make it ineligible.
This problem often manifests itself in the confusion between a company project and an SR&ED project, and in the inclusion of product names in the SR&ED technical narrative, which we discuss below.
Using Product Names in an SR&ED Technical Narrative
One key mistake that many first-time writers make is focusing too intently on brand and product names when describing the work performed over the reporting period. Â This issue is easy to resolve; writers should focus on the capabilities of a product used and why it was necessary in their experimental development.
As an example, a software company could have used a third-party application programming interface (API) tool to create a plugin for a piece of software. In this case, it is not the API name that should be mentioned, it is the specific capabilities of the API and why it was used in the development of the SR&ED project. Discuss specific features that were needed from ‘an existing API tool’, and why your company chose this tool over others.
Talking about specific advantages and disadvantages should be encouraged, but in almost all cases, the full product suite that you used isn’t relevant. Focus instead, for instance, on a specific feature that was needed.
Product Names Distract
There are several reasons for this approach, all geared towards trying to keep the reviewer interested for as long as possible. Every sentence and idea in the document should flow naturally from one to another. Anything that distracts from the reviewer’s attention on your technical narrative (e.g. spelling mistakes, grammatical issues or an out-of-place idea) should be avoided whenever possible.
Every reviewer at the CRA will have, at minimum, a general understanding of the technology being written about, and they will have likely seen hundreds of related claims each year. This exposure to a lot of technical narratives means the reviewer may have developed preconceptions and opinions on what particular programs/products are capable of doing. However, their understanding of the program might be limited to a single claim. Mentioning a specific product name shifts the attention from your specific project to their recollection of a similar product, which can impact their understanding of your overall project. The CRA reviewer may also not have realized that a particular program was capable of the capabilities that you list, which may make them doubt your claim.
Features > Product Names
Write about a generic program with specific features and the reviewer can accept that such a program exists, and then move on. If your claim is then filed for specialist review, this is the time to offer specific and detailed examples of the third-party product used. In the original T661 document, mention only the features of the program, not the program itself.
It is essential that the technical features you discuss in the technical narrative are well explained. If multiple approaches were required, with different programs/equipment being used in each, you must clearly differentiate between the feature sets of the various alternatives.
As an example:
We began experimentation with a third-party product that had capability A, however, upon analysis of the results of our experiments we found that it interfered with feature B. As a result, we sought an alternative third-party solution that combined capabilities A and B, and allowed integration with capability C. We encountered the following difficulties while implementing C…
Conclusion
It is important that the CRA know why you used a product in your development, not what that product was (though ensure you maintain thorough contemporaneous documentation on this in the event that your claim undergoes an SR&ED review). When writing the technical narrative for an SR&ED claim ensure that the uncertainties and, ultimately, the technical or scientific advancements or knowledge that were gained in your SR&ED project are the most prominent aspects, not product names.