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 provideHow it affects the result
Incident/act dateAnchors the timeline and helps determine when the limitation clock begins (or where “arose” may be placed).
Discovery dateIf the limitation regime is discovery-based, it can move the start date and therefore the deadline.
Claim typeDifferent limitation frameworks can apply; the tool uses this to select the correct time logic.
Tolling/suspension eventsCan 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/territoryIn 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:

  1. Go to /tools/statute-of-limitations
  2. Select the Canada jurisdiction (and the appropriate province/territory if requested).
  3. Enter the required claim type so the calculator can apply the correct time framework.
  4. Provide your anchoring dates:
    • incident / act date
    • date claim arose (or the closest supported date)
    • discovery date (if the tool uses it)
  5. Add tolling/suspension events only when you have a documented basis for them in your file.
  6. Enter your milestone date (e.g., filed or served) so DocketMath can test whether that date falls inside the limitations window.
  7. 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