SR&ED Ottawa Software Seminar (Part 2 of 2)

Reference Article (>5 Years Old)

SR&ED Ottawa Software Seminar (Part 2 of 2)

The Ottawa SR&ED office holds a free annual Software Seminar information meeting, which occurred a few months ago on February 29, 2012. During each session, the CRA offers advice and clarification on how software development fits into the SR&ED program.  This writeup is the 2nd part of the series “SR&ED Ottawa Software Seminar”; you can read about the first half here.  Was it successful?  Read on to find out!

Presentation 2: Process Improvement & Legacy Software

Scenario: A 3D printing company has recently expanded into worldwide operations, and must coordinate dozens of suppliers, material transportation and similar management.  The development of an ERP system was started to consolidate everything and merge all control aspects together (including databases, personnel, 24 languages, 32 currencies and 48 different legacy systems).

As with the first presentation, we began by brainstorming potential uncertainties that could be involved.  The group as a whole came up with the following:

• How to calculate local prices, and the algorithms required to juggle the variables.
• System uncertainty caused by the integration of the 48 legacy systems.
• Translation and local data manipulation.

All of these potential uncertainties came with the ‘It Depends‘ qualification.  Based on the available technology the company had access to (one of their subsidiaries may have already solved the problem for example), each of these elements could be made trivial.  The presenter emphasized the concept of ‘System Uncertainty‘, which relates to complications that are caused by the combination of technologies.  However, a common issue the CRA sees is that the System Uncertainty is never explained.  A concise explanation of what would cause the combination of disparate systems to fail is required to successfully claim SR&ED.

The conversation was sidetracked by a specific question asked by one of the audience members with regards to what constitutes ‘taxable suppliers’.  Since the SR&ED program is Canada-centric, all contractors and material suppliers claimed for SR&ED must also be paying taxes in Canada.  However, the question was what happens when you have layered supply chains and sub-contractors performing the work for you.

For example, if you hire GlobalCo (who have offices in Canada) to perform SR&ED activities on your behalf, but they go and contract the work to CodeCheapCo which solely operates in, say, the Philippines….  how does this affect your own SR&ED claim?

The answer, as with a number of things, is that it depends.  A CRA representative indicated that ideally there would be a clause in the contract with GlobalCo stating that all work would need to be done in Canada.   In the absence of this, due diligence must be performed on your behalf before claiming SR&ED on the costs.  If it becomes apparent that the work was not conducted in Canada, it cannot be claimed for your own tax credit.

The supplemental scenarios primarily focused on how SR&ED software programming interacts with international activities.  For example, they re-iterated that a maximum of 10% of each developer’s time can be spent outside the country, and how there can be differing calculations for the Provincial tax credits based on this difference.

Again, the presentation was moderately useful, especially for companies handling international deals.  The focus on process improvement and legacy upgrades were useful, especially since many companies are running into issues caused by 20-year old software.  However, once again, few specifics were actually provided since it all came down to “It depends on the detailed facts of the specific case.”

Presentation #3: Mobile Development & Hardware Development

Scenario: Five years ago, Lithe-Tech created a custom mobile operating system called MOS; the completed product was released in 2009.  In subsequent years, enhancements were built into the commercial product (e.g. GPU acceleration, external memory card support, SSH etc.) and claimed SR&ED for the related eligible activities.  For this year’s SR&ED claim, Lithe-Tech is attempting to claim SR&ED on a USB On-The-Go specification, which will require three protocols to be developed.  During the period, Lithe-Tech acquired a second Canadian company (SPN Mobile), which had developed a similar product (MOS-TAB) which supported the protocols of interest; during the period Lithe-Tech engineers reviewed and extracted the source code for the relevant protocols.

The discussion for this presentation went in a very different direction compared to the other events.  Everyone agreed that since the knowledge was simply purchased and it was straightforward to integrate into the existing MOS system, that the cost could not be used to claim SR&ED on these aspects.  Other activities might be possible to claim, but more details would be needed.

At this point in the seminar, some attendees had begun asking more specific questions about the program, and the rest of this 45 minute period was spent discussing a few different topics:

T661 Organization

One person noted that the word limits imposed by the new T661 were very restrictive, especially for software claims where detail is necessary.  The CRA representative replied that in their experience and local surveys, 90% of the respondents are satisfied by the word requirements.  He recommended splitting projects up if necessary.  We’ve compiled a number of other tips in our post here.

Defining Bug Fixing/Maintenance Activities

Several participants raised the question of where the CRA draws the line between routine ‘bug fixing’ activities which aren’t eligible for SR&ED and actual development which is.  Frustratingly, the answer was ‘it depends’.  They recommended that the applicant look at the actual error itself, and how the system was constructed at the time.  If the developer working on the bug fix can say “this is how it’s done” then it is likely a routine activity.  The CRA emphasized that it is extremely important to use the terminology of the industry when describing these activities and not gloss over key points.

Presentation #3B – Financial Questions

It’s worth highlighting the last part of the 3rd presentation, because a lot of interesting financial questions were brought up and answered by the CRA, especially with respect to software.

There was a long conversation explaining how software acquisitions were treated by the CRA.  Is it a material consumed? Transformed? New vs. used software?  One argument states that once a license for a software device has been used, it cannot be sold again (zero value) so therefore it is a material consumed.  However, it is still an asset and can depreciate.  Also, Sub-section 37(4) of the ITA states that “No deduction may be made under this section in respect of an expenditure made to acquire rights in, or arising out of, scientific research and experimental development.”  At some point in the past year or so, the CRA has made an internal ruling that:

All software purchased for the use in SR&ED work should be considered a capital expense.

However this also means that the software used must comply with the All-or-Substantially-All (ASA) requirement of regular capital expenses.  This means that 90% of the product’s useful time must be spent on SR&ED related activities.  The ASA requirement is based on the ‘intent’ of the usage.  If the purchased software is used as a tool to help the development of the technology, then the cost is eligible.  However, if you simply incorporate the purchased software into the technology itself, then you cannot claim SR&ED on that cost.

Software licenses are often temporary lease agreements, and the CRA allows lease costs as eligible expenditures.  In general, they use the following, based on the length of the software agreement.

If the software lease is >1 year, you must capitalize the cost.

If the software lease is <1 year, then classify it as a lease cost.

Some of this advice will be made irrelevant with the T661 budget changes, but it was an interesting discussion.

 Overall Impressions

I considered it a useful seminar, but not nearly as comprehensive as it could have been.  The presentations were clear, the presenters did a good job, the CRA representatives helpful for the most part, but I don’t think many of the attendees came away completely satisfied.  The biggest challenge with software claims is the apparant subjectivity of the reviews.  Many audience members brought up a few examples of companies successfully claiming self-admitted routine development, while others are meeting with RTAs annually to defend their ground breaking innovation.  The CRA’s response to this is that “it depends“, and that they “don’t have enough information to make a judgement.”

The examples provided by the Software Committee were an excellent step forward and highlighted some key points, but again, perhaps due to time constraints, they were not very detailed.  In the future, I will definitely be attending the SR&ED Ottawa Software Seminar, but hope that the will continue to expand upon what qualifies as SR&ED in the cutting-edge fields of software and mobile development.

What are your experiences with claiming software development as SR&ED? Are there specific problems you have encountered in the past?

** Note: In 2020, the CRA updated the term “Ombudsman” to “Ombudsperson”. **