Educational Resource

SR&ED Contemporaneous Documentation Checklist

Dated, specific records created while work is being performed are often the strongest support for an SR&ED project. CRA does not prescribe a weekly quota or guarantee acceptance based on document volume. Relevance, specificity, timing, and connection to the claimed work matter more than raw count.

What is Contemporaneous Documentation?

Contemporaneous documentation is evidence created during or shortly afterthe SR&ED work is performed. CRA's current get-ready guidance recommends maintaining records throughout the work and lists technical and financial records that may support a claim. The timing, relevance, and reliability of each record still require fact-specific review.

Examples of contemporaneous evidence:

Git commits with descriptive messages
Jira tickets describing experiments and hypotheses
Lab notebooks and experiment logs
Slack messages discussing technical challenges
Meeting notes about design decisions
Code comments explaining novel approaches

An Optional Capture Rhythm (Not a Quota)

If a weekly review fits your team's normal workflow, the following rhythm can help preserve relevant records. Use it when material work occurs; it is not a CRA frequency requirement or a reason to create records when there is nothing relevant to document.

Monday: Planning & Hypotheses

Record current technical uncertainties when they arise
Create Jira tickets for planned experiments when useful
State supported hypotheses explicitly in ticket descriptions
Reference relevant prior learnings

Tuesday–Thursday: Active Development

Commit meaningful code changes with descriptive messages
Tag experimental branches clearly (e.g., experiment/feature-extraction)
Update Jira tickets with observations and measurements
Document material failures and unexpected results if they occur
Screenshot graphs, charts, performance metrics

Friday: Analysis & Retrospective

Summarize material findings since the last review
Close tickets with conclusions (even if inconclusive)
Identify the next open questions
Create PRs with detailed descriptions of what was tried

Evidence quality principles

Use these as review questions, not CRA minimums. The right mix depends on the work and the records your business normally creates.

Principle	Ask	Useful examples
Relevance	Does the record support a specific claimed uncertainty, test, observation, result, participant, date, or cost?	Experiment plan, issue, commit, test result
Contemporaneity	Was it created during or shortly after the work, and is its date trustworthy?	Repository history, dated notes, instrument logs
Specificity	Does it explain what was unknown, tried, measured, observed, and concluded?	Technical decision, failed test, measured comparison
Traceability	Can a reviewer find the original and connect it to the project, person, period, and narrative statement?	Stable link, source ID, author, timestamp

Common Pitfalls to Avoid

❌ What NOT to Do

Mislabelled reconstruction: Presenting a later recollection as contemporaneous. Preserve original timestamps and label later context honestly
Vague descriptions: "Made improvements" or "Fixed issues" without details
Business-focused language: Talking about revenue, customers, features instead of technical challenges
Unexplained gaps: Long periods with no relevant support can leave work harder to substantiate; a gap is not proof that the work did not happen
Selective history: Omitting material unsuccessful tests or contrary results that actually occurred

✅ What TO Do

Timely capture: Preserve relevant records during or shortly after work when practical, and label later reconstruction honestly
Technical specificity: Explain the uncertainty, hypothesis, experiment, observation, analysis
Explain the investigation: Connect uncertainty → hypothesis → test → observation → conclusion when the records support that sequence
Relevant cadence: Capture records when material work, tests, observations, or decisions occur; there is no fixed weekly minimum
Honest reporting: Include material successes and failures that actually occurred

Tool-Specific Best Practices

GitHub

Use branches like experiment/, research/, prototype/
Commit messages should describe why, not just what
Tag failed experiments clearly (don't delete branches)
Use PR descriptions to document experiment outcomes

Jira

Custom issue type: "Research" or "Experiment"
Required fields: Hypothesis, Methodology, Expected Outcome
Update tickets with observations during work (not just at completion)
Close tickets with "Findings" section even if experiment failed

Slack

Create a dedicated #sred-log channel
Use tags like #experiment, #fail, #breakthrough
Encourage team to share technical challenges and solutions
Archive messages for year-end review

How SR&ED Copilot Helps

SR&ED Copilot supports evidence organization by:

Manual capture and on-demand import: Add records directly or import selected GitHub, Jira, Slack, and other supported-source records
Optional ongoing feeds: Webhook capture is available only when the source and server are separately configured
Coverage review: Surface longer spans without active records as heuristics for human review, not CRA quotas
Evidence timeline: Visual view of all captured evidence throughout the year
T661 generation: AI drafts narratives (lines 242/244/246) citing specific evidence items
Audit trail: Export Word/PDF with complete mapping of claims to evidence

Disclaimer: This is educational content, not tax or legal advice. Consult with qualified SR&ED advisors for your specific situation. SR&ED Copilot provides documentation support; final claims must be reviewed and filed by tax professionals.

Current sources: CRA Guide T4088, Appendix 2 and the CRA get-ready guidance. Reviewed July 11, 2026.

Ready to organize your SR&ED documentation?

Start with one project, preserve the source records, and see which periods or technical points need better support.

Start Free Trial