How to recognize routine work and standard practice

When claiming an SR & ED tax credit, it must be shown that we have done more than the standard practice. This demonstration is not obvious. We have already illustrated a way to identify and measure the technology gap. We will discuss again the method to make this demonstration in a next blog.

When preparing an SR & ED file, we describe the project and its activities. We strongly believe that this is a systematic process that satisfies all five questions. Everything remains there until the Canada Revenue Agency (CRA) Research and Technology Advisor (RTA) takes a look at your claim.

And then, IT IS OFTEN TOO LATE.

Do you like horror stories? Let me tell you about situations that all the least experienced SR & ED practitioners have encountered many times in their careers:

1- A horror story

A customer gets all his credit for all his claims for several years including an uncommented  audit or comment from the RTA.

A new RTA is assigned to your file this year and the entire claim is dismissed. Why? The new RTA responds “It’s routine development, you did not go beyond the standard practice. How could he get here? Several reasoning can lead to this conclusion. The RTA then proceeds with one of the following statements:

Experience

“You have been doing this kind of development for ten or twenty years. So you know these technologies. There are no more uncertainties.

Does this mean that if the company had been doing these developments only since, say, a year or two, then we would recognize the existence of uncertainties because this young company would not have built such a base of expertise and knowledge ? I have already heard a RTA answer “yes” to this question! …

Google

“We find this technology by a simple search in Google, so it is common practice in the field of technology. “

Nowadays many technologies are changing very quickly and there are many forums and sites of help and sharing to discuss problems and their solutions. If one applies this argument literally then there is almost no experimental research possible because the developers rarely invest in obscure and very risky searches without seeking / finding existing supports.

Troubleshooting

“The activities described do not go beyond the level of technological troubleshooting and are, therefore, routine activities”.

The goal of troubleshooting is to solve technical problems, optimize processes, or adjust equipment performance. It is not a question of advancing knowledge.

Domain completely defined

“Everything has been established in the field (mechanical engineering for example), laws, principles and standards are established. All that is possible today is to combine already defined knowledge to achieve predictable results. All work in this area is therefore common practice “!!!

That’s when we hear a jaw fall to the ground …

… And that begins a long and painful battle to overthrow this stupid decision.

2- How do you answer to this ?

Let’s say it right away. It will not be easy to convince a RTA (and his manager) to change their minds. Let’s explore some possible solutions together:

• The first step is often to convince the RTA to stop using a term as ambiguous as “routine” or “common”. Can he clarify where the relevant knowledge base comes from and what is in more detail?
• If he uses the argument based on the experience of the developers or the company, then it is a classic case of confusion between meeting someone competent and not seeing (understanding) the uncertainty seen in the eye of the expert. With experience the expert develops a better ability to grasp the essential elements of a problem. The presence of uncertainty is not necessarily accompanied by a lack of confidence to solve it as can be seen in the less experienced developers. Uncertainty arises at a higher level in the expert’s mind.
• Some TRCs accept the idea that changing the design approach of an experiment (or creating an alternative concept) indicates a challenge that is not obvious. In particular, the details of an essay may not be sufficient in itself, but it is the accumulation of several essays that can converge and germinate the idea of ​​a new and possible solution.

Exceeding the limits

• The key to answering the question of current practice is sometimes to recall the advancements sought. Uncertainty can be established and demonstrated if:
  • We can identify an unknown element that we had to discover through systematic experimentation, we can demonstrate that the research aims at overcoming the current limits of technology.

This is true unless, of course, there is not a defined sequence of steps that lead to the desired result for sure.

• Routine work includes development challenges that can sometimes be solved through general collaboration with other practitioners. For example, if developers encounter problems and they can solve them simply by exchanging online or with their colleagues. If this simple interaction leads to the resolution of the problem, it is routine. It is also routine if the developer is able to reproduce what he finds on the Internet and introduces it directly into his solution.
• This only becomes experimental if the developer feels that there is a risk associated with the solution, and whether he has had to improve or reinforce what he has found with a new approach. It is also experimental if one concludes that the work done is completely new and is not supported by what is found online.
• In any case, the existence of one or more documented evidence will be extremely useful in the debate.

Recommendation

Avoid any mention of troubleshooting (or “trouble-shooting” or “debugging”). Troubleshooting is a routine activity aimed at correcting equipment, software or processes. It is very often a fault detection activity without attempting to resolve the uncertainties in the underlying technology. This is not SR & ED. That said, troubleshooting can highlight the need for SR & ED. It is also possible that troubleshooting activities are required as part of eligible activities of an SR & ED project.

3- Conclusion:

So “standard practice” and “routine work” are two catch-all concepts commonly used by RTAs to cut into projects or activities.

The answer to these hollow words is to DEMAND the RTA to prove it. That he provides you with a detailed and documented definition of what is common practice or routine activities in the taxpayer’s technological field according to the RTA. What is the source of this statement?

Any answer to this argument must therefore go through the demonstration that the work done was to solve an uncertainty and in order to advance your knowledge of the technology.

On the other hand, it must be admitted that this kind of argument is difficult to win if we discuss with the one who is both judge and party. Moreover, it is easier to say that this is standard practice than to show the opposite, especially if this debate takes place one or two years after the facts.

Let’s conclude with this analogy: In the context of the current accelerated technological evolution, many developers are building new cakes flavors, but very few of them venture to create new types of pastries. According to the spirit of the law the “flavors” should qualify, but some interpretations tend to raise the bar at the level of “types”.

Thank you

We are honored by your visit to our blog. R&D Action thank you for this.

On the right of this page the index contains several other categories of practical and applicable solutions that are also intended for you.

Did you like your reading? Tell us so. Share it. What should be added? What topics are you interested in?

Did you dislike this reading? Tell us so. What did you like least about this text? How can we best meet your needs?