SR&ED DOCUMENTATION

and CLAIM PREPARATION

 

In recent years the Canada Revenue Agency (“CRA”) has increased the rigour of SR&ED reviews. 2 recent court cases (Highweb & Page Group Inc [2015 TCC 137] and Hypercube Inc [2015 TCC 65}) found in favour of the CRA on the basis that there was, amongst other things, insufficient contemporaneous documentation to support the claims.

Luckily these did not technically create a precedent as they were heard under the informal procedure rules. However it is clear that the CRA is looking for more and “better” documentation of a systematic approach to resolve technological uncertainties.

In the current environment claimants must keep regular, “contemporaneous” documentation of eligible work throughout the year.

 

 

A SR&ED project description must provide short answers to 3 questions:

1.  What technological uncertainties had to be overcome in order to achieve your ‘experimental development’ objectives? {maximum 350 words}

2.  What resources were applied systematically in the attempt to overcome these technological uncertainties (i.e. what was done)? {maximum 700 words}

3.  What was learned? {maximum 350 words}

 

WHAT IS ELIGIBLE EXPERIMENTAL DEVELOPMENT?

In recent years the CRA has begun using these 5 questions as a guide to determining eligibility. Claimants must be able to answer YES to each of these questions:

 

  1.          Was there a technological risk or uncertainty which could not be removed by routine engineering or standard procedures? {introduces the concept of “routine engineering”}
  2.         Did the person claiming to be doing SRED formulate hypotheses specifically aimed at reducing or eliminating that technological uncertainty? {claimant must use a systematic approach and have a “theory” regarding how best to overcome the uncertainty}
  3.          Did the procedure adopted accord with the total discipline of the scientific method including the formulation testing and modification of hypotheses? {further emphasis on the importance of a systematic approach}
  4.        Did the process result in a technological advancement? {if steps 1 to 3 are followed there will necessarily be a technological advancement – since it will necessarily lead to new knowledge}
  5.       Was a detailed record of the hypotheses tested, and results kept as the work progressed? {the key to a successful claim is “contemporaneous documentation”}

 

 

WHAT DOESN’T QUALIFY?

According to the CRA:

development work that is experimental in nature and that is undertaken for the purpose of achieving technological advancement for the purpose of creating or improving existing materials, qualifies, but development work that is routine in nature does not qualify

Government of Canada News Release 92-088, December 2, 1992

If a qualified person (i.e. an engineer or technologist) can be reasonably certain of the outcome by simply applying known techniques in “the standard way”, there was almost certainly no eligible SR&ED.

In other words, if you GOOGLE the problem and can find detailed instructions or a YOUTUBE video, it is probably not eligible. In fact that is one of the first things that a technology advisor at CRA will do when reviewing a claimant’s project  description.

Having said that, some ‘out-of-the-box’ solutions don’t work and require extensive (and eligible) modifications to work within a claimant’s own technological environment.

When innovative companies attempt to make new or improved products they don’t purposefully set out to address technological uncertainties. Instead they seek to improve the features and the functionality of their products.

Too many claimants – when they write SR&ED project descriptions – focus on the new and improved products and features that they have successfully developed – and ignore the technological difficulties and challenges.

Eligible SR&ED only occurs when the developer overcomes (or fails to overcome) the technological uncertainties that were faced when developing the product. While it is often counter-intuitive for product development teams to focus on the challenges and problems that were encountered during the year, that is exactly what the CRA requires.

Product development that only contemplates a single ‘technological’ approach is unlikely to be eligible SR&ED.

WHO SHOULD IDENTIFY the TECHNOLOGICAL UNCERTAINTIES? and  WHEN?

There is a requirement that SR&ED claimants employ technically competent and qualified staff in order to claim eligible development work. If you’re performing eligible SR&ED you undoubtedly have someone competent on staff to lead the development work.

The identification of eligible technological uncertainties can require a great deal of subtlety. Often even competent technical staff have difficulty describing the uncertainties adequately. However most skilled development staff can describe possible alternative solutions to problems that they face. They are also well aware  when product development efforts stall, or hit roadblocks.

If your company is investing in product development and believe that it may be eligible, you’ll need to engage someone with sufficient professional competence to understand what “standard practice” is. What’s more if your product development plan only contemplates a single ‘technological’ approach, it is unlikely to be eligible SR&ED.

Claimant’s must employ a skilled ‘technologist’ to put forward the development plan

Claimant’s must employ a skilled ‘technologist’ to put forward the development plan and their plan should document what the technological uncertainties are (i.e. why they don’t represent standard practice) and what alternatives they are considering to overcome the uncertainties. This development plan should be done BEFORE work commences.

The development plan should be done BEFORE work commences.

Of course we all know that the “best laid plans….”

In any experimental development program unanticipated problems can arise throughout the year. These problems represent excellent evidence that technological uncertainties were present. All members of the development team should be enlisted to document problems and alert the rest of the team to their existence.

All members of the development team should be enlisted to document problems and alert the rest of the team to their existence.

This regular and ongoing documentation of issues is what the CRA refers to as CONTEMPORANEOUS DOCUMENTATION.

WHAT DOES CONTEMPORANEOUS DOCUMENTATION LOOK LIKE?

Problems encountered during development are a good indicator that eligible SR&ED was being done. The CRA prefers to see (and may insist) that documentation is “contemporaneous”.

In previous years they put forward the notion of “naturally-generated information” although they seem to have forgotten that idea in favour of the “total discipline of the scientific method”. However it is clear to us at least that it is more effective to use documentation systems that form a natural part of the development process.

If the documentation process is too cumbersome and ‘unnatural’ – perhaps designed by a well-meaning accountant strictly for compliance purposes – there is a significant risk that development staff won’t use it anyway.

Instead development teams should focus on tweaking existing documentation systems to accommodate SR&ED. For example software developers generally use source code repositories to record check-outs and check-ins of software code. These systems will often allow users to export check-ins/check-outs to a spreadsheet or comma separated value file. For software claims, these systems are often an excellent source of contemporaneous documentation.

Many development teams also use project management software to manage activities and assign resources to projects. These systems are widely used by engineering professionals in a great many disciplines in addition to software.

In the case of modifications to a manufacturing process there will almost certainly be trial production runs. These production trials are dated (i.e. clearly contemporaneous) and are themselves evidence of experimentation.

Most development teams have regular meetings to discuss the status of the work and the problems encountered. Recording these meetings and keeping notes is an excellent way to provide support for the fact that eligible SR&ED was going on – and who was working on it.

We recommend exploiting the existence of such systems and – where possible – to examine ways to extend their usefulness in providing documentary evidence for SR&ED projects.

Team leads and project managers should insist that development staff use capabilities to add comments to records within these systems, and provide a little rigour around their documentation efforts.

The CRA has long expressed a desire for timesheets to document SR&ED activities. While useful, it is important that development teams take this task seriously and put descriptive information in their time records. A half-hearted implementation of 3 different systems is less effective than ensuring that your primary documentation is sufficiently robust to allow SR&ED activities to be identified.

In essence SR&ED claimants must extend their accounting systems to allow for rudimentary activity-based costing (“ABC”). For small, private companies there is really no such thing as accounting software systems that incorporate ABC.

So the best alternative is to superimpose a form of activity-based costing, by referring to one or more of the development tools:

  • project management software
  • source code repositories
  • timesheet systems
  • production trial data

and derive rational cost allocations after-the-fact.

For small companies, a couple of useful approaches could include:

  1. document issues that arise in regular meetings of development staff
  2. send emails documenting development issues to a pre-assigned email address (eg. sred@devco.com)