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 year, a new presentation format was introduced and several case studies were put forth to show eligible and ineligible activities. Was it successful? Read on to find out!
Attendees & Format
In total, there were about 70 people who were in the large meeting hall at the Nepean Sportsplex. It seemed as though there was a good representation from different interested parties, though the majority of the attendees were from accounting firms and SR&ED specialists. There were a few people who came from small businesses but they were unfortunately in the minority. It appeared as though the entire Ottawa SR&ED office were also in attendance; some of them helped with the presentations, while the others sat in on the different sessions and provided their own insight on the specific topic.
All presentations at the seminar were created by a separate, independent SR&ED Software Committee, which is a joint venture containing representatives from the CRA, industry and SR&ED consultants. The committee meets periodically throughout the year and provides guidance and advice regarding how software is handled by the SR&ED program.
For this year, there were three presentations, and all participants were divided into 3 groups so that each presentation could be given simultaneously to a different audience. All presentations tried to focus on different areas of software development, though open questions were encouraged in every group which often caused the conversation to diverge if an audience member had a specific question. In each presentation, an example scenario was provided to everyone to read over and then there was a discussion about the merits of each case from a SR&ED perspective. Sometimes there was a financial focus, other times it was all technical.
In general, this setup worked quite well and I encourage the group to continue this next year. There were some noise interruptions caused by the other groups since we were all in a single large room, but they were largely minor. All presenters were well spoken and appeared eager to answer any, and all, questions that the audience had.
Presentation 1: iPads in Hospitals
Scenario: A local hospital has recently purchased a number of iPads and has hired a local contractor to help with the integration of their original software system with the iPad environment.
After reading through the scenario (which included a few additional details), the presenter emphasized that the first thing that needed to be determined for this project to potentially qualify for SR&ED was the presence (or absence) of technological uncertainty. He then opened it up to ask the audience for suggestions. Everyone brainstormed potential issues which may create uncertainty:
- wireless interference caused by the iPad in a hospital environment,
- incompatibilities between architectures (Java vs. Android vs. iOS),
- interaction with legacy architecture/software (e.g. HL7) in the hospital systems.
However, the list came with a caveat, and this quickly became the word of the day for the event:
Specific details would need to be considered for every unique project. As a result, a further, more in-depth study of the specifics would be required to come to a conclusion. Several additional phrases came up which I found particularly interesting included:
- “Don’t have an obvious path from A to B”,
- “Never assume there is SR&ED, never assume there isn’t.”
The most interesting concept raised in this seminar, which I had never encountered before was that the presenter suggested that the project should be considered using a “Peer Test”. As in, would the company or individual who created the technology be proud to show them to a similarly experienced group of engineers or peers? Would these peers be impressed by the capabilities of the system, if they were provided sufficient details?
After this initial discussion, information was introduced as an addendum to the original scenario which modified the circumstances slightly. Some highlights of this discussion included:
- Companies MUST perform reasonable searches of open sources of information before beginning SR&ED; time spent researching a publicly available piece of technology will not be eligible.
- No one works for free! If a business owner pays himself a salary of $60k for a 40 hour week in which he spends all of his time conducting R&D activities, but also spends 20 hours a week in the evening doing other business development activities, he must account for the full 60 hour week for SR&ED purposes.
Overall this was a reasonably useful discussion. It was obvious that many in the audience were frustrated with the “It Depends” arguments, which would only get more prevalent as the morning progressed. Another interesting takeaway that I noticed was that the CRA was not against claiming mobile development or similar activities, but they seemed to require a high level of proof that the activities were not routine development. This was particularly the case for ‘porting’ activities such as moving from Java to other languages, or upgrading legacy systems.
To be continued…
We will continue the discussion next week with more details on the 2nd and 3rd presentations (which covered Process Improvement/Legacy Software as well as Hardware/Software Interactions).
Please Note: This discussion and review is based on the notes taken during the event and memory of the discussions. It is not meant to offer a complete summary of CRA official policy.