Resources

SR&ED Time Tracking for Engineering Teams: What the CRA Expects and What Works in Practice

By Matt | Last reviewed October 27, 2026

For many software companies, salaries and wages are one of the largest components of an SR&ED claim. That makes the time your engineers spend on eligible work more than a record-keeping detail. It directly affects the salary or wage expenditure you can include, and it needs to be supported by a method you can explain.

It is also one of the hardest parts of a claim to get right. Engineers move between experimental and routine work within a single week, sometimes within a single afternoon. Few people enjoy filling in timesheets, and the claim may be prepared months after the work took place.

This guide explains what the CRA says about employee time, whose time can count, the main ways teams track it, and a practical setup for engineering organizations that want a defensible record without turning every developer into a part-time bookkeeper. It is written for companies preparing their own claims and for the consultants or accountants who support them.

Why employee hours matter so much in an SR&ED claim

For employees directly engaged in SR&ED, the CRA says the portion of salary or wages included in the claim must be based on the time spent on SR&ED activities and the tasks performed, regardless of job title. Under the proxy method, the CRA’s Salary or Wages Policy goes further: the claimant’s information system must capture directly engaged time, and the allocation should be supported by a method, a rationale and internal controls that can be tested.

Separately, the CRA’s documentation guidance says your supporting records should show four things: what work was done, who was involved, when they did it, and how you calculated the associated expenditures.

Together, those points define the job. For each person included in the claim, you need a credible answer to a simple question: how much of their working time went to eligible SR&ED work, and what evidence supports that allocation?

Hours also tie the money to the technical story. If your project description says three engineers spent the spring testing retry strategies, a reviewer can reasonably expect the time allocation and supporting records to tell a consistent story. When they do not, the company needs to be able to explain why.

Consider an illustrative example. A software company allocates three engineers to an SR&ED project from April through June. The project narrative describes repeated testing of retry logic, duplicate-job prevention and failover behaviour. One engineer is allocated 80% to the project in May, but the available tickets and source-control activity show mostly unrelated product work that month. That does not automatically make the allocation wrong: some of the work may have happened in architecture sessions, test environments, design documents or shared code. But it creates an obvious question, and the supporting evidence should be able to reconcile the difference.

What the CRA says about time records

The CRA does not prescribe a specific time-tracking application or a standard timesheet template. Its current guidance lists a broad range of supporting documentation, including records of resources allocated to a project, time sheets, activity records and payroll records, alongside design documents, source code, meeting minutes, test data and other technical evidence.

Three points are especially useful for engineering teams:

The CRA says documentation that is dated, signed and specific to the work performed is best, although it accepts various types of supporting documentation.
The CRA recommends maintaining records throughout all phases of the SR&ED work because this supports the claiming process and may reduce errors.
The claimant remains responsible for the accuracy of the claim, whether it prepares the claim itself or uses an external adviser.

There is flexibility in how you track time, but there is not flexibility about being able to support the allocation. The CRA’s Salary or Wages Policy specifically says that, under the proxy method, the information system used by the claimant must capture directly engaged time. Under the traditional method, it must capture directly engaged time as well as directly related and incremental time. The CRA also says the labour-allocation system should be functional throughout the year and supported by evidence that the method is appropriate for the company’s environment.

In practice, that means a simple, repeatable process that produces explainable evidence is usually more useful than an elaborate tracking system that engineers stop using after a few weeks.

Whose time counts toward the claim

The CRA looks at the tasks an employee performs, not the title on the org chart. Under the proxy method, employees are considered directly engaged when they are doing hands-on SR&ED work or support work that is commensurate with the needs of, and directly supports, the SR&ED work.

For engineering organizations, a few examples help:

A developer who builds and tests a prototype to resolve a technological uncertainty may be doing qualifying SR&ED work. The same developer fixing a routine production bug or implementing a standard feature later that day is not automatically doing SR&ED. The allocation needs to reflect the work actually performed.
An engineering manager or supervisor can have qualifying time when directing the course of ongoing SR&ED work or providing direct technical input. Time spent on non-technological management activities - such as general budgeting, hiring or performance management - is not directly engaged time merely because the manager oversees an SR&ED team.
QA or testing work can count where it is required as part of the SR&ED project and directly supports the experimentation or analysis. Routine regression testing, release validation or general quality assurance is not automatically SR&ED.
A product manager is treated the same way: the title itself neither qualifies nor disqualifies the person. The question is whether the specific tasks were directly engaged in, or - under the traditional method - otherwise directly attributable to, the SR&ED work. Commercial planning, roadmap prioritization and customer research would not become SR&ED simply because they relate to the same product.
Administrative and clerical staff are generally not considered directly engaged under the proxy method. Under the traditional method, certain directly related and incremental support costs may be treated differently, depending on the facts.

Whether the underlying project qualifies for SR&ED is a separate question. This article assumes you have already identified the work you intend to assess as eligible.

Why time tracking is harder for software teams

A lab or a shop floor often has physical boundaries that help separate experimental work from normal production. Software teams usually do not, and several things make the problem harder:

The work is mixed. Experimental development and routine maintenance may live in the same codebase, sprint and even the same ticket.
The tools track activity, not necessarily time. Issue trackers show what moved, source control shows what changed, and calendars show meetings. None of them, on its own, tells you exactly how long someone spent resolving a technological uncertainty.
Records get completed late. When time allocations are entered at the end of a month or quarter, they can become estimates from memory rather than records made close to the work.
The claim is often assembled later. By year end, a question such as “what were you actually testing in March?” can be surprisingly difficult to answer.

A common failure pattern is not that the year-end estimate is obviously absurd; it is that it is too smooth. A team may assign the same percentage to an engineer for six straight months even though the underlying work trail shows bursts of experimentation separated by feature development, customer work and routine maintenance. That kind of mismatch is exactly why a defensible allocation should be tied back to the records the team actually produced.

Four ways teams track SR&ED time

Most teams end up with one of four approaches, or a mix. None is perfect, and the right choice depends on team size, tooling and how mixed the work is.

Method	How it works	Where it holds up	Where it breaks down
Dedicated time tracker	Engineers log hours against SR&ED and non-SR&ED projects in a time-tracking tool.	Direct, dated records tied to named projects.	Needs regular discipline. Adoption can fade and entries may still become end-of-week estimates.
Issue tracker	Tickets are grouped or labelled by SR&ED project, with time logged or estimated in Jira or a similar tool.	Fits existing engineering workflows and links allocations to underlying work.	Tickets can mix experimental and routine work; time fields may be incomplete or estimated.
Periodic allocation	A manager or employee estimates the percentage of time by project each month or quarter.	Low effort and potentially reasonable for roles with a stable split.	Only as strong as the basis for the estimate; weaker when the employee moves frequently between types of work.
Year-end reconstruction	Hours are reconstructed after the year closes using available records and employee recollection.	Can provide a basis when contemporaneous records are incomplete.	More dependent on memory and generally harder to substantiate than records maintained throughout the year.

The CRA’s guidance points to a practical test: is your allocation method appropriate for your environment, is it functional throughout the year, and is there evidence that lets someone test whether the resulting allocation is reasonable? Many engineering teams use a combination - for example, project tags and source-linked activity during the year, plus a regular employee or manager review.

A tracking setup that works for engineering teams

There is no single correct system. The following pattern is a practical approach for software teams because it keeps the burden relatively low while producing a reviewable trail:

Agree the project structure early. Once you have identified potential SR&ED work, give projects or workstreams consistent names, codes, epics or labels. Projects can evolve, but avoid inventing the entire structure after year end.
Separate experimental from routine work where practical. If one ticket contains both, split the ticket or add enough context to make the distinction reviewable.
Capture allocations close to the work. Weekly is a practical cadence for many teams, but the right frequency depends on how quickly people switch between projects. The objective is to avoid reconstructing months of work from memory.
Add a small amount of technical context. A note such as “tested three queue backoff strategies; two exceeded the latency threshold” is more useful than hours alone.
Review periodically. A short manager or employee review each month or quarter can catch gaps while the work is still fresh and confirm that the allocation matches what actually happened.
Keep the evidence connected and findable. Tickets, pull requests, source code, design documents, test results, meeting notes and other artefacts can all help support the claim. Make sure they can be located by project and period.
Reconcile at year end. Compare the time allocation with payroll and the technical project history, resolve obvious inconsistencies, and preserve the records used to arrive at the final numbers.

A simple example

Suppose a developer earns $120,000 a year and a supported allocation shows that 35% of her working time was spent on directly engaged tasks across two SR&ED projects. A simplified salary allocation would be $42,000 (35% of $120,000), subject to the applicable SR&ED rules. The key question in a review is not whether 35% sounds plausible; it is what supports the 35%. A repeatable allocation method tied to project records and reviewed by the employee or manager is much stronger than a single percentage entered when the claim is being prepared.

This example is illustrative only. The actual salary or wage amount that can be claimed depends on the method used, the nature of the employee’s work and other SR&ED rules that may apply.

Common time-tracking mistakes

Applying one flat percentage to everyone on the team without evidence underneath it.
Deciding who counts by job title instead of by the tasks they performed.
Estimating all hours after year end and presenting them as if they had been recorded contemporaneously.
Allowing the hours to drift away from the technical story. If the project narrative says experimentation ended in June but the time allocation continues through September, there should be a clear explanation.
Tracking at a level of detail nobody will sustain. A theoretically perfect process that engineers abandon is not a good control system.
Losing the underlying records when people leave or tools change. CRA business-record rules generally require records and supporting documents to be kept for six years from the end of the last tax year to which they relate; some records must be kept longer. Preserve the evidence used to support the claim, including exports when systems may not remain available.

Where ActiveSRED fits

ActiveSRED is in development and is opening an early-access group for Canadian companies, SR&ED consultants and accounting firms. It starts from a simple observation: engineering teams already leave a detailed work trail across issue trackers, source control, calendars, documents and collaboration systems.

ActiveSRED is being built to connect that work trail, propose employee-level SR&ED hours and project context, and then ask contributors to review, correct and confirm what accurately reflects their work. When the connected records leave gaps, the planned agentic consultant can gather focused context from the engineers or managers who were there. The claim owner then reviews the consolidated project and company drafts before anything moves forward.

The goal is not to turn AI output into an automatic claim. It is to reduce the manual reconstruction work, keep the underlying evidence close to the numbers it supports, and focus human attention on the areas that actually need judgment.

Interested in trying it with your team? Join ActiveSRED early access

Frequently asked questions

Does the CRA require timesheets for SR&ED?

The CRA does not prescribe a particular timesheet format or software tool. Timesheets are one example of supporting documentation, alongside activity records, payroll records and technical evidence. However, the CRA’s Salary or Wages Policy says the claimant’s information system must capture the relevant time used to allocate salary or wages: directly engaged time under the proxy method, and directly engaged plus directly related and incremental time under the traditional method. The important point is that the allocation must be supported by a reasonable, explainable system.

How detailed does SR&ED time tracking need to be?

The CRA does not set a universal minimum such as daily or quarter-hour entries. It expects the labour allocation to be reasonable, supported by evidence and appropriate for the company’s environment. The right level of detail is therefore the level that lets you connect the claimed time to the SR&ED work and test the allocation without imposing a process the team will not maintain.

Can we estimate hours at year end?

Sometimes a company has to reconstruct an allocation because contemporaneous records are incomplete. In that situation, tickets, source-control history, calendars, design records and employee explanations can help build a supportable estimate. But CRA guidance says dated, specific documentation is best and recommends maintaining records throughout the SR&ED work, so a year-end estimate generally needs more explanation than a system that was operating during the year. Document the method and the evidence used to arrive at the numbers.

Do salaried employees need to track their time?

Yes, in the sense that you need a supportable way to determine the portion of their salary or wages that relates to SR&ED work. A salaried employee does not necessarily need to complete a conventional timesheet, but the claimant still needs an allocation method and evidence supporting the amount claimed.

Whose time can be included in the claim?

It depends on the tasks performed and the expenditure method used, not simply the employee’s title. Hands-on experimentation, qualifying programming, testing and certain support work can be directly engaged. Managers and supervisors can have qualifying time when they direct ongoing SR&ED work or provide direct technical input, but general management time does not qualify merely because it relates to an SR&ED team. The traditional method can also treat some directly related and incremental support costs differently from the proxy method.

Sources

Primary CRA guidance reviewed October 27, 2026:

Related reading: ActiveSRED resources · SR&ED Changes in 2026

This article provides general information, not tax or legal advice. SR&ED eligibility and expenditure treatment depend on the facts of each claim, and CRA guidance can change. Check current CRA guidance and consult a qualified SR&ED adviser where appropriate.