Spreadsheet checks before running statute of limitations in New York

6 min read

Published April 8, 2026 • By DocketMath Team

What the checker catches

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

Before you compute any statute of limitations (SOL) date in New York, run a spreadsheet sanity-check. DocketMath’s statute-of-limitations calculator is only as reliable as the inputs feeding it—and SOL logic tends to fail in predictable spreadsheet ways.

For this page, the New York general/default criminal SOL baseline is 5 years, stated in N.Y. Crim. Proc. Law § 30.10(2)(c). No claim-type-specific sub-rule was found, so this checker treats 5 years as the baseline rather than branching into other categories. (Still, always double-check whether additional case-specific rules could apply.)

Here’s what a solid spreadsheet checker should catch—especially for New York’s general/default 5-year period:

  • Wrong SOL basis selected

    • If your sheet contains multiple SOL rules (or multiple rows/tables), confirm the calculator is actually using the general 5-year rule.
    • If your sheet has a “type” column, verify you aren’t unintentionally filtering out the general rule (for example, a blank “type” causing the filter to drop the default row).
  • Date field mismatches

    • Common issues:
      • Date stored as text (e.g., "2022-01-05" instead of a true Excel/Sheets date value)
      • Mixed formats across columns (MM/DD/YYYY vs YYYY-MM-DD)
      • Empty cells that later default to zero/blank in formulas
    • Effect on output:
      • A text date can produce a calculation error—or worse, a value that looks numeric but represents something else (shifting results by days or even years).
  • Wrong “start date” used

    • SOL calculations depend heavily on what date you treat as the “trigger” (the start point for the limitations clock).
    • Spreadsheets often rename columns late in the workflow (or copy formulas into new sheets). For example, if IncidentDate becomes FilingDate, but the formula still references the old range, outputs can drift without obvious visual flags.
  • Boundary-day behavior / off-by-one day

    • Even when you use the correct SOL period (5 years), date arithmetic can differ depending on how your spreadsheet adds time.
    • For example, these approaches can behave differently near boundaries:
      • =StartDate + 365*5 (approximate)
      • =DATE(YEAR(StartDate)+5, MONTH(StartDate), DAY(StartDate)) (calendar-aware)
      • (and other variations)
    • Result: your “expires on” date may shift by a day due to inconsistent year/month/day handling.
  • Time components bleeding into “date-only” logic

    • If you have timestamps (e.g., 2020-05-10 14:35) but later compare as if values are pure dates, comparisons can flip around midnight boundaries.
    • Effect on output:
      • Your “Expired?” status can change depending on the as-of time handling (not just the calendar date).
  • Inconsistent “as-of” date usage

    • A spreadsheet can compute the correct expiration date but evaluate it using a different “current/as-of” value in another column.
    • Effect on output:
      • You might see a correct “expires on” date while the “Expired?” label is based on a different reference date.

Pitfall to watch: A sheet may look correct when eyeballed, yet still be using the wrong date column due to renamed headers and stale cell references. Before running any SOL computation, verify the exact cell ranges that feed your calculator.

Quick spreadsheet checks (high signal, low effort)

Before you run SOL calculations, use these checks:

When to run it

Run the checker at three points in your workflow. Each timing catches a different class of failure.

  1. Right after importing data

    • Goal: catch format problems immediately (text dates, blanks, inconsistent separators).
    • Why now: once values propagate through derived columns, format issues can multiply and become harder to trace.
  2. Before feeding values into DocketMath

    • Goal: ensure the exact cells you copy into the calculator correspond to the correct start date and as-of date.
    • Why now: SOL timing is highly sensitive to trigger date selection and boundary-day behavior.
  3. After major formula edits or column renames

    • Goal: detect stale references caused by renamed headers, re-ordered tables, or moved rows.
    • Why now: many spreadsheet SOL bugs are reference mistakes—not arithmetic mistakes.

Rerun rule of thumb: if you change any of the following, rerun the checker:

  • a date column name
  • a “trigger” definition
  • an “as-of” definition
  • the formulas that calculate expiration dates or status labels

Try the checker

Use DocketMath’s statute-of-limitations calculator to validate that your spreadsheet inputs and outputs agree.

Primary link: /tools/statute-of-limitations

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Minimal input set to validate

For the New York general/default criminal SOL baseline, use the following inputs:

  • Start date: your chosen trigger date for SOL timing
  • As-of date: the date you want to evaluate whether it has expired
  • SOL period: set to 5 years as the default/general rule under **N.Y. Crim. Proc. Law § 30.10(2)(c)

Reference for the general 5-year baseline: https://www.nysenate.gov/legislation/laws/CPL/30.10

Note: This page uses the general/default 5-year SOL period under N.Y. Crim. Proc. Law § 30.10(2)(c). No claim-type-specific sub-rule was found, so this checker treats that 5-year period as the baseline.

Output sanity tests (what to compare)

After you run DocketMath, compare its outputs to your spreadsheet’s derived columns:

CheckWhat you compareExpected outcome
Calendar-aware year mathYour “expires on” date vs DocketMath’s expiration dateDates align (not just the year)
Status correctnessYour Expired? label vs DocketMath’s expired/non-expired outputSame label based on the as-of date
Boundary day behaviorStart dates near month-ends (e.g., Jan 31)No unexpected shifts from 365*5-style logic
Format consistencyDate-type vs text-type inputsNo missing/zeroed dates; no silent parsing differences

A quick “break it on purpose” test

To confirm your checker actually catches errors:

  1. Make a copy of your spreadsheet (don’t modify production).
  2. Intentionally introduce one common issue, such as converting a valid date to text.
  3. Run the checker, then run DocketMath again.
  4. If your expiration date changes or errors appear, you’ve validated that your pipeline is sensitive to the formatting failures that often cause SOL mistakes.

Gentle disclaimer

This is a spreadsheet quality-control workflow, not legal advice. Statute of limitations outcomes can depend on additional case-specific facts and procedural details beyond a general baseline.

Related reading