Using Jira & GitHub for SR&ED Documentation

Software teams already generate most of the evidence CRA needs for an SR&ED claim — it’s sitting in your issue tracker and Git history. Here is how to organize it.

Why development tools are the best source of SR&ED evidence

CRA requires contemporaneous records — documents created at the time of the work, not reconstructed from memory months later. Your Jira board and Git repository are exactly that. Every commit, every issue, every sprint retrospective is timestamped evidence of systematic investigation. Most software teams underestimate how much SR&ED-eligible evidence they already have.

The challenge is not creating new evidence. The challenge is organizing existing records to demonstrate technological uncertainty and systematic investigation. Tools like Jira and GitHub make that straightforward — once you know what CRA is looking for.

Configuring Jira for SR&ED claim support

You do not need a separate Jira project for SR&ED. The most practical approach is labelling or tagging tickets that involve genuine technical uncertainty. At year-end, filter by that label to get the set of eligible work.

• Create an “SR&ED” label or issue type for tickets involving technical uncertainty
• Write ticket descriptions that state the technical problem, the hypothesis, and what was tried
• Use Jira’s time-tracking field to log hours on SR&ED-labelled tickets separately
• Record sprint retrospective notes: what was tried, what failed, what was changed and why
• Link commits to tickets so the code history is traceable to the documented technical work

Using GitHub and Git history for SR&ED evidence

Git commit history is naturally contemporaneous, timestamped, and attributable to specific developers. For SR&ED purposes, meaningful commit messages that explain the technical change — not just what changed, but why — are the most valuable. Pull request review discussions often show the clearest evidence of systematic investigation.

• Commit messages: describe the technical problem, not just the code change (“Test alternative normalization to resolve outlier sensitivity”, not “fix bug”)
• Branch names: use descriptive names like “experiment/embedding-model-comparison”
• Pull request descriptions: explain what was tried, what the benchmark showed, why the approach was chosen
• Issues and milestones: link work to the technical goal being investigated
• GitHub Actions and CI logs: show testing regimes and iteration cycles

What to export before year-end

Before your fiscal year closes, export and archive the following from your development tools:

• Jira: all SR&ED-labelled issues with descriptions, time logs, and sprint assignments
• GitHub: commit log for SR&ED-related repositories (filtered by date range)
• GitHub: pull request list with review comments for SR&ED work
• Any architectural decision records (ADRs) or design documents
• Benchmark results, performance test outputs, and failure analysis reports

These exports go into your evidence index — not submitted to CRA, but available immediately if a CRA review is initiated. See the year-end preparation guide for the full checklist.

Combining dev tools with time-tracking records

CRA requires financial evidence showing what portion of each employee’s time was spent on SR&ED. Jira time-tracking is the cleanest source. If your team doesn’t track time in Jira, supplement with Harvest, Toggl, or similar exports. The standard is that CRA can trace from a dollar amount in your financial records to a specific employee, to specific SR&ED work, and to the contemporaneous records documenting that work.

For software companies using SR&ED year over year, establishing this discipline in your engineering workflow is the single highest-value operational change. SREDY.IO guides you through structuring this evidence into a complete claim package.