4 Steps to Better SR&ED Documentation in Jira
Documentation of SR&ED is single most important issue we face in the defendability of SR&ED claims. If you currently use—or have thought about using—Jira, then you’ve come to the right place, otherwise, consider other articles in our series, here:
- SR&ED Documentation Best Practices
- 3 Steps to Better SR&ED Documentation in Trello
- 3 Steps to Better SR&ED Documentation in Git
At ENTAX, we often see clients using Jira as the basis for their R&D efforts. Jira offers a wide range of features and customizations. At a glance this should improve your ability to track and justify SR&ED work, but this power and flexibility can itself present challenges. Our goal here is to provide you with a small number of concrete, actionable steps to simplify the process of documenting work and reviewing progress when using Jira. We want to ensure that filing your SR&ED claim is as easy as possible, so we’ve compiled a few tips and tricks to make the most out of Jira with the least amount of overhead.
To comply with CRA policy requirements for making a SR&ED claim, you must prove that you applied a logical, systematic approach (NOT trial-and-error) to problem-solving in the course of experimental development. Be mindful of the fact that this program is all about incentivizing and rewarding activities with a risk of failure in an attempt to advance a science or technology field, rather than the outcome of the effort, therefore it is largely irrelevant whether or not you ultimately succeeded in that effort. In the eyes of the CRA, the closer your R&D processes align with the scientific method (question, hypothesis, test, analysis), the stronger your overall SR&ED claim.
In the spirit of the scientific method, which demands carefully maintained and updated records (for reproducibility of experiments, knowledge transfer), a strong SR&ED claim is backed up by documentation of a contemporaneous nature i.e. recorded at the time the work took place, NOT generated retroactively. Documentation that complies with SR&ED requirements should communicate who was involved in what work, when work was performed, how that work was carried out, and relate the work back to a science or technology objective, in order to explain why that work was necessary to overcome a scientific/technological uncertainty.
How does that impact my Jira?
If you primarily use Jira to track your project work, it will most likely be leveraged not only to corroborate the science/technology narrative articulated in the technical report abstract submitted alongside your SR&ED claim, but also to establish the material scope and extent of your claim (i.e. qualified expenditures). That means Jira issues should clearly communicate:
Who was involved (creator, reporter, and assignee fields)
What work was performed in an attempt to resolve said issue (summary and or description)
When the work was performed (creation, update, and resolution timestamps)
How the work was carried out (description and or comments)
Why the work contributes to the aspirational pursuit of some science/technology advancement (epics or other parent entities that group together logically related issues)
Continue reading below for our 4 Steps to Better SR&ED Documentation in JIRA...
Here are 4 concrete changes that will dramatically improve your ability to claim SR&ED using Jira as evidence:
1. Consistently fill in descriptor fields
When the auditor assigned to your SR&ED claim looks at the Jira export you’ve provided, they’ll be looking at a massive spreadsheet with all of the issues from your tax year and potentially hundreds of columns per issue. You might be tempted to back up your claim by adding all sorts of customizations and required data fields to every task, but this quickly becomes overwhelming and confusing. Extreme overhead can frustrate or confuse issue stakeholders, leading to inconsistent or patchy logging, and a patchy recording system is almost as bad as no system at all.
The easiest way to communicate what the technical nature of the work was and how it was carried out is to focus on filling out the (default) project, summary, and description fields in a consistent manner as the work progresses. If you choose to organize Jira into multiple projects, it helps tremendously during a SR&ED eligibility assessment as an auditor can then filter for eligible work at the project level. Summaries and task descriptions should be filled out with enough detail such that someone outside your company can easily tell what tasks are commensurate with the needs, and directly in support, of your SR&ED work per CRA guidelines.
In practice, the CRA requires claimants to demonstrate their knowledge of the program by being able to clearly distinguish and separate eligible work from ineligible work at sufficiently levels of granularity, as their expectation is that only a subset of activities within projects constitutes SR&ED. Therefore the information contained within these fields should enable an auditor to clearly distinguish between eligible and ineligible work at the task level. Beyond that, you may choose to create custom Jira labels (e.g. ‘SR&ED’ or ‘experimental’) and apply them to epics/issues for ease of filtering at the end of the tax year, as well as any other fields that may help a reviewer see what small or routine tasks were necessary parts of a SR&ED project.
Naming/labeling conventions, terms, acronyms, and insider jargon should all be standardized across Jira issues to enable an outsider to filter for, reference, and group logically related tasks. Otherwise, you risk rejection of eligible tasks simply because the language used to describe work was inconsistent with descriptors used in other qualified tasks. Likewise, consistency is key. If projects go by a different name every time they get referenced, tracking the work associated with a given claim becomes a nightmare.
2. Supplement your assignee fields
Wages make up the bulk of expenses in a typical SR&ED claim, meaning that evidence supporting your wage allocation is the most important kind of evidence. In order to ensure your SR&ED success, you need to show who was working on a given task, and when that work occured.
When Jira information is used to calculate and justify the qualified SR&ED expenditures (i.e. salaries and wages) claimed on a per-individual basis, one of the main drawbacks is an overall reduction in claimable expenditures, due to past reassignment of tasks that decreases the amount of eligible work you can associate to specific individuals. The root cause stems from Jira having only one Assignee field, and this field only retains the most recent assignee ID. Atlassian has done this purposefully, as it means one person is responsible for each piece of work at any given time, but this it makes it much more difficult to figure out how to apportion total time logged in a particular issue amongst all past and present assignees. This problem gets compounded by the fact that your experimental work probably get passed between assignees during its lifecycle (e.g. moving from design, to production, to validation), meaning that individuals who took ownership of those issues (eligible or not) at the initial stages of the lifecycle will be underrepresented in, or possibly absent from, the Jira database.
So how do you make sure that your Jira documentation matches the actual SR&ED work of your team? The most straightforward way is to create a large amount of individual sub-tasks (e.g. having design, production, and validation all be independent tasks), each with a single individual being responsible for them, and duplicating tasks should multiple people need to collaborate. Admittedly, this method results in a lot of clutter in terms of fields, but will ensure that the “assignee” field accurately identifies who did what.
Alternatively, you might consider adding a custom user-picked field for tracking personnel who have previously worked on a tasks, but who became unassigned for whatever reason, for multiple-assignee tracking with minimal overhead.
3. Track timelines better
When looking at Jira to validate claimed SR&ED expenditures, an auditor is looking to establish the extent of eligible work performed; in other words, how long it took to do the work. Since two Jira issues can take wildly different amounts of time (compare an issue to fix a typo with one to develop a new feature) it helps if you can account for that. Since SR&ED issues tend to take longer than routine ones, an accounting method which treats every issue as equal weight is probably leaving money on the table.
That is why we recommend leveraging the “time spent” fields to keep an accurate accounting of time spent on tasks. This can be done either at the epic or task level. Make sure that you don’t miss out on time spent planning work and all the other support activities as these are SRED eligible tasks as well; many companies only track hands-on development work in Jira, while neglecting to log the initial R&D, design and planning work that made implementation possible. Unless this work is explicitly recorded in Jira or elsewhere, it is disqualified by default by the CRA.
In lieu of explicit timekeeping, it is acceptable to use story points for labour allocation purposes. While the CRA mandates some form of time tracking, in practice they commonly recognize that story points are a good proxy for time/effort spent on tasks, so long as points are consistently applied to tasks throughout the project lifecycle.
You also have to consider project timelines. It’s perfectly fine to have a SR&ED project that spans multiple tax years, but you need to have a way to account for time spent on tasks which overlap your tax year end. A typical Jira issue will have timestamps representing when it was created, when it was updated, and when it was resolved, but these often differ from the time when work was actually done. If you tend to outline a Jira project well in advance of its start date, the ‘created’ date may be many months removed from the time when hands-on work actually starts, which has the effect of inflating actual time spent on work. Likewise, if a task spent a lot of time in review its ‘resolution’ and ‘updated’ dates may be far too late. That can be a problem during an extent assessment, when your stated project timelines and supporting documents like Gantt Charts don’t line up with your issue tracker. This problem can be resolved by tightening your backlog, or by making use of more subtasks, since smaller pieces of work tend to have a much shorter lifetime, which will tighten that window.
However, for more explicit timekeeping solutions, Jira offers many Add-ons for timekeeping such as Tempo Timesheets and many other Apps available on the Atlassian Marketplace.
4. Take advantage of SREDTRAK
Because we've seen all these issues before, we developed a dedicated SR&ED tracking Add On for Jira. SREDtrak creates a complete, end-to-end documentation trail of your SR&ED work in JIRA to maximize claim refunds. Made with the Atlassian Connect add-on framework, it simply integrates into your Jira Cloud instance.
Contact us to learn more about how we can help your software company claim and optimize SR&ED. With our deep understanding of SR&ED in Agile Software environments and with market-leading software tools like SREDtrak for JIRA and SREDbot for Slack, ENTAX can help you reach your SR&ED objectives.
ENTAX is a Research & Development advisory firm for technology companies. We specialize in Scientific Research and Experimental Development (SR&ED) tax credits and other Government incentives across all industries for companies large and small. We provide a full scope of SR&ED tax credit and incentive advisory services and provide the highest quality service. Our goal is to build long term, positive client relationships and with our Government agency partners.