Inputs you need for statute of limitations in Canada
5 min read
Published April 8, 2026 • By DocketMath Team
Inputs you will need
Run this scenario in DocketMath using the Statute Of Limitations calculator.
To run a statute of limitations calculation in Canada using DocketMath, you’ll typically supply a small set of core dates and fact details. Think of these as “inputs the calculator can’t guess,” because limitation periods are tied to specific events and timing.
Use this checklist to make sure your case has the information DocketMath needs before you click /tools/statute-of-limitations.
Note: This is a practical checklist—not legal advice. A limitations result is only as reliable as your date inputs. If you have conflicting dates across emails, invoices, pleadings, or internal summaries, normalize them before running the tool.
What each input changes in the output
| Input you provide | How it affects the result |
|---|---|
| Incident/act date | Anchors the timeline and helps determine when the limitation clock begins (or where “arose” may be placed). |
| Discovery date | If the limitation regime is discovery-based, it can move the start date and therefore the deadline. |
| Claim type | Different limitation frameworks can apply; the tool uses this to select the correct time logic. |
| Tolling/suspension events | Can extend or pause the limitations window (if supported in the calculator’s logic). |
| File/serve date (milestone) | Used to determine whether your deadline has been missed or still available at that milestone. |
| Province/territory | In Canada, procedural and some substantive timing details differ by jurisdiction; the tool uses this to apply the correct rules. |
| End of conduct date (if applicable) | Helps refine the relevant triggering event when the alleged wrong is ongoing or tied to a period of performance. |
Where to find each input
Collect the inputs from your case file and supporting documents. DocketMath works best when you can point to a specific record for each date.
- Incident / alleged wrongful act date
- Emails, incident reports, police occurrence reports (where applicable), contract milestones, project logs.
- Look for the first “event date” mentioned consistently in your documents.
- Date the claim arose
- Often the date performance was missed, the breach occurred, the damage manifested, or the wrongful act happened (depending on claim type).
- If your facts span multiple dates (e.g., repeated breaches), identify the earliest date that plausibly starts the legal time clock under your claim theory.
- **Discovery date (or “ought to have discovered”)
- Internal investigation start date, first complaint to a counterparty, notice letters, damage assessment dates.
- If discovery is disputed, use the earliest date your records show you had enough knowledge to consider a claim.
- **Date of end of conduct (if relevant)
- Stop-work dates, termination notices, final invoices, last communications.
- Useful where the alleged wrong is ongoing or contractual performance continues for a period.
- Claim type
- Pleadings, drafts, demand letters, or your internal case taxonomy.
- If you’re splitting facts into multiple legal theories, decide which theory you want the statute analysis to reflect for this run.
- Tolling/suspension events
- Court orders, written agreements to extend time limits, procedural stays, or other time-altering events.
- Keep the document showing the event and its effective date.
- Jurisdiction
- The location of the parties, the contract’s governing context (if relevant), or where proceedings are intended to be brought.
- If there’s a chosen forum clause, use the province/territory that matches the intended forum.
Warning: Don’t “average” dates. For limitations, picking the wrong day can swing the result from “within time” to “out of time.” Choose the earliest defensible trigger for discovery/notice and document why.
Run it
Once you’ve gathered the inputs, run your calculation in DocketMath:
- Go to /tools/statute-of-limitations
- Select the Canada jurisdiction (and the appropriate province/territory if requested).
- Enter the required claim type so the calculator can apply the correct time framework.
- Provide your anchoring dates:
- incident / act date
- date claim arose (or the closest supported date)
- discovery date (if the tool uses it)
- Add tolling/suspension events only when you have a documented basis for them in your file.
- Enter your milestone date (e.g., filed or served) so DocketMath can test whether that date falls inside the limitations window.
- Review the output summary and note:
- the tool’s calculated deadline
- the computed time window (how long the period runs)
- any dependency on discovery or other conditional inputs
How to sanity-check the output (before you rely on it)
Use these checks to catch common data-entry problems:
Pitfall: If you accidentally swap incident date and discovery date, the tool may still produce a result—yet it can be internally inconsistent with your actual timeline. Always cross-check that the discovery date is not earlier than the incident date unless your facts truly support that.
Recommended workflow (fast and repeatable)
If you have multiple plausible discovery/trigger dates (common in complex disputes), run multiple scenarios and compare:
DocketMath is most useful when you can see how sensitive the deadline is to the specific date you’re arguing.
Related reading
- Choosing the right statute of limitations tool for Vermont — How to choose the right calculator
- Statute of limitations in Singapore: how to estimate the deadline — Full how-to guide with jurisdiction-specific rules
- Choosing the right statute of limitations tool for Connecticut — How to choose the right calculator
