If you’ve written more than one SR&ED submission in your time and survived a review, you will likely have an idea of what the CRA is looking for in Part 2; however, a good writer is always looking for ways to improve their writing.

In this section, we cover advanced topics in writing for SR&ED, including nuanced phrasing, speed writing, and templates.

Table of Contents

How to navigate: Click on the name of a section or subsection to go directly to that area of the page.

SR&ED Anti-Glossary – Red Flag Words

The key to successful writing for SR&ED is to use accurate language that succinctly and accurately describes your project, but does not understate the effort of your work.

A common error is writing as though the report is intended to be read by management – this style is incorrect. Instead, write the report as an academic-style research project. Ask yourself the following: “does this sound commercial?” or “have I focused on features, instead of technology?” If the answer is yes, it’s important to begin rewriting your submission.

Often, we are too close to the material to review it objectively – we suggest that you have someone in-house read through your technical narrative (using this checklist of red flag words) before you submit. While it’s no substitute for having a review done by a professional SR&ED consultant, it will help reduce your risk.

Remember, misunderstandings in this area can cost companies thousands of dollars worth of lost time and tax credits. Remember to put appropriate time and effort into preparing these documents; the CRA wants to support R&D in Canada, so make it easy for them to say “YES!”

When possible, amend or remove references to the following words/phrases from your project titles and technical narrative:

Words to Avoid

Application/Apply – “Applying” a principle suggests that it is already an established principle and that the CRA considers this principle standard practice. If a solution is simply “applied,” the phrasing implies that the work was routine and that there was little/no uncertainty involved in producing the solution. We suggest you replace this word with synonyms such as “development” or “experimented with,” which both indicate that considerable work was required to realize the solution.

Beta Version – As soon as something reaches beta, it has gone into commercialization and no technological uncertainties remain. Ensure this is what you mean to say.

Company – Do not place “company” or other business objectives first.

Considered – The word “considered” is often seen as too cursory and related to “trial and error”. Look at replacing “considered” with investigated. For example, “We considered options X, Y and Z.” vs. “We investigated and researched X, Y and Z.” Investigated is a much more active word, and usually, better describes the necessary activities in SR&ED projects.

Did Not Know – The phrase “did not know” is usually too colloquial for high-quality SR&ED narratives. Contrast “we did not know”, with a phrase like “it was uncertain whether” The second phrase better aligns with the terminology expected of the SR&ED program, as it is related to scientific uncertainty and technological advancement.

Feature – The use of a word like “feature” implies a level of commercialization that should not be present in most SR&ED projects. The focus of SR&ED narratives should be on the technology, which supports and enables any “features” that a given product might have. Use “technological advancement” or “technological goal” instead of “product feature.”

Fine-tuned – “Fine-tuned” is a very colloquial word that should not exist in an SR&ED narrative. Words like “fine-tuned” and “tweaking” imply tiny changes to the software or code that don’t have any technological uncertainty associated with the modification. Often, these changes will occur after the actual SR&ED work is completed. Including these words will raise a red flag at the CRA, and questions may be asked about just how much engineering time is being claimed for the project. “Incremental improvements” are eligible activities, but they need to be carefully associated with related uncertainties and clear advancements in knowledge.

Found/Discovered – The word “found” belongs in a category of words that suggest that the related work was straightforward or easy. For example: “We found that solution X worked the best.” The phrasing of this sentence implies that only routine development work was required to find the solution, such as a simple Google search and plugging in the answer. This is not SR&ED-eligible work, as no uncertainty exists within this search, and no new knowledge is being gained. “Developed” is usually a more accurate (and active) word to use, and helps to show that the solution was not self-evident.

Goal – You can indicate the overall goal at the start of s.240; after that, it should refer to the “technological advancements.” Goals can be interpreted as business related, whereas “advancements” fit within the CRA paradigm of SR&ED.

GUI/UI– GUI work or UI work is considered support work – at best. Demonstrate the relevance to the overall project or remove from the narrative.

In-House – Jargon to avoid. Use “proprietary.”

Market Research – Activities described as “market research” are not typically eligible for SR&ED, and you should avoid references to these activities or business decisions at all costs during the narrative. If the activities are essential to the development, consider whether the phrase “establishing the required project parameters” is more appropriate.

Migration – Using “migration” implies that the work performed was a simple conversion process as opposed to innovative development. Unless there was a significant technical obstacle that was overcome and clearly described in the SR&ED application write-up, migration projects will be seen as standard practice. Remember as well that a systematic process to convert or update old code to new environments could be considered SR&ED-eligible. In this case, it would be the process or procedure that you could claim, and there is a lower emphasis on a single one-off migration.

Problem/ Issue – Not all problems or issues are technological uncertainties.

Product – Avoid using “product,” as this word has commercial connotations that present the SR&ED work as a commercial or finished product. SR&ED work generally ends once something is being sold; it’s important to use language carefully if you are past the pre-commercialization and research phase. Instead of “product,” discuss the “technology” or “technological capability” of the design process. If necessary, you can use “prototype” to designate a beta-stage development, but it will be absolutely essential to show that technological uncertainties or obstacles still remain with any described prototypes. In most circumstances, SR&ED projects end as soon as you overcome these obstacles.

Prototype – Sometimes this term is misconstrued as the SR&ED work being complete and only QA now occurring. If you choose to use this term, ensure that you are aware that additional emphasis must be placed on the continued uncertainties.

Simple – This term implies that the work was routine. Focus on the uncertainties/alternatives available at every point in the decision process, if they exist. If simple or straightforward steps were part of the process, ensure that these tasks are directly linked to other required tasks that have concrete uncertainties. This allows you to claim supporting work as necessary to the progression of the project.

Straightforward – As above, see “simple”.

Testing – This term is acceptable so long as it is clear that analysis is performed after the testing has been completed. Otherwise, it can be misconstrued as Trial and Error.

Trial and Error / Tried – Even though engineers often use this phrase to mean sophisticated experimentation, you should not use it in an SR&ED application. The CRA tends to think this phrase implies unstructured guesswork, which falls outside the realm of SR&ED (it is not “systematic investigation”). Re-examine the activities and see if it is possible to show the systematic approach to your investigations. Demonstrate that each step is related to the next in a logically consistent fashion.

Under/Over – When discussing numbers, use “more than” or “less than” instead of over/under. Quantifiable, measurable objectives are preferred.

Users/Clients – Any references to users should be minimized as much as possible, as anything related to the user-level or presentation layer is usually not eligible for SR&ED. Instead, focus on the underlying architecture and technology that allow the presentation layer to be rendered/displayed or that enable the user to interact with the developed product. Refer to “accounts” or “log-ins” if absolutely necessary, but avoid referencing the high-level presentation layers that may exist in the software. You may also use “external and internal users” or even “individuals.”

User Feedback – Ineligible; it is seen as marketing.

Other Points for Consideration

• Be concise. “With no user input required” vs. “without user input.”
• This – “This was especially hard” What is “this”? Specify in all circumstances.
• Non-quantifiable terms – Using terms such as “bigger,” “better,” “more efficient,” and such are not specific enough for SR&ED applications. Similarly, something that “just works” is too vague. When describing the SR&ED work, always remember to reference quantitative numbers. For example, “We required that the new system respond 10% faster than the older system which was benchmarked at 100 ms.” Phrases such as “It was not evident that ….” and “It was extraordinarily difficult to…” raise the question, “Why?” Why was it not obvious? Why was it difficult? What resources did you use to determine it was not evident? Your statements need to establish why something became a technological obstacle requiring a desired technological objective and experimental development.
• Avoid absolute statements such as, “Other companies had failed to develop a solution.” Are you 100% sure? And does it matter? Remove the reference to other companies and you’re in the clear—after all, if they had developed it, it was probably proprietary.
• Avoid flowery English such as “on the order of.”
• Avoid the temptation to include background information in s.242; state the technological obstacle first, explain why it is an obstacle second.
• In s.242, put the most challenging obstacle first. If you list it as “serious,” put it first.
• Be specific — “many different tests” vs. “we ran 73 tests with 9 variables.”
• Be sure to use “e.g.” and “i.e.” correctly, as they are not the same. “E.g.” means “for example” (you’re about to list examples) while “i.e.” means “in other words” (you’re about to rephrase what you just said).
• Watch for hanging sentences. Ex. “and still required large amounts of labour to process” vs. “considerable manual intervention was still required to process documents”; “to process” prompts the question “process what?”).

 Warning: Be careful not to play “buzzword bingo” (i.e., using CRA keywords repeatedly but incorrectly). Shorthand is useful but no substitute for correctly structured SR&ED projects. When in doubt, seek professional guidance.