Back to Resources
R&D February 25, 2026

T661 Form Guide: How to Complete Your SR&ED Claim

The complete guide to the T661 form for Canadian software companies. All 10 parts, technical narrative requirements, filing deadlines, and common mistakes.

CI

Chrono Innovation

Engineering Team

The T661 is the form CRA requires for every SR&ED tax credit claim in Canada. Filed alongside your corporate tax return, it identifies your qualifying projects, describes the technical work performed, and calculates the expenditures eligible for investment tax credits.

In 2024-25, Canadian companies filed 22,758 SR&ED claims and received $4.5 billion in approved ITCs. Software development accounted for 40.8% of all allowed credits — the largest single field by a significant margin. If your company employs five or more developers doing technically uncertain work, the T661 is almost certainly worth your attention.

This guide covers the form’s structure, what each section actually requires, how to write technical narratives that satisfy CRA reviewers, and the mistakes that most commonly reduce or disqualify claims.


What Is the T661 Form

The T661 is officially titled “Scientific Research and Experimental Development (SR&ED) Expenditures Claim.” It must be filed with every SR&ED credit claim alongside the T2SCH31 Investment Tax Credit schedule. Filing one without the other forfeits part or all of the benefit.

The supporting reference document is CRA’s T4088 Guide to Form T661, which provides line-by-line instructions. The T661 itself contains 10 numbered parts.


The 10 Parts of the T661 Form

Part 1 — General Information

Claimant name, business number, tax year, and primary contact. Straightforward. This is the administrative header.

Part 2 — Project Information (The Critical Section)

Part 2 is completed once for each qualifying project and has three distinct subsections.

Section A — Project Identification

Project title and internal code, start and end dates, the CRA field-of-science classification code (from the T661 appendix), whether the project is a continuation of prior-year work, and disclosure of any collaborative or joint projects with other entities.

Section B — Technical Narratives

The three narrative fields where most claims succeed or fail. Each has a strict word limit:

  • Line 242 (max 350 words): The technological uncertainty that made the work necessary.
  • Line 244 (max 700 words): The work performed — hypotheses, experiments, tests, results, and conclusions, in chronological order.
  • Line 246 (max 350 words): The new technical knowledge gained or the technological advancement achieved.

These are covered in detail in the next section.

Section C — Additional Project Information

Who prepared the technical descriptions and their qualifications. Names and roles of up to three key technical personnel. Whether any work was performed outside Canada. Subcontractors involved. What documentation is available to support the claim.

Note on multi-project claims: If you have more than 20 qualifying projects, CRA allows you to file Part 2 for the 20 largest by dollar value. All other parts must be complete for all projects.

Part 3 — Calculation of SR&ED Expenditures

You select one of two methods here, and the choice is binding for the tax year:

  • Proxy Method: Overhead is represented by a formula — 55% of salary base. No itemized overhead tracking required. Most software companies use this.
  • Traditional Method: All overhead is specifically identified and allocated with detailed supporting documentation. Higher ceiling but significantly more work.

Parts 4-7 — Financial Calculations

These sections calculate your qualified SR&ED expenditure pool (Part 4), the Prescribed Proxy Amount under the proxy method (Part 5), project-level cost breakdowns (Part 6), and supplementary details (Part 7). If you’re using a consultant or accountant, these parts are primarily their domain.

Part 8 — Claim Checklist

CRA’s internal completeness verification. Skipping fields or leaving items uncorroborated increases audit selection probability. Complete it carefully.

Part 9 — Claim Preparer Information

Identifies who prepared the claim — an internal employee or an external consultant. This section was added in 2013. Missing it triggers a $1,000 penalty but does not disallow the claim.

Part 10 — Certification

Authorized officer attestation. The person signing takes responsibility for the accuracy of the claim.


How to Write the Technical Narratives

Lines 242, 244, and 246 are where claims are won or lost. CRA reviewers spend the most time here. Vague or misdirected narratives are the most common reason otherwise eligible claims are denied.

The three T661 technical narrative fields: Line 242 technological uncertainty (350 words), Line 244 work performed (700 words), and Line 246 advancement achieved (350 words)

Line 242 — Technological Uncertainty (350 words)

CRA’s definition: “Whether a given result or objective can be achieved, or how to achieve it, is not known or determined on the basis of generally available scientific or technological knowledge or experience.”

Three things this means in practice:

1. The uncertainty must exist at the start of the project, not in hindsight. You’re describing why, at the time work began, the solution was not obvious or derivable from existing public knowledge.

2. It must be beyond what any qualified practitioner could resolve by applying known methods. Technical problems solved by applying established techniques are explicitly excluded. Technological uncertainty exists when even a skilled expert could not determine the solution without conducting original investigation.

3. Failure is acceptable evidence. Learning that an approach will not work constitutes advancing knowledge. You don’t need to succeed — you need to have faced genuine uncertainty and investigated it.

What CRA does not want to see in Line 242: business objectives (“we wanted to improve customer performance”), feature descriptions (“we needed the system to handle 10,000 concurrent users”), or problems solved by applying known solutions (“we implemented caching to reduce database load”).

Line 244 — Work Performed (700 words)

This is the systematic investigation record. CRA uses a five-question test drawn from case law (known as the “Northwest Hydraulic” framework):

  1. Was there scientific or technological uncertainty?
  2. Were hypotheses formulated to reduce that uncertainty?
  3. Was the approach consistent with systematic investigation via experiment or analysis?
  4. Was the goal scientific or technological advancement?
  5. Were records of hypotheses tested and results maintained as work progressed?

All five must be answered affirmatively by what you write in Line 244. Structure it as a chronological record: the hypothesis you started with, the experiments or analyses you ran, the results you observed, and the conclusions you drew. Each cycle of hypothesis-test-result is one iteration of systematic investigation.

CRA guidance is explicit: “Trial and error lacking systematic planning does not constitute proper investigation.” You need to show that your approach was structured, not random.

Line 246 — Advancement Achieved (350 words)

What new knowledge did your team gain? Advancement doesn’t require a commercial product or a successful outcome. It requires that the understanding produced by your investigation extends beyond what existed at the project’s start.

Write in terms of principles: what your team now understands about the problem space, the limitations you discovered, the constraints you mapped. Avoid restating the business outcome. “We shipped the feature in Q3” is not technological advancement.


Software-Specific Eligibility

Software development qualifies under three scenarios, per CRA guidance:

  1. The software itself is the novel product — a new algorithm, a novel data architecture, a machine learning model with no existing technical solution.
  2. Software combined with hardware creates an improved product — embedded control systems, signal processing pipelines, custom neural network implementations.
  3. Software created to support a qualifying SR&ED project that is not part of the final commercial product — custom testing frameworks, simulation tools, HDL code.

System Uncertainty — The Key Concept for Software Companies

Most commercial software is built on known tools, libraries, and frameworks. CRA has historically required novelty in the components themselves, not just in how they are combined. A 2024 Tax Court ruling changed this.

In DAZZM Inc. v. His Majesty the King (2024 CCI 129), Justice Gagnon clarified that combining known components can itself create technological uncertainty — called “system uncertainty” — when the interactions between those components are unpredictable. The ruling also confirmed that technological uncertainty should be evaluated at the project level, not the task level, and accepted performance metrics and time estimates in lieu of daily timesheets.

This matters: if your engineering team integrated multiple known systems and encountered interaction effects that required original investigation to resolve, you may have qualifying work even though no individual component was novel.

What Does Not Qualify

CRA is explicit that these do not qualify, regardless of technical complexity:

  • Routine bug fixes using established debugging methods
  • Applying standard caching, file transfer protocols, or database patterns without addressing their known limitations
  • Quality control and routine testing
  • Hiring experts to apply what they already know
  • Novelty in a mobile app’s features or functionality achieved using existing technical methods

The distinction CRA draws: technology is the practical application of scientific knowledge and principles — not simply building what is technically possible using existing tools.

Software SR&ED eligibility: what qualifies (novel algorithms, system uncertainty, hardware-software integration) versus what does not (routine bug fixes, standard patterns, applying known solutions)


Filing Deadlines

The SR&ED filing deadline is 12 months after the income tax return due date for the year in which eligible expenditures were incurred. For corporations, this produces an 18-month window from fiscal year-end:

Fiscal Year-EndTax Return DueSR&ED Deadline
December 31, 2024June 30, 2025June 30, 2026
March 31, 2025September 30, 2025September 30, 2026
June 30, 2025December 31, 2025December 31, 2026

Two rules that catch companies unprepared:

No extensions. CRA states: “The CRA cannot by law allow any additional time” after the deadline passes. Missing it results in automatic disallowance of the entire claim. There is no appeal mechanism.

Both forms must be filed by the deadline. The T661 and the T2SCH31 must both be submitted. Filing only one forfeits part or all of the benefit.

CRA recommends filing at least 90 days before the deadline. This gives time to address deficiencies CRA identifies while there is still a window to correct them.

For the 2026 filing season, see SR&ED Filing Deadline 2026: Key Dates and How to Prepare.


Common T661 Mistakes That Reduce or Disqualify Claims

According to G6 Consulting, 80% of SR&ED claims are approved without detailed review. Of the 20% that are audited, approximately 60% are denied or substantially reduced. The gap between the two groups is almost always in the narratives and the documentation.

The most expensive narrative mistakes:

  • Describing what the software does, not the problem in building it. “We built a real-time processing pipeline that handles 50,000 events per second” is a product description. “We investigated whether known message-queue architectures could maintain sub-100ms latency under concurrent write loads exceeding published benchmarks, and found that none could without architectural modifications requiring original investigation” describes qualifying work.

  • Omitting the hypothesis-test structure. CRA reviewers look for evidence that your team formulated an approach, tested it, observed results, and drew conclusions. A list of tasks performed does not satisfy the systematic investigation requirement.

  • Business language in technical fields. Phrases like “improve customer experience,” “support our growth,” and “competitive pressure” belong nowhere in Part 2. Every sentence should describe a technical fact.

The most expensive documentation mistakes:

  • No contemporaneous records. CRA treats documentation created after the fact skeptically. Records created during the work — git logs, PR descriptions, sprint notes, test results, design documents — are the strongest evidence. If your documentation was assembled at filing time from memory, your claim is weaker and more vulnerable in an audit.

  • Claiming 100% of an employee’s time without supporting records. Time allocations above 80% for any individual trigger reviewer scrutiny. You need time-tracking data, calendar records, or project assignment documentation to support allocations.

  • Missing subcontractor documentation. Subcontractor costs require signed contracts, invoices, and a description of the qualifying work performed. A $100,000 subcontractor claim without contracts will be reduced or denied.

  • Omitting government assistance disclosure. Provincial SR&ED credits and federal grants must be disclosed on Line 429. The omission triggers automated flags.


The Documentation Problem

The T661 is ultimately a documentation exercise. The qualifying work your engineers did over the past fiscal year — the uncertain investigations, the failed approaches, the novel solutions — is already captured in your development artifacts. Git commits, pull requests, Jira tickets, Linear tasks, architecture decision records: this is the raw material of a T661 claim.

The difficulty is translating that raw material into the specific format and language CRA requires. Most companies do it retrospectively, which is expensive (engineering time lost to reconstruction), risky (memory is unreliable, and CRA treats retroactive documentation skeptically), and incomplete (qualifying work from earlier in the year that wasn’t flagged at the time is simply lost).

Chrono Platform connects to your development tools and produces CRA-ready T661 documentation from your actual commit history, pull requests, and project tickets — automatically, as work happens. The result is more accurate documentation than retrospective reconstruction, with zero impact on your engineering team.

For a detailed comparison of software vs. consultants for SR&ED documentation, see SR&ED Consultants vs. Software: An Honest Comparison.

If your team is spending engineering time reconstructing SR&ED documentation at year-end, talk to us about automating it from your existing development artifacts.


Sources: CRA T661 form page | T4088 Guide to Form T661 | SR&ED Annual Program Statistics | Eligibility of Work Policy | Filing Requirements Policy | G6 Consulting — T661 Rejections | SR&ED Education — DAZZM Analysis

#sred #t661 #tax-credits #cra #r-and-d #canada
CI

About Chrono Innovation

Engineering Team

A passionate technologist at Chrono Innovation, dedicated to sharing knowledge and insights about modern software development practices.

Ready to Build Your Next Project?

Let's discuss how we can help turn your ideas into reality with cutting-edge technology.

Get in Touch