The top mistakes

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

When you run statute of limitations calculations in New York with DocketMath, small input errors can create big downstream mistakes—like counting from the wrong date or ignoring a timing event. Below are common SOL pitfalls people hit in US-NY, using the general/default statute period as the starting point: 5 years under N.Y. Crim. Proc. Law § 30.10(2)(c) (see the statute at https://www.nysenate.gov/legislation/laws/CPL/30.10).

error 1: Using the wrong “start date” (the clock can be triggered by different events)

A frequent error is entering a “date of accident” (or a similar label) when the SOL clock should be based on another legally triggering event. Even where the baseline period is fixed at 5 years, the output deadline depends heavily on the start date you feed into the calculator.

What goes wrong in practice

• You enter the wrong event date as the SOL start.
• DocketMath produces a termination date that is consistently off by days, months, or even years.

Quick check

• Identify the event that legally starts the clock for your scenario.
• Use that specific date as the calculator start-date input, not a secondary or “likely related” date.

error 2: Confusing “date filed” with “date served”

Another common error is comparing the SOL expiration to the wrong procedural milestone. Some teams compare to the complaint filing date; others compare to the service date. If your internal workflow compares DocketMath’s SOL “deadline date” to the wrong milestone, you may incorrectly conclude a matter is timely—or time-barred.

What to do

• Align your “timeliness check” to the procedural event your workflow uses.
• Keep that mapping consistent across cases so the same logic is applied every time.

error 3: Treating “5 years” as automatically correct without confirming the context

Because the general/default SOL period is 5 years under N.Y. Crim. Proc. Law § 30.10(2)(c), it’s tempting to skip verification. But New York SOL analysis can turn on context—what is being charged, and whether a specialized timing framework applies.

Key point

• Use 5 years as the default only after you’ve confirmed you’re in the general track for your scenario.
• Don’t let the calculator’s baseline replace the initial “is this the right rule?” check.

error 4: Ignoring tolling or other timing modifiers

Even when the baseline is 5 years, the effective deadline can change due to specific legal timing events. A common failure mode is running the baseline SOL calculation and then forgetting to incorporate the timing modifiers that your matter depends on.

Practical takeaway

• If tolling/timing adjustments are part of your process, document them and ensure your calculator inputs are consistent with that approach.

error 5: Day-level vs. month-level assumptions (off-by-one errors)

SOL deadlines are often computed with day precision in practice. Using a “month and year” approximation can cause subtle errors—especially around leap days or when deadlines land on weekends/holidays (depending on the framework your team uses for internal deadline handling).

How this appears

• You estimate “about 5 years” and mark it timely.
• Later, the precise deadline date shows it’s outside the window.

Practical rule

• When you need accuracy, rely on DocketMath’s date arithmetic, not rough calendar approximations.

How to avoid them

Step 1: Confirm you’re using the right baseline rule (general/default SOL)

For this guide, the baseline rule is the general/default SOL period of 5 years, referencing:

• N.Y. Crim. Proc. Law § 30.10(2)(c) — general/default statute of limitations period (5 years)
  https://www.nysenate.gov/legislation/laws/CPL/30.10

Because no claim-type-specific sub-rule was identified here, treat 5 years as the general starting point—not as a guarantee that it’s the only timing rule that could apply.

Step 2: Use the correct date inputs—and label them clearly

When you run DocketMath’s statute-of-limitations calculator, structure inputs so each date has a clear meaning:

• Start date: the date the SOL clock begins to run
• Comparison date: the date you’re using to test timeliness (for example, your workflow’s “filed” or “served” milestone)
• Modifiers (if applicable): if your workflow applies tolling/adjustments, ensure you handle them consistently with the calculator approach and your internal logic

If you’re not sure which date starts the clock, resolve that question before calculating. A correct baseline period can’t fix a wrong start date.

Use the calculator here: /tools/statute-of-limitations

Step 3: Run a “sanity range” before relying on the exact output

A fast internal validation reduces risk:

• If your start date is January 15, 2020, a 5-year baseline should generally land near January 15, 2025 (then refine based on any timing logic your workflow applies).
• If the computed deadline lands in 2026, that’s a red flag that an input date was shifted by a year.

If you want to quickly re-check calculations, you can revisit your run in DocketMath at: /tools/statute-of-limitations

Step 4: Verify what your team compares against (filed vs. served)

Make sure the date you compare to the SOL deadline matches what your process is designed to measure. Use a checklist:

Step 5: Keep a paper trail—record your assumptions in the calculation notes

DocketMath is a calculation tool; it can’t replace case-specific legal analysis. Still, you can prevent confusion by recording:

• the statute basis used (N.Y. Crim. Proc. Law § 30.10(2)(c) for the general/default 5-year framework)
• the start date you entered
• any timing modifiers you applied (or explicitly did not apply)

This makes audits and case reviews faster, and it helps you catch mismatches between “calculated SOL” and “used SOL” logic.

Step 6: Re-check edge cases at year boundaries

Pay extra attention when the deadline may land around:

• leap days (e.g., February 29)
• weekends/holidays (depending on your internal deadline method)
• year-end transitions

These are common places where an “almost right” estimate becomes a real error.

Related reading

• Browse the blog

The top mistakes

• using the wrong cause-of-action period
• skipping tolling or suspension windows
• treating discovery as accrual without support
• missing choice-of-law constraints

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

How to avoid them

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

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