Worked example: statute of limitations in Australia

7 min read

Published April 8, 2026 • By DocketMath Team

Example inputs

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

This worked example shows what a statute of limitations calculation can look like in Australia using the DocketMath tool: /tools/statute-of-limitations.

Because limitation rules can depend heavily on the type of claim and the relevant limitation trigger (often framed around discoverability/knowledge versus breach), the goal here is to demonstrate how inputs flow into an output—not to provide legal advice about a specific dispute.

Scenario (worked example)

You’re assessing a civil claim and want to check whether it’s brought within the limitation period after a triggering event.

We’ll use a simplified fact pattern:

  • Claim type (inputs used by the calculator): Contract / simple contract debt (civil claim)
  • Date of breach (trigger candidate): 10 January 2022
  • Date the claimant became aware (optional “knowledge/discoverability” input): 25 February 2022
  • Limitation rule used by the calculator (for this illustration): 6 years from the relevant trigger date
  • Assessment date (“today”): 1 March 2028
  • Legal action filing date (optional second deadline check): 10 March 2028

Note: In Australia, different causes of action can have different limitation periods and different triggers. This example uses a single consistent rule solely to illustrate DocketMath calculation mechanics.

Inputs checklist

Use this list to mirror what you’d type into the DocketMath statute-of-limitations calculator:

  • Select jurisdiction: AU
  • Select claim type used by the tool (e.g., contract debt)
  • Enter breach date: 10 Jan 2022
  • Enter knowledge/discoverability date (if your chosen rule uses it): 25 Feb 2022
  • Enter assessment date: 1 Mar 2028
  • Enter proposed filing date (for a second “pass/fail”): 10 Mar 2028

How the calculator typically chooses the trigger

DocketMath’s logic (as reflected in the tool’s workflow) generally follows this pattern:

  • If the rule for the chosen claim type is “from breach”, then the breach date is the trigger.
  • If the rule is “from knowledge/discoverability” (or uses a claimant-awareness component), then the knowledge/discoverability date can become the trigger.
  • When both dates exist, the calculator applies the relevant trigger rule tied to the selected limitations setting.

To make this practical, the worked example runs two variations:

  1. Trigger = breach date
  2. Trigger = knowledge/discoverability date

That’s why the next section includes a sensitivity check.

Example run

Below are two runs for the same factual timeline, differing only in which date becomes the trigger.

Run the Statute Of Limitations calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Common timeline (same facts)

  • Breach: 10 January 2022
  • Knowledge/discoverability: 25 February 2022
  • Assessment (“today”): 1 March 2028
  • Proposed filing: 10 March 2028
  • Limitation period length (as used in this example): 6 years

Run A — Trigger set to the breach date

Trigger: 10 Jan 2022
Limitation period: 6 years
Calculated expiry date: 10 Jan 2028

Now compare to the relevant dates:

  • Assessment date: 1 Mar 2028
    • 1 Mar 2028 is after 10 Jan 2028 → likely out of time for that expiry benchmark.
  • Proposed filing date: 10 Mar 2028
    • 10 Mar 2028 is also after 10 Jan 2028 → also out of time on this trigger.

Result (Run A):

  • Expiry date: 10 Jan 2028
  • Status as at 1 Mar 2028: Expired
  • Status for filing 10 Mar 2028: Expired

Run B — Trigger set to knowledge/discoverability

Trigger: 25 Feb 2022
Limitation period: 6 years
Calculated expiry date: 25 Feb 2028

Compare again:

  • Assessment date: 1 Mar 2028
    • 1 Mar 2028 is after 25 Feb 2028 → expired.
  • Proposed filing date: 10 Mar 2028
    • 10 Mar 2028 is after 25 Feb 2028 → expired.

Result (Run B):

  • Expiry date: 25 Feb 2028
  • Status as at 1 Mar 2028: Expired
  • Status for filing 10 Mar 2028: Expired

What this teaches you (calculation mechanics)

Even with different triggers, this particular timeline ends up expired in both runs—because the assessment and filing dates fall after both calculated expiry dates.

Where DocketMath becomes especially useful is when your dates are close to the boundary. In practice, a small shift in the trigger can flip a result from “within time” to “out of time.”

So next, we keep the facts the same and move only the assessment date.

Sensitivity check

Sensitivity checks answer a practical question: “If I move one input—usually the trigger—does the outcome change?”

Here, we hold most inputs constant and vary the assessment date, while keeping both trigger options available (breach vs knowledge/discoverability).

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Use the same underlying timeline

  • Breach: 10 Jan 2022
  • Knowledge: 25 Feb 2022
  • Proposed filing: fixed at 10 Mar 2028
  • Limitation length: 6 years

Variation 1 — Assessment date moved earlier

Consider an earlier assessment date: 15 February 2028.

  • If trigger = breach (expiry 10 Jan 2028):
    • 15 Feb 2028 is after 10 Jan 2028 → expired
  • If trigger = knowledge (expiry 25 Feb 2028):
    • 15 Feb 2028 is before 25 Feb 2028 → within time

So for assessment on 15 Feb 2028:

  • Run A (breach trigger): Expired
  • Run B (knowledge trigger): Within time

Variation 2 — Assessment date on the boundary (near expiry)

Try an assessment date of 20 February 2028.

  • Under breach trigger (expiry 10 Jan 2028): still expired
  • Under knowledge trigger (expiry 25 Feb 2028): still within time

Variation 3 — Assessment date just after the knowledge expiry

Use 26 February 2028.

  • Under breach trigger (expiry 10 Jan 2028): expired
  • Under knowledge trigger (expiry 25 Feb 2028): expired (by 1 day)

Quick comparison table

Assessment dateExpiry if trigger = breach (10 Jan 2028)Expiry if trigger = knowledge (25 Feb 2028)
15 Feb 2028ExpiredWithin time
20 Feb 2028ExpiredWithin time
26 Feb 2028ExpiredExpired

Pitfall: If you enter a “knowledge/discoverability” date that’s based on an estimate, the outcome can shift near the expiry boundary. For limitations analysis, precision about the trigger input often matters as much as the rest of the calculation.

Practical checklist before you rely on an output

When you run your own DocketMath calculation, consider:

Disclaimer: This is an educational worked example, not legal advice. If you’re dealing with a real dispute, consider speaking with a qualified professional about the applicable limitation rules and triggers.

Related reading