The technical, logic-oriented side of me has traditionally despised SR&ED; and I’m sure that the ambiguity, subjectivity, procedural vagueness, lack of structure and transparency are nightmares for other likeminded individuals too. In this post, we breakthrough the confusion and deliver a succinct, objective methodology for Canadian IT professionals, most of whom have at one point or another grappled with SR&ED and reluctantly accepted the guidance of consultants as the sole authority.
I’m really curious: what’s been your experience with SR&ED?
Drop me a line if, after reading this, you still aren’t clear about what’s in and what’s out.
Conclusion #1: Outsourcing Claims
There are no shortage of consultants, claiming expertise and exclusive insights into the muddied waters of SR&ED, willing to help you navigate the terrain and maximize your claim potential, even on a contingency basis. In my experience, based on both accepted and challenged claims, these services offer little value-add. At their core, successful SR&ED claims should be transparent enough to be authored by internal resources, assuming they’ve been properly acclimated to the process and its common pitfalls (what this post is intended to help with).
So here it is, in a nutshell; the 6-step guide to successful SR&ED claims:
- Familiarize yourself with the fundamentals of the program; understand the difference between IRAP and SR&ED .
- Read the Guidance on Eligibility of Software Projects for the SR&ED Tax Credits and Developing and Documenting Claims ; yes, it’s an old document, but the cases and methodology are very much relevant even for current FY08, FY09 claims.
- Group each part of your claim clearly under the three criteria of eligibility: Technological Uncertainty (TU), Technological Content/Chronology (TC) and the Technological Advancement (TA). Note that under the revised T661 form  for 2009, TU = 242, TA = 240, TC = 244; the new ordering they’ve suggested is actually counter-intuitive and somewhat harmful, IMO. You will complete a separate Part 2 – Project Information for each project claimed in the year.
- Order is paramount: start by succinctly and confidently identifying the Technological Uncertainty (this obstacle is commonly referred to as a “nugget”) as a first-step; TU is the foundation for everything else and it should have the following characteristics (see Update #1 on when TU can be defined up front):
a) Element of Surprise Must have been an unplanned, unforeseen hurdle; i.e., it caught your team off-guard mid-stride in the delivery phase. b) Risk Must have jeopardized successful execution of the project and achieving the stated deliverables; put differently, it introduced new risk in completing previously scheduled work that would have otherwise transpired if it wasn’t compromised by this hurdle. c) Non-Routine Routine uncertainties resolved through code or peer discussion and/or optimization, calibration-type exercises are not included; it must be shown that there is a fundamental problem with the underlying technologies. Refer to 6b) for validation through peer reviews.
IC97-1 Sec. 3.2: A technological uncertainty arises when the solution is not readily apparent to appropriately skilled and experienced software developers. Uncertainties that arise from lack of diligence or lack of appropriate expertise, such as the failure to use commonly available information, or lack of programming knowledge are not technological uncertainties and relevant to eligibility.
- For each nugget, prove Technological Content/Chronology by demonstrating:
a) Experimental Development This doesn’t necessary mean that you attempted each approach; it means you researched, analyzed and carefully considered potential work-arounds before ultimately accepting or rejecting them. You can apply scientific methodology without actually prototyping each option; applying defined selection criteria to each alternative, and reasoning about why they pass/fail is sufficient.
By showing the evolution of the design (confirmation of approach or changes in design approach or
changes to the specification) resulting from each analysis, prototype or test, the taxpayer also demonstrates
b) Technological Gaps This is often the hardest criteria to satisfy. When encountering a hurdle (A), experts are trained to immediately jump to solution (B); but merely observing that A doesn’t work and offering B as a working solution is insufficient. You need to: a) understand why A doesn’t work, b) show a systemic progress from A –> B, with discussion and analysis of in-between alternatives, and c) only arrive at B only with a conclusion that demonstrates its efficiency over the others.
Trial-and-error involves executing a series of probes that were not sequenced in a systematic pre-plan. The objective here is to resolve a functional problem (as in routine debugging) rather than to gain understandings that are expected to be more widely applicable. The lesson learned in each iteration of “trial and error” is simply “that an option didn’t work” and they are not applicable in a much broader sense. For each iteration the probe is chosen that is now judged to be the most efficient in resolving the immediate problem. The process proceeds quickly from iteration to iteration.
As stated in IC97-1, “experimentation or analysis in a situation where there is technological uncertainty”, is a strong indication of project eligibility. The claimant should strongly link the experimental work to the Technological Advancement sought and to the Technological Uncertainties declared in the technical description of his project. In this way, the claimant will show clearly that specific experimental work is aimed at resolving the Technological Uncertainty and thus constitutes an attempt at providing the Technological Advancement.
c) Qualified Personnel SR&ED is not concerned with ramping people up or learning new technology; it does, however, make allowances for not reasonably having access to the required expertise and exploring ideas under business-specific cost, feature constraints.
An appropriately skilled individual is one whose qualifications and/or experience enable him or her to operate competently within a particular field . Such a person could be reasonably expected to produce a functional solution to a problem if such a solution exists within the constraints imposed upon the solution.
The skills expected for a company’s developers are those commonly found within the context of a company’s competitive business environment, and appropriate to the work being undertaken.
The three criteria for eligibility are to be applied with reference to the circumstances of the organization that executes the project. The judgement as to what knowledge of solutions a company should have or how far a company should search for solutions is to be assessed within the context of what it is reasonable to expect of a company conducting the project in a similar business environment.
If a third party executes a project on behalf of a claimant, the applicable business environment against which eligibility will be evaluated is that of the third party. Nevertheless, a claimant should not be denied eligibility simply because third parties exist for whom the same project would be standard practice, .if the claimant did not have reasonable access to that expertise. As noted, the meaning of “commonly available” has to be sensitive to the business’ environment and hence what can be expected of the tax payer’s developer’s project employees. All information technology workers are expected to have knowledge of the commonly available evolving tools of their trade. Workers are expected to make reasonable efforts to learn of new tools that might be applicable to the task at hand, but can be excused for failure to discover a relevant tool not commonly available in the public domain.
Simply learning to solve the problems that are commonly encountered during the first time use of a commonly available tool which happens to be new to the claimant’s business environment does not on its own involve the resolution of a Technological Uncertainties and hence produce a Technological Advancement. In the absence of any other fundamental technological problems, this is simple on-the-job learning.
The redevelopment of a solution which was generally available will usually fail the tests of both Uncertainty and Advancement. When making a claim based upon such a project, the onus will be on the claimant to show that (a) he was in fact unaware of the existing solution, and that (b) he made reasonable efforts to search for available solutions before embarking upon his project. Hint: Often it is a company’s ability to show how he normally searches for generally available solutions or that he did search for them or that he has established make/buy assessment practices that provides useful evidence that a “generally available” solution was not available to him in his business environment.
The business environment in which the software is developed or is to be used can give rise to technological challenges and hence Technological Uncertainties, but business constraints per se are not of themselves Technological Uncertainties.
For example, one claimant may choose for business reasons (e.g. time to market, a perceived need to differentiate himself from a competitor’s product) to attempt technical solutions involving Technological Uncertainty which another claimant might choose to avoid. A small business may try to minimize the development costs of a software system by taking some shortcuts that increase his risks. A larger firm might not take these same shortcuts because of the increased commercial risks. In this scenario, the claimant may be able to provide evidence that the shortcut was the source of a technological challenge and hence of a Technological Uncertainty and hence he sought an advancement.
For example, acceptable evidence might be advanced by showing that component hardware or software chosen because of cost considerations were less capable than those required for the system’s certain success. The resolution of the resulting Uncertainties, if done experimentally, could lead to an Advancement and thus to project eligibility.
- For each nugget, prove Technological Advancement by demonstrating:
a) A New Construct, Architecture or Technique A key here is that a technique equally encompasses do’s and dont’s. Also note that it’s not necessary for the advancement to have been incorporated into the ultimate solution; that the field of knowledge in this realm was advanced is sufficient. b) Peer Review & Relevancy Is the material presentation worthy in that an audience of your peers would find the material compelling? c) Evolution How does it compare with earlier solutions and what constraints have been overcome? d) Form/Function vs. Approach? How widely applicable are your ideas?
Simply claiming to have developed the first or best software suite for a given purpose does not in itself prove that the taxpayer has made a technological advancement.
A new and unique software suite can be built using only well known combinations of constructs, tools and methods without technological advancement. This is analogous to designing and building a unique and complex office building without making any advancements in the field of civil engineering.
Note that an advancement in technology can rarely be described by listing software functions and features at an “end-user” level. Advances are typically made through innovation in software architectures, designs, algorithms, techniques or constructs.
Update #1: Yes, there are certainly eligible projects that don’t fit this mould – be sure to read the guidance carefully. The intention here is to provide a checklist to validate the most common form of eligibility encountered in day-to-day IT. We are trained to avoid risk and to maximize leverage in helping businesses make the most of established tools, processes – this is an inherently different mindset when compared to traditional software vendors, OEMs and ISVs. For instance, in reviewing the section on “Eligibility of work to improve the process of Software Development,” you will find 2 examples that don’t fit the pattern: in both cases, the claimant found no commercially available tools and identified significant obstacles in developing the concept. In such cases, Technological Uncertainty (TU) can be defined up-front, without the element of surprise or risk. In practise, this is difficult to prove for an IT consultant working under billable hours.
 – SR&ED and IRAP Primer
 – Guidance on Eligibility of Software Projects for the SR&ED Tax Credits and Developing and Documenting Claims
 – Revised T661 SR&ED Expenditures Claim Form