How to run statute of limitations in DocketMath for Delaware

6 min read

Published April 8, 2026 • By DocketMath Team

Step-by-step

This guide shows you how to run a statute of limitations (SOL) calculation in DocketMath for Delaware (US-DE). It’s a practical walkthrough—not legal advice—so treat the results as a starting point for review and documentation.

  • Select Delaware in the Statute Of Limitations tool.
  • Enter the trigger dates and any caps or rates.
  • Run the calculation and save the output.

1) Open the SOL calculator in DocketMath

Start here:

2) Confirm the jurisdiction is set to Delaware

In the calculator, select or verify:

  • Jurisdiction: **Delaware (US-DE)

DocketMath will use Delaware’s default/general SOL rule for this workflow when a claim-type-specific rule isn’t selected or found.

Note: For Delaware, the general/default period used here is 2 years, tied to Title 11, § 205(b)(3). If you’re looking for a specialized SOL (for a specific claim category), you may need additional inputs or a different rule selection—this guide covers the general rule.

3) Enter the event date (the “start” date for the clock)

In Delaware’s general SOL setup, you’ll typically model the clock from a key triggering date, such as:

  • a date of injury
  • a date a cause of action accrued
  • another trigger date relevant to your claim facts

Input to enter: Trigger date (the date the SOL begins running)

What changes when you change it:
Moving the trigger date forward shifts the computed expiration date forward by the same amount (assuming the tool accounts for exact calendar dates).

4) Enter the “as-of” date (the date you want to test timeliness)

Next, provide the date you want DocketMath to evaluate against the SOL deadline. Common examples:

  • the filing date (to check whether a complaint is timely)
  • today’s date (to see whether a deadline appears to have passed)

Input to enter: As-of date (the date you’re testing)

What changes when you change it:

  • If the as-of date is before the expiration date, DocketMath should flag the matter as within the general SOL window.
  • If the as-of date is after the expiration date, it should flag the matter as outside the general SOL window.

5) Review the rule used: Delaware’s general SOL (2 years)

DocketMath will apply Delaware’s general rule for this calculation:

If DocketMath displays a rule name/version, verify it reads like a general/default calculation. This matters because Delaware has multiple SOL provisions across different claim categories; relying on the general rule when a specialized rule should apply can produce the wrong deadline.

6) Generate and interpret the output

After you run the calculation, DocketMath typically returns:

  • Computed SOL expiration date (trigger date + 2 years)
  • A timeliness comparison between your as-of date and the expiration date
  • Often, a reason/rule label identifying the statute used

Use the expiration date as the anchor, then check the comparison:

  • Timely (within SOL): as-of date is on or before the expiration date
  • Time-barred (outside SOL): as-of date is after the expiration date

Practical checklist for interpreting results

7) Save your work and document your assumptions

Before you move on, record:

  • the trigger date
  • the as-of date
  • the expiration date shown by DocketMath
  • the statute label shown (e.g., 11 Del. C. § 205(b)(3))

This helps you explain the calculation later—especially if you revisit the analysis using different triggering dates based on new documents or updated timelines.

When small input edits matter

Try re-running if you have competing factual timelines, such as:

  • an incident date vs. an accrual/discovery/notice-related date
  • an event date vs. when the affected party first knew of the harm

Even a 7–14 day shift can change whether the as-of date is inside or outside the deadline boundary.

Common pitfalls

Most SOL mistakes come from input choices and rule selection rather than arithmetic. Here are the common issues to watch for when running the Delaware general/default 2-year rule in DocketMath.

  1. Using the wrong “start” date If you input a date that doesn’t match the clock start used by your model, the expiration date will drift. Common errors include:
  • using the filing date as the trigger (the trigger should represent when the SOL begins running)
  • using a later discovery/notice date when your facts would support an earlier trigger
  1. Assuming the general/default rule always applies This guide uses only Delaware’s general/default 2-year rule from 11 Del. C. § 205(b)(3) and is not claim-type-specific.
  • If Delaware provides a different SOL for your claim category, the correct statute may not be the one applied here.
  1. Testing the wrong “as-of” date Make sure the as-of date matches your question:
  • “timely if filed on X?” vs.
  • “deadline passed as of today?”

Swapping these can flip the result.

  1. Ignoring rule labels in the output DocketMath may display a rule name or statute reference. If it doesn’t clearly indicate Title 11, § 205(b)(3) and the general/default basis, pause and verify:
  • jurisdiction selection
  • rule selection (if applicable)

Pitfall: If DocketMath is set to use the general/default 2-year rule, treating the output as if it were a claim-specific deadline can lead to an incorrect conclusion about “timely” vs. “time-barred.”

  1. Not recording what you entered Without saving the trigger date and as-of date, it becomes difficult to explain how the deadline was calculated, especially as facts evolve.

Try it

Run a Delaware general SOL calculation using these example inputs. Adjust dates to match your facts.

InputExample valueEffect on output
JurisdictionDelaware (US-DE)Ensures the calculator uses Delaware’s default SOL framework
Trigger date2024-01-15Expiration date moves based on this date + 2 years
As-of date2026-01-14Likely within the 2-year window (exact boundary depends on exact date handling)

Suggested experiment: shift by 1 month

Try one controlled change:

  • Keep the as-of date the same
  • Move the trigger date forward by 30 days

You should see the computed expiration date shift forward too, and the timeliness result may change if you cross the deadline boundary.

Where to double-check in the output

After each run, confirm:

  • the expiration date produced
  • the statute used (should reference 11 Del. C. § 205(b)(3))
  • whether the tool labels the period as general/default 2 years

If the statute label or rule type doesn’t match the general/default rule, stop and review your selections before relying on the output.

Related reading