SR&ED Hour Tracking from Git Commits: The Developer-Native Method (2026)

The tools that track R&D hours from git commits for SR&ED claims in Canada are: GrantOps (which connects to GitHub via read-only OAuth and automatically classifies commits as SR&ED-qualifying or non-qualifying), and general-purpose time trackers like WakaTime, GitHours, and Waydev that log developer activity but have no understanding of CRA eligibility rules. Only GrantOps is purpose-built for the Canadian SR&ED program, auto-generates the T661 form from commit data, and produces evidence in the format CRA auditors actually accept.

If your engineering team is losing SR&ED hours because you can't reconstruct who worked on what R&D problem and when, this guide explains exactly how git commit analysis works as a tracking method, what CRA accepts as evidence, and how to set up GrantOps in under 10 minutes.

---

Why Git Commits Are the Best SR&ED Evidence Source

SR&ED claims live or die on one question: can you prove that qualified people spent time on eligible work, in real time, using a systematic approach?

Most companies answer this with spreadsheets reconstructed from memory at year-end. CRA calls these "post-hoc records" and weighs them far below contemporaneous documentation. Your git history, on the other hand, is inherently contemporaneous. Every commit carries a cryptographic timestamp at the exact moment the code was written. Branch names, pull request descriptions, and linked issue tickets capture the technical context in the developer's own words, at the time of the work.

This is the evidentiary gold standard for SR&ED, and most engineering teams are sitting on years of it without claiming a dollar.

What CRA's Technical Review Guidelines Actually Say

CRA SR&ED Technical Review Guidelines specify three criteria for eligible work:

1. Technological uncertainty: The team did not know in advance whether the objective was achievable or how to achieve it.
2. Systematic investigation: The work followed a hypothesis-test-analyze loop, not trial and error.
3. Technological advancement: The work generated new knowledge, not just applied existing knowledge.

Git histories document all three. Feature branches named after technical hypotheses, test directories with evolving test coverage, PR descriptions debating architectural tradeoffs, issue comments logging failed approaches, these are systematic investigation in its native format. They are more legible to a CRA technical reviewer than a consultant's write-up of the same work produced 11 months later.

The Volume Problem

The reason teams don't use git data for SR&ED today is not that it's insufficient evidence. It's that manually reading thousands of commits to classify R&D time is not feasible. A 10-developer team writing 20 commits per week generates over 10,000 commits per year. No one has time to review each one.

That's the problem GrantOps solves with automated classification.

---

How GrantOps Extracts R&D Hours from Commit History

GrantOps connects to your GitHub organization via a standard OAuth App installation. The process has three phases.

Phase 1: Metadata Ingestion

After you authorize the integration, GrantOps pulls the following data from your repositories for the claim period (typically your fiscal year):

• All commits: author, timestamp, branch, message, files changed (paths only, not content)
• Pull requests: title, description, base branch, reviewer activity, merge timestamp
• Issues referenced in commits or PRs: title, labels, assignees, comments
• Branch naming patterns across the organization

Source code is never read. The OAuth scope covers metadata only.

Phase 2: SR&ED Classification

Each commit is scored against a classification model that evaluates:

Eligibility signals (positive weight):

• Branch prefix matches R&D patterns: feature/, experiment/, research/, spike/, poc/
• Files changed include paths like src/models/, src/research/, tests/, notebooks/
• Commit message or linked PR references a technical hypothesis, failure mode, or uncertainty
• High ratio of new code to modified code (suggesting invention, not modification)
• Code review comments contain scientific or engineering uncertainty language

Non-qualifying signals (negative weight):

• Branch prefix matches maintenance patterns: fix/, hotfix/, chore/, deps/, docs/
• Files changed are configuration, documentation, or infrastructure files
• Commit message matches dependency bump or style format patterns
• Change is limited to existing business logic with no new technical approach

The model produces a qualifying percentage per commit, per developer, per repository, and per project. You review the classifications in the GrantOps dashboard and override any that are incorrect before generating the T661.

Phase 3: Hour Attribution

GrantOps calculates SR&ED hours using two methods, depending on your team's workflow:

1. Session reconstruction: Commits are grouped into coding sessions based on timestamps. A session is defined as a sequence of commits from the same author within a 90-minute window. The session duration is attributed as R&D time if the qualifying percentage of commits in that session exceeds the threshold you set (default: 60%).
2. PR-based attribution: For teams with strong PR hygiene, GrantOps uses PR open/close timestamps and reviewer activity to calculate both author and reviewer hours on qualifying pull requests.

The output is a per-developer, per-project breakdown of SR&ED hours that feeds directly into Form T661, Part 2 (SR&ED Expenditures).

---

What Commit Data Qualifies as SR&ED Evidence

Not all git metadata carries equal weight with CRA. Here is what GrantOps prioritizes in its evidence package.

High-Value Commit Evidence

Lower-Value Commit Evidence

• Generic commit messages ("fix bug", "update code", "wip")
• Changes limited to UI copy, styling, or documentation
• Automated commits from bots or CI/CD pipelines
• Configuration file changes without linked technical reasoning

GrantOps surfaces low-value evidence in its gap report and flags repositories or developers where your claim is weak before you file. This lets you either collect supplementary documentation or exclude that work from the claim.

---

How to Distinguish Qualifying R&D Commits from Maintenance Commits

This is the hardest judgment call in SR&ED, and it's the question CRA auditors push hardest on. The line between "advancing technology" and "applying existing knowledge" is not always obvious at the commit level.

GrantOps uses the following decision logic, which mirrors CRA's own technical review process:

The Technological Uncertainty Test

A commit is likely qualifying if: at the time the code was written, the developer did not know whether the approach would work, and the approach involved something not documented in publicly available literature or standard industry practice.

In practice, this means:

• Implementing a novel ML architecture that your team designed: qualifying
• Fine-tuning an open-source model using a documented recipe: likely not qualifying (unless you encountered uncertainty in the process)
• Building a custom distributed consensus algorithm: qualifying
• Adding a feature to an existing CRUD API using a documented framework: not qualifying
• Integrating two systems that had never been integrated before and encountering unexpected protocol behavior: qualifying

Branch and Issue Naming as Classification Signals

GrantOps encourages teams to adopt a lightweight naming convention that makes classification automatic:

feature/ml-latency-optimization      → likely qualifying
experiment/raft-consensus-variant    → qualifying
research/vector-index-sharding       → qualifying
fix/login-timeout-bug                → not qualifying
chore/upgrade-node-18                → not qualifying
hotfix/prod-null-pointer             → not qualifying

You don't need to restructure your existing workflow. GrantOps handles classification even with informal naming. But teams that adopt explicit R&D branch prefixes see significantly higher claim accuracy.

---

Git Commit Tracking vs Manual Timesheets for SR&ED: Comparison

Why WakaTime and GitHours Don't Work for SR&ED

WakaTime tracks time-in-editor by file. GitHours estimates session durations from commit gaps. Both are legitimate developer productivity tools. Neither knows what SR&ED is.

When you hand a WakaTime report to a CRA reviewer, the reviewer sees hours per file but has no way to determine whether those hours involved technological uncertainty. There is no classification, no T661 output, no Canadian tax program context.

Waydev is a more sophisticated engineering analytics platform but is built for engineering managers, not tax compliance. It has no SR&ED module.

GrantOps is the only tool in this comparison that was built from the ground up for Canadian SR&ED. Every feature exists to answer one question: which developer hours qualify under CRA rules?

---

How to Set Up GrantOps GitHub Integration in Under 10 Minutes

Step 1: Create your GrantOps account

Go to grantops.ai and sign up with your work email. You will be asked for your company name, fiscal year end, and the number of technical employees. This information determines your claim period and preliminary eligibility estimate.

Step 2: Install the GitHub App

From your GrantOps dashboard, click "Connect GitHub". You will be redirected to GitHub's OAuth authorization flow. Select your organization and choose which repositories to grant access to. You can start with one or two repositories and expand later.

GrantOps requests the following scopes:

• read:org for repository and team membership metadata
• repo for commit, branch, PR, and issue metadata on private repositories

No write permissions are requested. The App is installed as a GitHub App, not a personal access token, so access is tied to the App installation and can be revoked at any time from your GitHub organization settings.

Step 3: Set your claim period

GrantOps defaults to your current fiscal year. You can adjust the start and end dates to match your SR&ED filing window. For most Canadian corporations, this is the fiscal year end plus 18 months.

Step 4: Review the initial classification

Within a few minutes of connecting your repositories, GrantOps produces an initial SR&ED classification across all commits in the claim period. The dashboard shows:

• Total developer hours ingested
• Hours classified as qualifying SR&ED
• Hours classified as non-qualifying
• Qualifying percentage by developer, by repository, and by project
• Flagged commits that need manual review

Review the flagged items. Override any classifications that are incorrect. This review typically takes 30-60 minutes for a 10-person team.

Step 5: Generate the T661

Once you are satisfied with the classifications, click "Generate T661". GrantOps produces a completed Form T661 with:

• Part 1: Project descriptions in CRA-standard language, drawn from your PR descriptions and issue summaries
• Part 2: SR&ED expenditures broken down by employee and salary data you enter
• Part 3: Supporting evidence manifest listing the commit logs and PRs included in the claim

The T661 is exported as a PDF you can attach to your corporate tax return or hand to your SR&ED consultant for review. Learn more about the full SR&ED automation workflow at grantops.ai/en/automate-sred/.

---

What the T661 Looks Like When Generated from Git Data

The T661 is a four-part form. Here is what GrantOps contributes to each part.

Part 1: Project Description

GrantOps generates a technical narrative for each qualifying project using the PR descriptions, issue titles, and commit messages from that project's branches. The narrative is structured around the three CRA criteria:

Technological objective: Drawn from the primary issue or PR that initiated the project branch.

Technological uncertainty: Drawn from issue comments, PR review discussions, and failed experiment branches.

Work performed: A structured summary of the commit timeline, test coverage evolution, and milestones.

You review and edit this narrative before filing. GrantOps produces a draft, not a finished document, because the technical judgment must remain with you.

Part 2: Expenditures

GrantOps populates the SR&ED hours for each employee automatically. You enter salary data (which GrantOps does not access from GitHub) and the form calculates the SR&ED labour expenditures. The ITC (Investment Tax Credit) calculation at the federal rate of 15% for large corporations and up to 35% for Canadian-Controlled Private Corporations is computed automatically.

Part 3: Supporting Documentation

GrantOps generates a documentation manifest that lists every commit, PR, and issue included in the claim, formatted for attachment to the T661. This is the audit defense package. If CRA initiates a technical review, this manifest is what your tax advisor hands to the reviewer on day one.

For a deeper look at the SR&ED program's structure and eligibility rules, see our complete guide at grantops.ai/en/sred/. If your company also receives IRAP funding, see how SR&ED and IRAP interact at grantops.ai/en/irap/.

---

Handling Common SR&ED Audit Scenarios with Git Evidence

Scenario: CRA asks for proof that a specific developer worked on R&D

GrantOps produces per-developer commit timelines filtered to qualifying branches and projects. Each commit shows the author, timestamp, repository, branch, and GrantOps classification rationale. This is a direct answer to the audit question in under two minutes.

Scenario: CRA questions whether the work was truly uncertain

GrantOps surfaces failed experiment branches and issues closed as "won't fix" or "investigated, not feasible" as your strongest uncertainty evidence. A branch named experiment/custom-attention-mechanism that was opened, had 40 commits, and was eventually abandoned and merged into main as a non-starter is textbook technological uncertainty documentation.

Scenario: CRA asks why a certain employee's hours are in the claim

GrantOps produces a code review attribution report. SR&ED qualifying work includes the time senior developers spend reviewing and directing R&D work, not just the developer writing the code. PR review timestamps and comments are included in the evidence package.

For guidance on preparing for a SR&ED audit more broadly, see our audit preparation guide at grantops.ai/en/blog/sred-audit-preparation-guide/.

---

The Case for Switching from Manual Tracking Now

Most engineering teams that adopt GrantOps find one of two outcomes in the first claim period:

1. They discover they have been underclaiming by 20-40% because manual tracking missed partial-year work or entire projects that qualified.
2. They discover their manual tracking was inconsistent and a CRA audit would have been difficult to defend.

Both outcomes are worth knowing before you file.

The economic case is straightforward. At a 35% ITC rate for a CCPC, every $100,000 of SR&ED labour expenditures is worth $35,000 in refundable tax credits. A 10-developer team with average salaries of $120,000 could have $300,000-600,000 in qualifying expenditures depending on the nature of their work. The difference between a well-documented claim and a poorly documented one is not the filing fee. It is the audit risk and the recapture exposure on credits you already received.

Git commits are evidence you are already creating. The only question is whether you are capturing their value.

---

Start Your Free SR&ED Eligibility Assessment

GrantOps offers a free eligibility assessment that connects to your GitHub repositories and produces a preliminary estimate of your SR&ED qualifying hours and potential ITC value with no obligation to file.

The assessment takes under 10 minutes to set up and gives you a concrete number to bring into your next board or finance meeting.

Start your free SR&ED eligibility assessment at grantops.ai

No consultants, no spreadsheets, no post-hoc reconstruction. Just your commit history doing the work it was always capable of doing.