Tracking SR&ED hours from your git history

If you're a Canadian company doing experimental development, you're leaving money on the table if you're not claiming SR&ED. The Scientific Research and Experimental Development tax credit is one of the most generous R&D incentives in the world — but claiming it requires documenting which work qualifies, how many hours were spent, and what technological uncertainties were being addressed.

Most teams reconstruct this from memory at year-end. They sit down with a spreadsheet, try to remember which sprints involved experimentation versus routine development, estimate hours, and hope the CRA doesn't ask too many questions. The documentation is thin because nobody was tracking it as they went.

The git history already has the data

Every commit is a timestamped record of work. The commit message describes what was done. The diff shows what changed. The frequency and timing show how many hours were spent. The question is whether each commit represents qualifying experimental development or routine engineering.

The /commit-ledger skill scores every commit in every repo against SR&ED qualification criteria: was there technological uncertainty? Was a systematic investigation conducted? Was there an advance in technology or scientific knowledge? Each commit gets a qualification score, an estimated hour count, and a categorization (qualifying, partially qualifying, or routine).

What the output looks like

Two deliverables:

The CSV ledger — Every commit across all scanned repos, with columns for: date, repo, author, commit hash, message, qualification score (0–100), estimated hours, category (qualifying/partial/routine), and the specific SR&ED criterion it addresses. This is the spreadsheet your accountant needs. Sort by qualification score, filter to qualifying, sum the hours. That's your claim basis.

The summary report — Aggregate statistics: total commits scanned, qualifying percentage, estimated qualifying hours, top qualifying repos, top qualifying authors, and the distribution of work across SR&ED criteria. This is the document that supports the claim narrative.

How scoring works

Not every commit is experimental. Bug fixes that follow a known pattern are routine. But a commit that implements a novel algorithm to solve a problem where the solution wasn't known in advance — that's qualifying. The scorer evaluates:

Technological uncertainty — Was the outcome uncertain when the work started? Did the developer know the approach would work, or were they investigating? Commits with words like "attempt," "experiment," "try," "prototype," "investigate" score higher. Commits with "fix," "update," "bump" score lower.

Systematic investigation — Was the work methodical? A series of commits exploring different approaches to the same problem scores higher than a single commit that happens to work. The scorer looks at commit sequences, not just individual commits.

Technological advance — Did the work produce knowledge or capability that didn't exist before? Integration of an existing library is routine. Building a custom solution because the existing library couldn't handle the requirement is potentially qualifying.

The scoring is conservative. It's better to under-claim and be defensible than to over-claim and trigger an audit. Every qualifying score comes with a rationale that can be included in the claim documentation.

When to run it

Quarterly. Don't wait for year-end. Run the ledger every quarter so the data is fresh and the commit messages are still meaningful in context.

Before filing a SR&ED claim. The CSV is the evidence. The summary is the narrative. Together they're the foundation of the claim.

When onboarding a new accountant or SR&ED consultant. Hand them the ledger. It's more specific than "we did some R&D last year."

Skip it if your work is primarily integration, configuration, or routine development with no technological uncertainty. The ledger will correctly score most commits as routine, and the output won't be useful.

---

Resources

Skill reference: /commit-ledger — trigger phrases, output format, scoring criteria.

Related reading:

• 03. Documenting projects that don't document themselves — the doc suite provides project context that enriches SR&ED narratives
• 07. How much does your infrastructure actually cost at scale? — LOC/complexity costing complements SR&ED valuation

Download: Full toolkit (252KB) — all 16 commands, all 11 skills, installs in 30 seconds.

---

Part of the Claude Skills Library.