Document your SR&ED now

To claim tax credits for an SR&ED project, the Canada Revenue Agency (CRA) now requires contemporaneous documentation of the activities claimed. Document your SR&ED, how do we do that?

Document HOW?

It requires a new business discipline, a new system to document regularly because nobody will remember in detail what happened 12 or 18 months ago. When you start a new development project, immediately think about documenting it. How will you measure the work done? You will then find ways to incorporate these measures into your way of doing things. For example :

• Mark these activities in your project or time sheet management software
• Save the information in a separate directory for SR&ED
• Save important emails in PDF format
• Create a red folder marked R&D on your desktop where you discard your dated handwritten notes, hard copies of websites, blogs and other sites visited to understand and evaluate the technology, tools, alternatives, etc.
• Prepare birth certificates and prepare tracking documents to show the progress of your projects that can be claimed as SR&ED
• Initiate a logbook to record the progress of each project
• Follow the expenses
• Use simple communication tools and collaborative documentation, such as a Wiki, or voice recordings to build your virtual “collage”, on the network or even on the Web, and to:
• Centralize the supporting information
• Begin preliminary drafting of your technical projects.
• Motivate some of your resources with the electronic format, often more effective.

Document WHAT?

Review the information gathered at least two or three times during the year, to ensure the information is complete, dated, and related to key project events.

Concepts

Document initial concept discussions and initial documents explaining the requirements – why you felt the need to experiment with technical improvements in the first place. Photos, videos, prototypes or wrong codes can be worth gold to demonstrate significant changes and improvements to the experimental design. If you can demonstrate high-level needs, you will typically find that most companies generate a lot of detailed documentation – the trick is to trace the evidence of “unnecessary results of detailed failure” before they are thrown away.

Issues

Likewise, high-level issues are often the most difficult to document – the issue is often located between a learning attempt or a trial-and-error focus. Talk to your designers and analysts, have them describe their conceptual approach and the corresponding dates when they were always considered.

Typically, when something is missing, send an e-mail asking for a summary confirmation (eg a bulleted list rather than a text) of the conceptual alternatives considered in the early stages of development. Similarly, you can record an interview where you will be told the details of complex situations or concepts. Quantified technical specifications of specific targets that were known or unknown are important for defining and demonstrating technological issues.

Learning appears in the complexity of the details told by the people who did the work – managers are often too far away from the problems and they over-simplify the difficulties sometimes, for example to facilitate discussion. This can make the claim very difficult to defend. Go to the source, talk to those who did the detailed work, find out what their options were and what they were looking for. Build a global and close vision at a time. Too generic quotes lack credibility. Get specific, quantified or qualified conclusions.

Thoughts

Document your thought processes before experimentation. This is critical because if the problem can not be defined before the experiment, then the cost could be denied. Your need to experiment may be due to lack of time or resources. The experimental approach is perhaps the best method for the situation, although not the only one. However, be sure to draw sound conclusions after the experiment. For example, if you will not redo this design or experimentation, it may be a very significant lesson. Emphasis on the evolution of the design of the experiment can be exceptionally powerful.

Objectives

Relate to your objectives.

Similarly, if you can not show a change in your approach or direction, you may be in the process of developing a known technique. So be sure to keep the relationships to the original purpose in the documentation. “Tuning” may be a necessary step rather than actual “learning” for the future. Thus, presenting the evolution of the design of the experiment is often a critical and essential perspective for some start-up situations.

And how do you document your SR&ED projects? Do you have any tips to share? How do you make sure the right information is kept throughout the year?

How do you document during the course of your SR&ED projects? Do you have any tips? ways of doing things or ideas to share about it? How did the CRA respond to your documentation mechanisms?

R&D Action thanks you for visiting our blog on tax credits.

R&D Action is the choice of experience and expertise in tax credits.

Several other categories of practical and applicable solutions are available to the right of this page, in the index.

Try them. They are for you.

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

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

Read More

SR & ED Technical Documentation: Reconciling Reality and Hypotheses

In a technical audit, sufficient evidence can make all the difference between the success and failure of a claim.

CRA Research and Technology Advisors (RTAs) expect you to manage your SR & ED projects in parallel with your client projects. Consequently, the requirement is to keep contemporary, dated, signed and specific records of the SR & ED work carried out.

In practice, very few development managers go beyond documenting the activities leading to the delivery of a technology solution to their client. During a technical audit, some RTAs use the repeated mention of the name of clients in the documents provided to consider that it is not evidence of SR & ED experimentation but rather the normal delivery of a project. customer.

How to reconcile the reality of development work with the requirements of the CRA? Here we distinguish two types of justification: the development project, often carried out in part for a client, and the experimental SR & ED project, especially carried out in the minds of the designers of the technology.

1- Justification of development work

In Appendix 2 of T4088, the CRA identifies in a table “Examples of Evidence Supporting SR & ED”:

• Project planning documents
• Resource Allocation Records, Timesheets
• Experimental plans
• Design documents, computer-aided design (CAD) and technical drawings
• Project records, laboratory notebooks
• Design, system architecture and source code (software development)
• Test registers
• Project progress reports
• Project meeting reports
• Test protocols, test data, test results
• Analysis of test results, conclusions
• Final project report or professional publications
• Photographs and videos
• Prototypes, samples
• Destroyed materials, material disposal records
• Contracts and invoices

All these documents are typical of a conventional development project. The problem is that they are normally produced as part of a client project. Nothing links this work to the objectives, uncertainties and technological advancements requested in Form T661. So what is missing to prove the experimental work?

2- Justification of the experimental work: document the SR & ED hypotheses

Oddly none of the documents listed above and in Table 1 of Annex 2 of Guide T4088, is related to the column: “Work done: experimentation, analysis, support work, progress ” which corresponds to the line 244 of Form T-661. Why ?

The answer is the record of the hypotheses that is defined in the description of the fifth question to determine if work meets the definition of SR&ED :

“[The CRA] expects the work to be recorded in a way that clearly indicates the purpose of their key elements and how they fit into the overall project. The indicators or measures that will be used to determine if the project objectives are being achieved should be identified and documented at the beginning of the work. (Eligibility policy 2.1.5)

Therefore, the CRA expects us to have both development project tracking information and monitoring information from the claimed experimental process.

Two important remarks remain despite this definition:

2.1 It is necessary to document the acquisition of knowledge

The record of the hypotheses is the only place where the acquisition of knowledge can be linked to activities, uncertainties and technological advancements. It is therefore a key document to support your technical claim.

Note: the quality prevails on the quantity. What we demonstrate here is the acquisition of knowledge rather than the generation of a mass of more or less relevant information.

2.2 Hypothesis = choice

Nobody uses the word hypothesis in daily exchanges between members of the development team. However, the CRA requires “a record of verified assumptions and results retained during the course of the work”.

First, in a real project of technological development, the issue of hypotheses to resolve uncertainty is an exercise that happens between the two ears of those who conduct the work. It is therefore necessary to explain, verbalize and write the hypotheses raised, even if they were rejected even before formally testing them.

In addition, the word “hypothesis” is certainly far from the reality of engineers and solution designers. It would be clearer to use the term “option” or “choice”.

Basically, what the CRA is looking for is a record of the uncertainties encountered, the choices considered, the tests carried out, the results obtained, as well as the knowledge that we drew from them.

3- Conclusion

In conclusion, let us remember that for the CRA, we claim a systematic experimental process, where the progress of the work is done by an analysis of the results step by step. In this context, to use the results of the tests, we must record, write, note, the experimental work and analysis that will one day lead us to solve the technological uncertainties and to better understand the scientific or technological relations (also called scientific or technological advancement).

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

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?

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

Read More

No to the SR & ED documentation software

In more than 25 years in the business I have never seen a SR & ED documentation software  that bore it’s name. Several competitors have proposed or are still offering software to document the activities and especially the costs of SR & ED. This is, of course, an attractive concept as it could meet the requirements of the CRA’s Research and Technology Advisors (RTAs). But that does not work. It will never work and here is why.

Selling dreams – or fake security

Of course, the software designers worked very hard to develop it. They inserted a lot of good ideas in there. They deserve our support. Oh yeah ? I have NEVER seen such software still fully operational after more than a single year at a client. Never. And to those who answer me that their implantation is older than that I answer, Oh yeah? What functions are still using? The costs accumulation ? What is the driving force behind this implementation? The software itself or the effort that the consultant injects every month or quarter? Is this software installed for ALL your teams of developers? You reduced the year-end writing effort by how much? 10%?

Garbage in – garbage out

The SR & ED documentation software vendors all have pretty much the same arguments:

• It’s automatic
• It reduces writing efforts at the end of the year
• It forces discipline
• It will be more acceptable to CRTs

These are good selling points, but the reality is quite different:

• Garbage in – garbage out: after a few weeks of use without the presence of the consultant who sold the software, we find:
  • a tendency to limit documentation efforts.
  • more and more copy-and-paste from one week to the next.
  • little or no update of the experimental project structure.
  • multiplication of dangerous words (trial and error, debugging, client documentation, etc.) or meaningless catchy phrases to document the research.
• Too much is like not enough. I still remember a customer who came to an audit meeting with at least 60 cm of paper printed from his software. It was full of repetitions, meaningless sentences … and the CRT refused to even take a look! Useless!

What is essential is the tight follow-up to get the quality information, not the price of the software.

• Follow-up, Follow-up, Follow-up.

  Despite all the goodwill of the management, the consultant and even the main users, the human nature quickly takes over if there is not a very close monitoring by the consultant. The monitoring must cover not only the existence of new documentation, but also, and above all, the relevance of the preserved traces. Without tight follow-up, the validity declines after a few weeks, three or four months at most. And we will not realize this until the end of the year, when trying to write the description.

• Some believe they are buying the solution to their problem.

  Software, however extraordinary, is NEVER the solution. It is only a tool. The solution is to closely monitor the data entered each week. Otherwise you accumulate waste and you throw away valuable time of your developers.

• Flexibility when faced with the unknown

The problem with documentation software is that these tools require pre-defining technological objectives, advancements (AT) and uncertainties (IT). How do you pre-define these if it is really an experimental development project? We can not know in advance where we will encounter problems, how many and what assumptions will be tested and demonstrated, what new avenues we will explore. The flexibility of the software is therefore an important issue. It is easy to create an initial template that structures an advancement, which relates to 1 to n uncertainties and for each uncertainty there are 1 to m assumptions, etc. But an experimental project does not always move linearly in a tree structure. The structure of these programs is often too cumbersome or complex to simply add new avenues explored. Even when a software expert creates new branches in the experimental process users will not do it, they will write anything, anywhere and the information collected will soon become unusable.

Buying software to document SR & ED solves no problem

A simple solution that works

Instead of buying useless technology, buy a good lab book, a project book, call it what you want. A simple notebook allows all insertions, references and notes that you want and it does not cost $ 10. When coupled with a “R&D folder”, you can add a copy of the project plans and follow-up reports – with your manual notations …

You want technology anyway ? Word and Excel are not enough for you? Implement a Wiki. This category of information sharing tool can evolve easily.

For some clients, we have purchased letter-size agendas specifying that they must stay on the desk, that they can be used for their personal needs, but most importantly, to record for each day (with dates) what they are working on and how much many hours they have devoted to it. Often a sentence is enough to recall the whole context. And the R & D / Non R & D breakdown will be easy to duplicate in the timesheet. You can add the names and links to supporting documents or test results that have been produced. At the end of the year you pick up these diaries. You take them out with the Word or Excel documents when you want to write the descriptions or when preparing for an audit.

Of course, close monitoring is essential for quality information, but at least you will not have to justify the $ 5,000. for a useless, heavy software.

Let me be clear. I have been involved in technology for 40 years. I believe in technology. But I have never seen a technology that self documents SR & ED. A technology flexible enough to adapt to several contexts.

Conclusion: Praise for the simple project book

Consequently, the right approach is simplicity. Documenting without software gives you flexibility and quality. It’s a question of will, organization and follow-up, not computer code. From there, it becomes a matter of building the habit of documenting often.

Ask your consultant to follow your team, to structure your documentation. Apart from you, he is the one who is really very interested in maximizing your credits. The result, when written by the hand of your experts will be 100 times more convincing for the CRT, and he will see, as a bonus, diagrams (by hand), test results, etc. In short, he will see proof that you manage your SR & ED project as a systematic research project.

We are honored by your visit to our blog.

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

Serve yourself.

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

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

Read More

How do you prove SR & ED? (2/2)

Contemporary documentation of SR & ED projects is the new credo of the RTAs. There must be documentary evidence that our research has taken place or there is no eligible SR & ED. Verbal testimonials are no longer enough. But how do we do that?

On the day your SR & ED is audited, you will be asked to answer each of the five questions defined in recent years by the CRA to determine eligibility for SR & ED. In a recent article we proposed to group your evidences according to these five questions.

Today, here are the evidence for the last three questions.

3- Evidence of a systematic investigation

A systematic investigation is a structured approach that involves moving from the identification of scientific or technological uncertainties to the issuance of hypotheses to resolve them, testing through experimentation or analysis, and the formulation of logical conclusions.

In a business context, this implies that:

• The SR & ED objectives are clearly established and written early in the project,
• The methods and experiments attempted to solve the uncertainties are specified,
• The work is supervised by personnel with appropriate technical competence.

Examples

To demonstrate a systematic process it is necessary to:

• Demonstrate systematic experimentation while supporting the costs:
• How many experiments and alternatives have been studied to try to solve each uncertainty,
• Demonstrate the working method:
• Analyzes (which, why, how many alternatives analyzed or simulated (theoretical), etc.)
• Testing process (what test environment, what changes from one test to another, how many process runs, conclusions, etc.),
• Keep evidence and inconclusive test results,
• Prototypes (how many prototypes (physical or simulated), why and what is the cause of their rejection),
• Take pictures of the physical prototypes before destroying them.
• Results of performance analyzes (over time and following the evolution of the process),
• Conclusions: compare results to expectations and explain variations,
• For which uncertainties do you think you can draw a conclusion (thus identifying a technological advance)?
• List in chronological order the key events, activities, tests and results relevant to the resolution of uncertainties,
• Keep copy of the results and the conclusions drawn at the time,
• Prepare and maintain minutes of your technical follow-up meetings including dates and participants,
• Document any new direction taken following the tests (iterations),
• Keep versions of project plans, budgets, resource utilization plans, test plans, and accompanying explanations,
• Note the support activities. The use of well-established technologies that are recognized as “routine” is not eligible unless the activity is carried out in support of an experimental development project. It can then become eligible. Do not neglect the tests which would seem to you ineligible at the outset,
• Keep all other relevant technical documents.

4- Proof of advancement

Advancement is defined by the CRA as the eligibility policy: “the generation of information or the discovery of knowledge that advances our understanding of scientific relations or technology. (…) Technological advancement shifts the scientific or technological knowledge base of a society to a higher level by increasing the understanding of technology. ”

http://www.cra-arc.gc.ca/txcrdt/sred-rsde/clmng/lgbltywrkfrsrdnvstmnttxcrdts-eng.html#s2_1_4

Examples

We have already illustrated the documentation of current practice and the technological gap. It is necessary to :

• Define the initial knowledge base,
• Specify the deviation sought in relation to the existing technology,
• Keep negative opinions on the feasibility of our technological approach by external experts or technology providers,
• Document the « rejection of a hypothesis, which is an advancement because it eliminates a possible solution»,
• Refer to a scientific or industry journal defining the state of technology capabilities at certain times,
• Record the results (even negative ones),
• Note the knowledge that we would be proud to show to our colleagues. What would be their opinion about the achieved/sought-after progress of knowledge?
• Periodically document your vision on topics such as:
• Is the new knowledge or technology generalizable? Where?
• Can this knowledge be applied elsewhere than in this specific situation?
• For what technological reason has advancement not been sought or obtained before?
• What would you do differently if the project started today?
• Compare your results/technologies to previous or competing products.

5- Register of assumptions and results

“A record of assumptions, tests and results should be kept in the course of the work. (…) the work must be documented so as to clearly state the rationale for their main elements and how they fit into the overall project. (…) A systematic investigation or search can generally not be conducted without recording work as it progresses. It is not intended to suggest a particular format of documentation to support SR & ED. ”

Appendix 2 of the T4088 – Guide for Form T661 contains some examples of evidence suggested by the CRA. But he does not give an example of a register of hypotheses. Here are a few practical suggestions:

Examples

For each SR & ED project, documentation must be produced while the activities are being carried out to ensure the consistency and integrity of the content. The following table should be revised and updated two to four times a year:

• Identify the project (name, numbers in management systems and timesheets, etc.),
• Identify the manager,
• Prepare a table of technological content specifying, for each uncertainty and for each hypothesis:
  • Start/end of activities,
  • Technological uncertainty and associated common practice,
  • Assumptions formulated to resolve uncertainties,
  • Results obtained for each hypothesis,
  • Technological advances targeted and obtained, knowledge generated by this work,
  • Resources and efforts (hours) used, including consultants.

Conclusion

This complements our documentation examples to support your SR & ED claims. The new RTAs now require such contemporary documentation of SR & ED projects. It has become a condition of acceptance. It is therefore necessary for you to organize to produce it, to enrich it and to preserve these traces of your projects during the year in order to reduce the risks of an unfortunate decision by these RTAs.

How do you document your SR & ED projects? Do you have any tricks or pitfalls to share? Which of your documentation practices have convinced the CRT?

We are honored to see the time spent reading our page. Our blog index (to the right of this page) contains several other solutions that are also intended for you.

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

Read More

How do you prove SR & ED? (1/2)

Contemporary documentation of SR & ED projects is the most recent hype for the RTA. You have to prove by documentary evidence that your research has taken place. Otherwise  there is no eligible SR&ED. Verbal testimonials are no longer enough. How do we do that?

In recent articles we have presented some ways to document your SR & ED projects. We have presented an inexpensive process, we have illustrated how to organize to document and how to document the deviation from current practice.

Here is another approach to gather your evidence for SR & ED. In recent years, the CRA has identified five questions to determine eligibility for SR & ED. We must now be ready, in audit, to answer each of these questions and to demonstrate our arguments. So here we propose to group your evidences according to these five questions.

Today we present the evidence for the first two questions. We will conclude with the evidence of the last three questions in a future blog

Before you start

Some warnings are needed before starting:

• Contrary to the CRA’s assertions, documentation of experimental processes is not “natural” in a commercial venture.
• Documenting your SR & ED projects is a new discipline to be implemented on a weekly or monthly basis in your company.
• Appointing a Technical Documentation Manager for each requested project is now a must.
• Paper is not the only acceptable support. A Word, Excel, Visio, Txt file, an e-mail, a picture or a Wiki will do the trick, the important thing is that it is dated,
• Be creative. Here we present a reminder, a source of inspiration from which you will build your bank of evidence, do not limit yourself to this list.
• Date all your documents.
• Finally, there is a great deal of overlap between the evidences presented here for each question, since we are talking about the same project in terms of uncertainties, experiments and advances and so on.

So let’s go for examples of documentary evidence for the first two questions:

1- Proof of uncertainty:

An uncertainty exists “if whether a given result or objective can be achieved or how to achieve it, is not known or determined on the basis of generally available scientific or technological knowledge or experience “

We have already discussed how to document current practice and how to overcome the knowledge base. Other examples of uncertainty documentation include:

Examples

Uncertainties are rarely described formally by the project staff. It is therefore necessary to create the habit of referring to them during the course of the project.

• From the beginning of the project, prepare a list (in the project’s birth certificate, which we will soon be discussing) stating the:
  • Main risks that the technological objective is not achieved within the technological constraints,
  • Anticipated problems and standard solutions for each,
  • Initial needs for testing of technologies, develop prototype (s)
  • Technical limits and known alternatives, in order to compare them later with the reality of the project.
• Write and update dated lists about:
  • Attempts (by others or by you) to resolve the problem raised,
  • Conceptual alternatives envisaged to solve the uncertainties,
  • Tests or serious analyzes to evaluate alternatives,
  • Constraints, peculiarities or problems specific to your environment (size, architecture, resources, adaptability, etc.) that prevent you from using the existing solutions,
  • Compelling specifications (performance, cost, stability, functionality, compatibility …).
• Identify and document conflicting constraints (eg performance versus reliability)
• Document the unpredictability of the environment to illustrate the interactions, reactions or behaviors of several components that could not be determined in advance in a given system. This may lead to the demonstration of systemic uncertainty,
• Clarify the status of the project and technology at the beginning and end of the year:
  • What uncertainties were resolved during the year
  • What uncertainties remain to be solved
• Document the reasons for abandoning prototypes.

2- Evidence of assumptions

An hypothesis is “intended to resolve scientific or technological uncertainty. An hypothesis is an idea, consistent with known facts, that serves as a starting point for further investigation to prove or disprove that idea. ”

We must therefore note the ideas, the options and the alternatives that we envisaged to solve the various uncertainties. Do not forget to :

• Date these documents,
• Specify to what uncertainty each hypothesis tries to answer,
• Identify who carried out the work,
• The best places to record the assumptions are the birth certificate, periodic reports and logbook that we will discuss in another page of this blog.

Examples

Examples of documentation of assumptions include:

• Describe the initial approach envisaged to resolve each uncertainty,
• Illustrate the alternative hypotheses envisaged (not necessarily tested, nor the final approach),
• State what tests or analyzes have been undertaken to evaluate the alternatives?
• Test plans or test reports: What results and conclusions have we drawn from them?
• At what point (following which results) was the hypothesis rejected? Or demonstrated?
• Describe what justified the initial need to develop a prototype(s)?
• Why was the prototype abandoned?

Conclusion

In conclusion, contemporary documentation of SR & ED projects is now a condition of acceptance according to the new RTAs. It is therefore necessary to prepare, enrich and save these traces of your projects during the year in order to reduce the risks of an unfortunate decision by the RTA.

We are honored to see the time you spent reading our page. The index of our blog (to the right of this page) contains several other solutions that are also intended for you. Did you like your reading? Tell us so. What should be added? What topics are you interested in? You did not like this reading? Tell us so. What is it that you disliked?

Read More

How to identify and measure the gap in technology

The Canadian Revenue Agency (CRA) is increasingly demanding documentation of your SR & ED activities. It is no longer enough to define a technological uncertainty and some deviation from standard knowledge. The CRA now requires to measure this gap.

There is not always a tool or measure ready to prove our point to the CRA advisor. This stems from the very nature of SR & ED work. We try to push boundaries, often undefined or unexplored. We must therefore use our creativity to create our measuring instruments.

Do not focus solely on the uncertainty of the product. Rather look at what is limiting the technological objectives, the methods and technologies required to resolve these uncertainties. Think how to measure the gap between these uncertainties and the standard practice.

No method is universal. And it is not a three pages’ article that will establish THE method. We are there, obvioulsy, to help you. But there is a minimum to meet the requirements of the CRA. Here are some suggestions to better identify and measure the gap to current technology and the progress of your work:

1- Define the technology adequately.

First of all, let’s start with the technologies involved. It is very easy to ill-define the technology, which can prevent us from defining our true uncertainty, what we are trying to add to it. For example, if I define my technology as the database management system, or the hydraulic pump system, the CRT can easily argue that this system has existed for a long time and that there is no technological challenge in designing a new pump.

Be more specific: what measured target does one want to reach or exceed? For example, in the management of the database, are we interested in how to improve the performance by 25% of the “blob” type of unstructured data? We need to measure our target before, during and after our experimental process and from several angles relevant to our experience (speed, number of records per second, transaction success rate, amount of data lost, etc.).

Same thing for the pump, instead of considering the whole pump, concentrate, for example, on the component under study, which limits the expected results. For example, this may be filtration, or holding the pressure.

2- Evaluate existing knowledge at the outset

We have then to connect with the rest of the planet. Are we the only ones or the first to see these limits or to try to overcome them? What are the known or studied approaches, how do we commonly solve the limit (s) encountered?

Example: List, summarize and count the number of:

– Research on this subject on Google,

– Relevant articles,

– Patent research on the subject,

– Alternative methods formulated elsewhere,

– Technologies similar for our needs and limitations,

– Components or solutions with potential to be explored,

– Analysis of external experts or technology providers,

– University studies,

– Etc.

3- Specify the relevant limits of technology or knowledge.

When the target technology is well positioned, it is necessary to specify why this part of the technology is of interest to us. This brings us back to specifying the technological limits we want to exceed. This technology has certain properties, allows certain transformations, etc., but it also has its limits, which can be translated into measurable units such as a maximum number of transactions per second, or a pressure per square centimeter, and so on.

By the way, when it is properly defined, this uncertainty may lead us to rename the project and its challenges according to technological objectives or methodologies rather than uncertainties of the product.

4- Quantify the objectives Vs standard practice

Also, the CRA requires that our technological objectives be quantified and clearly identified early in the project. Wherever possible, we must therefore measure our technologies at the beginning and our performance objectives. Let us compare them over time to existing performance standards or new ones that we will formulate. Let us keep track of them.

Example: Performance Targets 1: XXXXX

– Date

– Target

– Measuring units

– Conditions under which the test was carried out

– Measured performance

– Finding, uncertain variable 1,

– Finding, uncertain variable 2, etc.

– Results, Comments and Conclusions

5- Link research steps to specific uncertainties and measure the progress

Finally, parallel to these examples we define an experimental development process, its essential activities, and its stages. We clearly identify where we are trying to resolve uncertainties and what alternative assumptions are being analyzed. We then define relevant criteria and measure them. The existence of such measures clearly differentiates experimental SR & ED work from routine work.

Conclusion

In conclusion, there is no limit to your creativity to define original methods of measuring your technological progress. Similarly, there is no limit to cuts that the CRA can apply to an experimental project that is not well defined, documented and supported by adequate measures. The choice is yours.

And you what do you think about this ? Do you have any tips or ideas to share on measuring the progress of your work?

Did you like reading this? Tell us so. What should be added?

You did not your reading this? Tell us so. What should be corrected?

What topics are you interested in?

Read More

How to organize your SR & ED documentation?

There is still a popular belief in the collective imagination that verbal testimony is sufficient to convince the RTA that our projects are SR & ED. No more. We are very far from that. Everything changed. It is no longer the same program.

How do you meet the new CRA requirements? Simply put : organize a better documentation system. Document throughout the year. Establish a light system for use by your staff but at the same time a precise and disciplined mechanism. There is no choice. The new requests from the CRA are there, in black and white. Let’s look at how to better organize to document your SR&ED.

A story from the good ol’ time …

I have been preparing SR & ED claims for over twenty years. Ah, back in time! The grass was softer and greener! I remember it as if it were yesterday … Let me tell you how much everything has changed.

At the turn of the century, the CRA managed SR & ED as an incentive program to take technological risks. The CRA accepted “even minor” advances and projects were defined and judged at the highest possible level to bring out the overall issues. Project descriptions had no word or page limit. Project documentation was often produced in the normal course of the commercial project with few references to the SR & ED project. When auditing the documentation, it was first supported by verbal testimony from the resources involved in the project. Some documentation demonstrating that development had actually taken place was enough to reassure the RTA. Requests for detailed information related mainly to the accounting aspects: evidence of payment of invoices and salaries.

Today’s approach is one of compliance control. We are suspected of fraud until proven guilty. We have to prove that we deserve the credit. A project description is limited to 1,500 words. Major projects must be broken into small SR & ED chips. The CRA wants proofs that you have identified your eligible projects throughout the year and that you manage and document them as separate SR & ED projects from your other development projects. You should note and date your technological goals, your uncertainties, your assumptions, your tests, your conclusions for each hypothesis. In short, you almost have to demonstrate that you have a laboratory in your plant. There must be a highly structured and documented experimental process. Verbal testimony is no longer sufficient for audit if it is not corroborated by tangible written evidence.

Documenting what

There is no definitive list of sufficient evidence, a complete guide to whatever it is possible or necessary to document to demonstrate the eligibility of our work. The T4088 Guide indicates that “contemporaneous documentation that is dated, signed, and specific to the work performed are the best supporting evidence that you can provide. ”

We have already discussed the reasons why the CRA doesn’t define more precisely the necessary and sufficient documentation to satisfy the CRA’s RTAs. Let’s look at what can be done simply to document the past.

Your Advisor

What is your relationship with the CRA and your RTA? It is very important to maintain a positive relationship with your technical representative. He will judge your case. Everyone has their little preferences in terms of documentation. A phone call or even a visit can be very informative. Is the advisor of the last technical audit always in charge of your file? You are the taxpayer, you have a right to know that. What are his personal requirements in terms of documentation? Would he like more texts? Does he prefer pictures? tables ? A paper or electronic documentation? He’s your advisor. Build your relationship with him because it’s his opinion that counts.

Your inventory

What do you have in place now? Make an inventory of the documents available for your projects and compare this with the incomplete list of CRA requirements (T4088 Appendix 2). Most development teams use a project tracking system. This is a good start. There are some interesting information.

You probably have emails and SMS messages. Especially those from the main technical experts of your development projects. Gather, date and securely store all e-mails, reports, analyzes, web searches, test results and internal discussions relevant to your project and work. You make drawings on the whiteboard? Take a dated photo. Do you have a functional prototype? Capture it in video. All of these sources contain relevant information to build your documentation.

Develop a project log by compiling in one place the relevant information and the path followed by your team. You will get a “collage” easy to consult and sift later. Your documents do not need to be long or well formatted. They must be relevant and dated.

Your computerized project accounting systems, timesheets and the like are credible sources for the CRA. The same applies to contracts with your subcontractors and customers for whom the projects were carried out. These are all sources of demonstration for your claim : how much and when your activities we performed.

Don’t wait

From the start of the project, bring together everything that can be used to testify directly or indirectly to the relevant facts . And it is necessary to identify relevant information early and keep track of it or a copy, since information tends to get lost in the masses of data produced daily.

We are always at risk of losing an important development resource during a movement of personnel, so we must insist that everyone contributes to build his traces, evidences and other artifacts DURING THE PROJECT. That is part of their job. The financing of the development project is the responsibility of all the main contributors.

Conclusion

In conclusion, documenting a SR & ED project is everyone’s business and it is important throughout the project. Do not wait until you have to defend this project in front of the CRA. You will then have to live with the strengths and weaknesses of the available information. That day you will feel a huge void when you see the little evidence you have to convince the RTA. And compassion? … Good luck, this is not a reliable strategy.

And you what do you think ? How do you document your SR & ED projects? Do you have any trick? Ways of doing things or ideas to share? How has the CRA responded to your documentation mechanisms?

Did you like your reading? Tell us so. What should be added? You did not like your reading? Tell us so. What should be corrected?

What other topics are you interested in?

Read More

SR & ED – How to document uncertainty and the technology gap ?

The documentation of projects and activities claimed as SR & ED is increasingly important in the claim process. We look at why it is difficult to document the technological uncertainty, especially in the context of experimental development (ED). We propose a simple method to document current practice and “the gap in technology” that will better illustrate this uncertainty.

1- Why is it difficult to document the technological uncertainty

In recent years, the CRA has stressed the importance of documentation as to almost make it a new eligibility criterion. Many written requests for additional information by the CRA these days include a request for examples of project documentation. We have reached the point where the issue of documentation is one of the main obstacles to obtain credits for SR & ED.

1.1 No clear directive

At first glance, this requirement may seem difficult to put in writing. Yet this issue could be resolved to the benefit of everybody if the CRA simply emitted a sort of “standard” that would show to the auditors and taxpayers what is needed to support a SR & ED claim.

Of course, there is Appendix 2 of the “Guide for complete Form T661 – T4088”. But these are only examples. The CRA does not specify what is required, necessary and sufficient.

1.2 The effect of not clearly defining requirements

The fact that the CRA did not provide more detailed written instructions on its documentation requirements means that a CRT can always indicate a “lack of documentation” or “insufficient detail about the work performed and claimed” as a reason to reject a claim. Since there is no written standard or clear test to determine what is necessary, it is almost impossible for a taxpayer to challenge such a decision.

Warrant a negative assessment of SR & ED as “insufficient documentation” is very easy and cost effective for the CRA. It is certainly much more efficient than requiring the CRT a rational and documented explanation of why it considers that there is no technological uncertainty or technological progress.

2- The case of Experimental Development (ED)

Documenting is even more problematic, because most companies claiming SR & ED actually claim experimental development (ED). The initial objective of these projects is usually to create a “product or a new or improved process” but not to create new knowledge. This problem is complicated by the fact that there are two types of required documents:

2.1- Accounting records and time:

This requirement is quite easy to satisfy and most companies can implement a simple process to comply.

• Prove that when working on this project, you have
  • time sheets,
  • contracts and subcontractors’ invoices,
  • frequent reports, and
  • other contemporaneous documents.
• Make sure that the hours worked are detailed by project, activity and employee. You also need a clear explanation supported by facts about the end of the project.
• Use a formal chronology and / or a Gantt chart.

2.2- Technical documents

These documents must corroborate that the activities claimed as SR & ED were actually carried out during the claimed time span.

The documentation of the development of a new product is usually focused on the progress of the project and on meeting the customer requirements and specifications. But this is not the language nor what the RTA is looking for.

It is therefore essential to create specific documentation for the SR & ED project. It will focus on three basic requirements of the CRA rarely documented in a product development project :

1. The standard practice for this technology in this industry has been defined and measured with respect to at least one reference,
2. You must demonstrate that your activities go beyond routine engineering and standard practice. This is to define and demonstrate the gap between what is desired and what can NOT be processed using existing technologies and standard practice knowledge,
3. You also need to characterize the experimental process: the solutions explored, hypotheses generated, experimentation performed, analysis, results and conclusions, and who worked on these activities

3. Documenting the standard practice and the “technology gap”

The CRA requires to demonstrate more than the work done. We must increasingly prove that this work represents a “progress” compared to the “state of the art” (also known as standard practice) of the technology. If this is unsuccessful, the taxpayer may show  excellent proofs of his research, but it still does not satisfy the fifth question to identify if it is SR & ED.

Once this “state of the art” is defined, it is easier to decide which documents represent the “experimental procedure” or activities that are or not part of the SR & ED and why. Although this goes beyond the absolute requirements to claim SR & ED tax credits, it is an effective method to better defend the claim, while paving the way for additional protection of intellectual property.

Establish, define and gather the facts relevant to the “state of the art”. Then you specify what was possible with this technology and compare it to what was necessary or required to realize your project. That’s a key to define the uncertainty encountered in a SR & ED project. We call it “technology gap”.

4- Conclusion

To conclude, the analysis of the technological gap and documents depicting the essential landmarks of the experimental process would normally satisfy the RTA. Note further that the date on which this gap has been identified as a central barrier is often used to establish the beginning of the SR & ED project. You must write and date every documents related to the project and defining this difference in technology.

And you what do you think about this ? How do you define the technological uncertainty in the course of your SR & ED projects? Do you have any tips? Ways or ideas to share about it ? How did the CRA respond to your documentation mechanisms?

Did you like reading this article? Tell us so. What should be added?

You did not like reading it ? Tell us so. What should be corrected?

What are your themes of interest?

Read More

How to document SR & ED: a low cost, simple method

How can we meet the intensified documentation requirements of the CRA? What is done in practice in the industry to document projects for SR & ED ?

A simple answer lies in the T 4088 guide for the T661 :

” It is important to maintain supporting evidence (for example, information, records, documentation) to substantiate that the scientific research and experimental development (SR&ED) work was performed and allowable expenditures have been incurred. (…) In fact, contemporaneous documentation that is dated, signed, and specific to the work performed are the best supporting evidence that you can provide. ”

This is fine in theory, but in practice, how do you generate and maintain contemporaneous evidence to meet the CRA prescriptions?

Do you realize the increasing level of risk you submit your claim to if you do not set up a contemporaneous system of documentation for your SR&ED activities?

Background

The position of the CRA regarding the documentation has evolved over the last decade. It was a secondary issue at the time, but now the implementation of a contemporary evidence record keeping has almost become an additional criterion. In recent years, it became the fifth question to determine if there is SR & ED. The reasoning behind this is that proof recording has become a defining characteristic of the SR & ED. So, if there is insufficient documentation, then not only the job is not supported, but it must not be SR & ED.

In the context of the budget constraints of recent years, the recovery mentality has thrived within the CRA. The documentation was a potentially faster way to put the claims aside when the program workload increased. The documented evidence has become, for the CRA, a great way to reach a significant recovery (or rejection) rate of the claimed tax credits. All that was needed was to move from a “seems reasonable” to a “prove it” position .

Contemporaneous documentation

The requirement of contemporary documentation implies that information produced later (eg. the year-end reports) has less value to the CRA. The CRA is seeking for documentation that was produced naturally in a project and which should be sufficient to support an SR & ED.

Some claimants believe that this means that any paperwork related to the project should satisfy the CRA. It does not work like that.

The true meaning of this requirement is that the generation of supporting documents is a characteristic of a SR & ED project. Once again, here is the reasoning of the CRA: If the documents produced in the normal flow of a project are not enough to support a claim, the project is not only unsupported as SR & ED, but it is not SR & ED.

So we must demonstrate to the CRA that throughout the year you quickly identify your eligible projects, and that you manage them as SR & ED project, segregated from your other development projects.

A simple documentation system at low cost

We cannot expect that small claimants will keep detailed laboratory notebooks dedicated to their research, and that they will acquire equipment and scientific experts in the literature that such an approach seams to require.

Therefore here is a simple and effective approach to implement your contemporaneous documentation.

The core of this system rests on two pillars: That is :

• Continuous documentation system
• Leaning on your key project employees.

We need to create a system to capture the eligible activities during the year, and to:

• Be regularly used by employees because it is not heavy and bulky,
• Facilitate the year-end form preparation (T661), and
• Meet the requirements of the CRA.

Here is the solution :

1- Train your development staff to recognize the eligible activities by :

• Attending to the CRA public seminars.
• Training all project management staff and R & D teams.
• Refreshing memories and updating about new items.

2- Set up a formal early projects tagging system as soon as the development team meets it’s first major issues.

• The development teams may use filters or tags to identify SR & ED activities and archive the results.

3- Motivate the staff to save potentially eligible activities

• Remind them of the importance of the program for the company – reducing taxes, increasing liquidity, creating and maintaining jobs, etc.
• Transfer some of the results of the SR&ED tax credits claims to the R & D projects budget so they equip themselves or they initiate interesting new research
• Set up an individual incentive bonus program for their contribution to the success of claims.

4- Require “birth certificates” from the development teams at the beginning of a project

• The birth certificate is a condensed early overview that identifies:
  • The main constraints and technological challenges;
  • The potential technological uncertainties;
  • The desired technological advances;
  • The potential approaches or hypothesis – proven and unproven.
• The certificate is used as a starting point for the T661 form.
• Archive birth certificates or include them in your regular management reports.

5- Check the system and enforce compliance

• Appoint a technical leader to work with the controller
• Identify projects with good claim potential and for each one write a plan of the work to be done
• Have regular project monitoring meetings and keep the minutes and resulting actions
• Regularly review the documentation files

6- Produce regular reports of progress of work following the birth certificates:

• Take note of :
  • Problems,
  • Hypotheses raised,
  • Progress results,
  • Problem solving processes,
  • The major events.
• Collect and archive these reports regularly (weekly, bi monthly, etc.).
• Include various reports such as:
  • Test results report for the SR & ED
  • Design review reports
  • Reports on major events,
  • Regular reports on specific situations,
  • Draft T661, etc.

7- Keep a complete copy of each key prototype including its performance data, its production and test environments.

8- Develop a system to segregate eligible activities from routine ones:

• Set up a separate R & D department
• Discriminate technology issues from those of stemming from new product development
• Set up a codification of projects with sub-codes to identify SR & ED
• Record the experimental activities and link them to the project plan in your project management system
• Make sure to record the time spent per employee per activity, especially for eligible activities.

9- Follow the costs:

• Plans and reports on the actual resource allocation;
• Detailed timesheets for the SR & ED activity;
• Periodic supervisors reporting.
• Keep up to date, for each employees and subcontractors:
  • Name and contact information
  • The number of hours or the proportion of their time spent on eligible activities per project
  • The link with the payroll system and the G / L
  • Each qualifications for this project:
    • Their technical role
    • Training / Experience
    • Years of experience
    • Arrival / Departure dates in the project
    • Feedback, special contribution, etc.
  • Identify and document the indirect and support activities necessary for the SR & ED:
    • Equipment and material preparation
    • Experimentation and results analysis
    • Recording measures, calculations and graphs
    • Identifying the eligible support activities
    • Direct supervision of SR & ED activities
  • Document the cost of materials consumed and / or transformed
    • Review the definition of materials consumed or transformed (when using the traditional method)
    • Note the materials sold or converted to commercial use
  • Keep copies of the signed contracts for outsourcing and customer contracts involved in your projects for SR & ED

10- Keep any other information as back-up, when applicable

Conclusion

Such a system generates several important benefits:

• A better monitoring of the R & D
• An early screening claims
• A better understanding of R & D by all
• A reduced risk of missing eligible projects
• An increased likelihood to meet CRA requirements
• An increase in the value of SR & ED claims

And you, what are your experiences and discoveries in documenting your SR & ED? Do you need help to set-up such a documentation system for your claims?

Read More