# How to Document SR&ED Evidence from Pull Requests (GitHub, GitLab, Bitbucket)

Source: https://grantops.ai/en/blog/sred-evidence-documentation-pull-requests/
Last updated: 2026-06-03

PR descriptions, code review threads, and merge notes are CRA-accepted forms of contemporaneous SR&ED documentation. [GrantOps](https://grantops.ai) automatically collects this data from GitHub, GitLab, and Bitbucket via read-only OAuth and uses it to generate T661 technical narratives, turning the evidence that already lives in your repositories into a CRA-ready SR&ED claim.

If your engineering team submits pull requests, you are already generating SR&ED evidence. The question is whether that evidence is structured well enough to survive a CRA review, and whether you have a system to collect and organize it before the fiscal year closes.

This guide covers exactly that: what PR data CRA accepts, how to write PRs that double as SR&ED documentation, the specific metadata GrantOps extracts, and a copyable PR template your team can drop into `.github/PULL_REQUEST_TEMPLATE.md` today.

## Why Pull Requests Are the Strongest SR&ED Evidence Source

CRA evaluates SR&ED claims on the quality of technical evidence. The stronger the contemporaneous record, the more defensible the claim. "Contemporaneous" is the operative word: CRA wants documentation created *at the time of the R&D work*, not reconstructed months later when the claim is being prepared.

Pull requests satisfy every contemporaneous documentation requirement that CRA looks for:

**Timestamped.** Every PR has an immutable creation timestamp and merge timestamp recorded by the platform. This establishes when the work occurred and ties it to a specific fiscal period without any manual effort.

**Author-attributed.** Every PR is attributed to a named developer with a platform identity. Review comments are attributed to specific reviewers. This directly supports the personnel cost calculations in Form T661, Part 2.

**Peer-reviewed.** Code review threads contain technical back-and-forth between developers discussing *why* an approach was chosen, what alternatives were rejected, and what the outcome revealed. This peer review layer is exactly the kind of technical dialogue that demonstrates a systematic investigation was conducted.

**Linked to a specific technical problem.** A well-written PR description names a problem, describes an approach, and documents what was learned. This maps directly to the three-part SR&ED eligibility test: technological uncertainty, systematic investigation, and technological advancement.

**Audit-trail complete.** Unlike timesheets or lab notebooks, PRs cannot be retroactively altered without leaving a visible edit history. This makes them one of the most tamper-evident forms of SR&ED documentation available.

In practice, CRA reviewers who are comfortable with software R&D claims will accept a strong PR record as the backbone of technical evidence. The challenge for most companies is that PRs are rarely *written* with SR&ED in mind, which means useful evidence is often buried in vague titles like "fix rendering issue" or "refactor auth module."

## What PR Data CRA Accepts as SR&ED Evidence

Not all PR metadata carries equal weight for SR&ED purposes. Here is the specific data that GrantOps collects and how each field maps to CRA's documentation requirements:

**PR title.** Used to identify the work unit and associate it with a project or workstream. Titles that name a specific technical problem (rather than a feature or ticket number) are more useful.

**PR description (body).** The highest-value field. A description that documents the technical problem, the approach taken, what was tried first, and what the outcome revealed can serve as a standalone piece of contemporaneous evidence for that unit of work.

**Code review comments.** Technical discussion in review threads frequently contains the most explicit articulation of technological uncertainty: "we tried X and it didn't work because..." or "the challenge here is that the library doesn't support Y, so we had to..." These comments are extracted and grouped by PR.

**Linked issues.** GrantOps follows issue links in PR descriptions and extracts the issue title, description, and comment thread. This is valuable when the technical problem definition lives in the issue rather than the PR itself.

**Merge date and base branch.** Establishes when work was completed and merged into the main codebase, confirming the work falls within the claim period.

**Author and reviewers.** Used to attribute hours and support personnel cost calculations.

**Commit count and file scope.** Used as a proxy signal for the scale and complexity of the work unit. Not submitted to CRA directly, but used internally by GrantOps to weight the significance of a PR when generating narratives.

**CI/CD result links.** Where available, links to failed and passed test runs referenced in PR comments provide additional evidence of iterative experimentation.

## How to Write PR Descriptions That Double as SR&ED Evidence

Most developers write PR descriptions for their teammates, not for CRA. The goal is to explain what the code does and why the reviewer should approve it. SR&ED evidence has a slightly different purpose: it needs to show that the work involved technological uncertainty and a systematic attempt to resolve it.

The good news is that these goals overlap more than they diverge. A PR description that honestly explains *why* a problem was hard and what the team tried is both useful for reviewers and useful for SR&ED.

Here are five patterns that consistently produce SR&ED-ready PR descriptions, with examples contrasting weak and strong versions.

### Pattern 1: Name the technological uncertainty explicitly

**Weak:** "Implement new caching layer for API responses."

**Strong:** "Implement caching layer for API responses. The core challenge was that our multi-region deployment means cache invalidation signals can arrive out of order, and no existing library we evaluated handles this deterministically. We built a custom vector clock implementation to resolve conflicts."

The weak version describes a feature. The strong version names a specific technical problem (non-deterministic cache invalidation in multi-region deployments) and explains why off-the-shelf solutions did not work.

### Pattern 2: Document what you tried before this approach

**Weak:** "Switch from polling to websockets for real-time updates."

**Strong:** "Switch from polling to websockets for real-time updates. We first attempted long-polling at 500ms intervals, but this produced unacceptable server load at our current scale (approx. 8,000 concurrent sessions). We then evaluated SSE, but Safari's lack of support for the EventSource reconnection API made that impractical. This PR implements websockets with a custom reconnection manager that handles the Safari edge case."

CRA looks for evidence that a systematic investigation was conducted, which means showing that alternatives were evaluated and rejected for technical (not business) reasons.

### Pattern 3: Record the outcome, including failures

**Weak:** "Optimize database query performance."

**Strong:** "Optimize database query performance for the invoice aggregation endpoint. Hypothesis: adding a composite index on (tenant_id, created_at, status) would reduce query time below 200ms at p99. Result: composite index reduced median query time from 1,200ms to 180ms, but p99 remains at 890ms due to hot partition behavior for large tenants. Partial success; separate follow-up PR will address partition strategy."

Recording partial or failed outcomes is valuable for SR&ED because it demonstrates that the outcome was not known in advance, which is one of CRA's core eligibility criteria.

### Pattern 4: Reference the technical constraint

**Weak:** "Add support for large file uploads."

**Strong:** "Add support for large file uploads. Cloudflare Workers has a 128MB request body limit and a 30-second CPU time limit per invocation, which makes streaming large files non-trivial. This PR implements a presigned S3 multipart upload flow that bypasses the Worker for the file bytes while keeping auth validation in the Worker."

Naming an external technical constraint (platform limits, library behavior, protocol restrictions) establishes that the uncertainty came from the technology environment, not from a lack of knowledge on the developer's part.

### Pattern 5: Link to the issue that defines the technical problem

If the technical problem definition is well-documented in a Jira ticket, Linear issue, or GitHub issue, reference it explicitly in the PR description. GrantOps follows these links automatically during ingestion.

**Example:** "Closes #4821. See issue for full description of the serialization race condition and the five approaches we ruled out before this implementation."

This keeps the PR description concise while ensuring GrantOps can pull the full technical context from the linked issue.

## How GrantOps Automatically Extracts PR Evidence

GrantOps eliminates the manual collection step entirely. Here is how the pipeline works from setup to T661 export:

**Step 1: GitHub (or GitLab, Bitbucket) OAuth connection.** You authorize GrantOps with read-only OAuth. No write access is granted. You select which repositories are in scope for the current fiscal year's SR&ED claim.

**Step 2: PR ingestion.** GrantOps pulls all PRs merged within the claim period across the selected repositories. For each PR, it extracts the fields listed above: title, body, review comments, linked issue content, author, reviewers, timestamps, and CI result references where present.

**Step 3: Eligibility classification.** Each PR is classified against SR&ED eligibility criteria. GrantOps flags PRs that show technological uncertainty signals (novel approaches, documented failures, technical constraint references) and filters out PRs that are clearly routine (dependency updates, configuration changes, UI copy edits). You review and adjust these classifications before the claim is finalized.

**Step 4: Project grouping.** PRs are grouped into SR&ED projects based on repository, branch naming conventions, issue labels, and semantic similarity of the technical problems described. You name and describe each project during review.

**Step 5: T661 narrative generation.** For each SR&ED project, GrantOps generates a technical narrative in T661 format covering: the technological uncertainty faced, the work performed (systematic investigation), and the technological advancement achieved. The narrative is grounded in the specific PR and issue evidence collected, with citations.

**Step 6: Review and export.** You review each narrative, make edits, approve, and export the completed T661 package. The package includes the narratives, the supporting evidence log (PR citations), and the personnel cost schedule. Your accountant files the T661 with your T2 corporate return.

The full process from OAuth connection to exported T661 draft takes most companies two to four hours of total human review time, compared to the 40-60 hours typically spent on manual claim preparation. See [how GrantOps automates SR&ED claims](/en/automate-sred/) for more detail on the full pipeline.

## What NOT to Include in PRs for SR&ED

Not all development work qualifies for SR&ED, and classifying ineligible work as eligible is the fastest way to trigger a CRA review. GrantOps flags potentially ineligible PRs automatically, but it helps to understand the classification logic so your team can self-sort from the start.

**Routine maintenance.** Dependency version bumps, security patches for known CVEs, OS or runtime upgrades, and infrastructure configuration changes are routine maintenance. They involve no technological uncertainty because the outcome is known and the approach is standard practice.

**Bug fixes (most of them).** A bug fix is SR&ED-eligible only if the bug was caused by a previously unknown behavior of a technology, and resolving it required developing new technical knowledge. Most bug fixes involve applying known debugging techniques to find a known class of problem, which is routine. The exception: if a bug reveals a fundamental gap in the technology (e.g., a race condition in a distributed system that requires designing a new synchronization mechanism), the *investigation and solution design* portion may be eligible.

**UI and UX changes.** Visual design changes, copy updates, layout adjustments, and accessibility improvements are not SR&ED-eligible unless they required solving a novel rendering or interaction problem at the technical level (e.g., building a custom layout algorithm because CSS grid cannot handle the required constraint).

**Feature work with known solutions.** Implementing a CRUD interface, adding a third-party API integration using the provider's SDK, or building a report from documented data is not SR&ED-eligible. The work may be complex and valuable, but if the implementation path was known at the start, there is no technological uncertainty.

The practical test: if a competent developer could look at the problem and say "I know exactly how to do this," it is not SR&ED-eligible. If a competent developer would say "I am not sure this is technically achievable, and I will need to experiment to find out," it likely is.

## PR Evidence vs Lab Notebooks vs Meeting Notes: What Does CRA Prefer?

CRA does not have a ranked preference list for evidence types. What it evaluates is: contemporaneity (was this created during the R&D work?), specificity (does it name the technical problem and approach?), and traceability (can you show who did what work and when?). Different evidence types score differently on these dimensions:

| Evidence Type | Contemporaneous | Specific | Traceable | Developer Burden | Automation Potential |
|---|---|---|---|---|---|
| Pull request descriptions | High (created during work) | Medium to high (depends on quality) | High (timestamped, attributed) | Low (fits existing workflow) | High |
| Code review comments | High | High (captures real-time technical debate) | High | None (created naturally) | High |
| Lab notebooks / R&D logs | High | High (if maintained well) | Medium | Very high | Low |
| Meeting notes | Medium (often written after) | Low to medium | Low (rarely attributed) | Medium | Low |
| Jira / Linear tickets | High | Medium (depends on ticket quality) | High | Low | High |
| Timesheets | High | Low (no technical content) | High | Medium | Medium |
| Email threads | Medium | Medium | Medium | Low | Low |

Pull requests and linked issue tickets consistently rank as the most practical evidence source for software companies because they are created as a natural byproduct of the development workflow, require no additional process to generate, and are fully automatable for ingestion and narrative generation. [GrantOps also ingests Jira and Linear ticket data](/en/automate-sred/) alongside PR evidence for the most complete possible evidence package.

## Setting Up a PR Template Your Whole Team Will Actually Use

The most common reason PR-based SR&ED evidence is weak is not that developers are avoiding documentation. It is that there is no default structure prompting the right information. A `.github/PULL_REQUEST_TEMPLATE.md` file solves this: every new PR in the repository is pre-populated with the template, and developers fill in what is relevant.

The template below is designed to be genuinely useful for code review (developers will fill it in for their teammates' benefit) while also capturing exactly the fields GrantOps needs for SR&ED evidence collection.

Copy this into `.github/PULL_REQUEST_TEMPLATE.md` in any repository:

```markdown
## What does this PR do?

<!-- One or two sentences describing the change. -->

## What technical problem is this solving?

<!-- Describe the technical challenge or uncertainty this addresses.
     What made this hard? What did you not know going in?
     If there was no technical uncertainty (routine change, dependency bump), write "Routine." -->

## What approaches did you try?

<!-- List alternatives you evaluated or attempts that did not work, and why.
     Example: "Tried X first, but it failed because Y. Tried Z, but the library does not support W."
     Skip if this is routine work. -->

## What is the outcome or learning?

<!-- What did you confirm, discover, or rule out?
     Include partial results and failures -- they are valuable context.
     Example: "Confirmed that approach A works at scale. Still unresolved: behavior under Z condition." -->

## References

<!-- Link to related issues, spike documents, or prior PRs. -->

---
<!-- SR&ED classification hint (optional, for GrantOps users):
     Does this PR involve technological uncertainty?
     [ ] Yes -- novel problem, outcome was not known in advance
     [ ] Partial -- some novel elements, some routine
     [ ] No -- routine change, known solution
-->
```

The SR&ED classification checkbox at the bottom is optional but useful: it prompts developers to self-classify, which makes GrantOps's automated classification more accurate and reduces your review time when preparing the claim.

For teams on GitLab, the equivalent file is `.gitlab/merge_request_templates/Default.md`. For Bitbucket, PR templates can be configured at the repository level via the Bitbucket UI.

## Getting Historical PR Evidence Before Your Fiscal Year Closes

If you are reading this mid-fiscal-year and your team has been submitting PRs without SR&ED documentation in mind, do not assume that evidence is lost. GrantOps ingests historical PR data from the beginning of a repository. PRs submitted months ago with detailed descriptions and review threads are still fully valid contemporaneous evidence because they were created at the time the work occurred.

What you cannot do retroactively is improve the quality of PR descriptions that were never written. A PR from eight months ago with the description "fix issue" and no review comments will not generate a useful T661 narrative, because the evidence is genuinely thin.

The practical approach for a mid-year course correction:

1. Connect GrantOps to your repositories now and run a historical ingestion. This gives you a baseline of what evidence you already have.
2. Review the eligibility classification. Identify which PRs GrantOps flagged as potentially eligible but with low evidence quality.
3. For high-value PRs with thin descriptions: if the developer who wrote the PR still remembers the technical context, have them add a retrospective comment to the PR (not edit the original description). A comment added now is still timestamped to today, but it supplements the existing contemporaneous record. CRA accepts supplementary documentation.
4. Implement the PR template going forward to ensure the remaining months of the fiscal year generate strong evidence automatically.

For the prior fiscal year, the same approach applies: connect GrantOps, ingest historical data, review classifications, and supplement thin records with dated comments or technical notes where developers can provide them. See [our SR&ED audit preparation guide](/en/blog/sred-audit-preparation-guide/) for more detail on reconstructing documentation for prior periods.

## Connecting PR Evidence to Hour Tracking

T661 Part 2 requires you to report eligible salary expenditures by employee and project. This means matching hours to developers and to specific SR&ED projects. PR evidence supports this directly.

GrantOps uses PR submission timestamps, commit timestamps, and review comment timestamps to build a time allocation model. This is not a substitute for a timesheet system, but for companies that do not maintain granular R&D timesheets (which is most software companies), the Git and PR record provides a defensible basis for time allocation estimates.

For a more complete treatment of how commit-level data supports hour tracking, see our post on [SR&ED hour tracking from Git commits](/en/blog/sred-hour-tracking-git-commits/).

## Start Collecting SR&ED Evidence from Your PRs Today

The evidence for your SR&ED claim is already being created every time a developer opens a pull request. Whether that evidence is strong enough to support a CRA review depends on two things: how PRs are written, and whether you have a system to collect and organize them before the fiscal year closes.

The PR template in this post addresses the first problem. GrantOps addresses the second.

If you want to see what your existing PR history already contains as SR&ED evidence, connect your repositories at [grantops.ai](https://grantops.ai) and run a free historical analysis. The ingestion takes minutes, the classification review takes an hour, and you will have a clear picture of where your SR&ED claim stands before engaging any consultant or spending time on manual documentation.

For companies earlier in the process, start with the [SR&ED eligibility overview](/en/sred/) to confirm your R&D activities qualify, then return here to set up the PR template before your team's next sprint.

A free SR&ED eligibility assessment is available at [grantops.ai](https://grantops.ai), no consultant fees, no commitment.

---

Try GrantOps: https://app.grantops.ai/auth?mode=signup (free to start, no credit card). Plans: Starter $99 CAD/month, Professional $499 CAD/month, plus an 8% success fee. Pricing: https://grantops.ai/en/pricing/