How to run statute of limitations in DocketMath for Canada

7 min read

Published April 8, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Statute Of Limitations calculator.

This guide walks you through running a statute of limitations calculation in DocketMath for Canada (CA) using the Statute of Limitations calculator. You’ll see exactly what to enter, how the output changes as dates and time periods change, and how to interpret the results at a practical level.

Note: This is a tooling walkthrough, not legal advice. Statutes of limitation can be affected by facts, applicable legislation, and specialized limitation rules in certain proceedings.

1) Open the correct calculator

Start at the primary call to action:

  • Go to: /tools/statute-of-limitations

If you’re navigating within the app, you can also jump from your dashboard or tools menu, then select the statute-of-limitations calculator.

2) Set the jurisdiction to Canada (CA)

In DocketMath, the jurisdiction selection should be set to Canada (CA). This matters because limitation periods and rules are not identical across legal systems—and even within Canada, rules can differ depending on the claim type.

If DocketMath presents a “jurisdiction” drop-down, choose Canada (CA) explicitly rather than relying on any default.

3) Choose the claim type (if prompted)

Many statutes-of-limitations tools ask for the category of claim (for example: contract, debt, personal injury, or a general civil claim). Select the option that best matches the dispute you’re working on.

If the calculator supports multiple pathways (e.g., “general civil,” “property,” “employment”), use the option that aligns with the underlying cause of action you’re modeling. Your selection determines which time window the tool applies.

4) Enter the key date(s)

Most statute-of-limitations calculations require at least one “start” date and then compute an “expiry” date based on a limitation period.

Typical inputs you’ll see in a calculator like DocketMath include:

  • Start date / date of the event (for example, the date the claim arose or the date harm occurred)
  • Date filed / action commenced (for example, the date you’re assessing against)
  • Optional but common:
    • Discovery date (if the limitation rule uses knowledge/discovery)
    • Last date of related conduct (if the period runs from a final act)

Use the best available date for the rule you’re testing. If the underlying limitation logic uses discovery, entering a “discovery date” will shift the computed deadline later or earlier.

5) Understand how DocketMath updates the output

After you enter dates and claim type, DocketMath will calculate, typically:

  • Calculated limitation expiry date (deadline by which the claim generally must be started)
  • Days remaining / days overdue (relative to the “date filed” you enter)
  • A simple status indicator (e.g., within time vs. potentially time-barred) based on the tool’s model

Try changing one variable at a time to see the effect. A common pattern:

  • Later start datelater expiry date
  • Later filing dateshorter time remaining (or “overdue” if beyond the expiry date)
  • Discovery date included → expiry can move based on the later of the event vs. discovery dates (depending on the tool’s logic)

6) Review the limitation expiry and status

Once DocketMath produces results, check:

  1. Expiry date: the computed last date to start the proceeding (per the calculator’s model).
  2. Time difference: how many days between “date filed” and expiry.
  3. Consistency: confirm that the dates you entered are logical (e.g., you didn’t accidentally set a filing date earlier than the start date).

7) Capture your assumptions before you share results internally

Before saving or exporting, note the assumptions you used—especially:

  • Which claim type you selected
  • Which start date you used (event date vs. discovery date)
  • The filing date you compared against

This makes it easier to rerun the calculation if your team later updates facts (for example, substituting a discovery date once evidence is developed).

8) Save or rerun with alternate scenarios

A practical workflow is to run multiple scenarios:

  • Scenario A: using event date as start
  • Scenario B: using discovery date as start
  • Scenario C: adjusted dates (e.g., “last contact,” “final invoice date,” or “last day of performance”)

DocketMath’s value is highest when you can compare outputs across scenarios and document which assumption drove the deadline.

9) If you need to reference other DocketMath tools

If your workflow involves documenting timelines beyond limitations, you may find it useful to pull related entries from other parts of the platform. For example, you can cross-check date handling and formatting by using tools accessible via /tools/statute-of-limitations and adjacent pages in your tools menu.

You can also start again or revisit the calculator directly here: /tools/statute-of-limitations.

Common pitfalls

Statute-of-limitations runs are usually “date math” plus claim classification. The most frequent failure points are input assumptions and mismatched claim categories.

Warning: Avoid treating any single calculator result as dispositive for a real-world claim. Limitation periods can be affected by statutory interpretation, procedural context, and specific exceptions.

Pitfall checklist

Use this checklist before you finalize your DocketMath run:

  • Event/harm date vs. discovery date vs. when the claim “arose”
  • Filing date earlier than start date (usually indicates an entry error)
  • If the calculator asks for a discovery date, leaving it blank may change the output materially
  • Teams often assume the first start date is correct; running at least one alternate scenario reduces surprises
  • Many systems model “start the proceeding” deadlines; procedural steps may have separate timing requirements

How to detect a likely bad run quickly

If any of the following happens, rerun with corrected assumptions:

  • The expiry date looks obviously off by years (e.g., you expected months).
  • “Days overdue” is extremely large given your known timeline.
  • You used a start date that is after the filing date, unintentionally.

A fast fix is to:

  1. Re-check the date order.
  2. Re-check the claim type.
  3. Rerun with an alternate start date (especially event vs. discovery).

Practical “scenario discipline”

For Canada-focused limitation reviews, a disciplined approach usually beats guesswork:

That comparison tells you whether your limitation result is robust or sensitive to discovery-style facts.

Try it

Follow these steps to run a full calculation in DocketMath right now:

  1. Open /tools/statute-of-limitations
  2. Select **Canada (CA)
  3. Choose your best-match claim type
  4. Enter:
    • Start date (event date or the best available trigger date)
    • Date filed (the comparison date)
    • Add discovery date if the calculator requests it and you have it
  5. Click Calculate (or equivalent action)
  6. Review:
    • Calculated limitation expiry date
    • Time remaining / overdue days
  7. Run a second scenario by changing only one input:
    • Swap start date type (event ↔ discovery) or adjust discovery date by 30–60 days if you’re testing sensitivity

If the result flips from “within time” to “overdue” (or vice versa) when you adjust one date, you’ve identified the input that drives the deadline. That’s exactly the insight you want from a limitations calculator.

When you’re ready to expand beyond limitation deadlines, you can also use other DocketMath tooling and date-handling workflows to keep timelines consistent. Start from the tools area via /tools/statute-of-limitations.

Related reading