Spreadsheet checks before running statute of limitations in New Hampshire

What the checker catches

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

Running a statute of limitations (SOL) calculation off a spreadsheet is fast—until one column, date, or formula quietly shifts your result. DocketMath’s statute-of-limitations checker is designed to catch spreadsheet mistakes that commonly flip an outcome in New Hampshire civil timing questions.

For New Hampshire, the default civil SOL period is 3 years under RSA 508:4. No claim-type-specific sub-rule was found for this checker scenario, so this guidance uses the 3-year general period as the baseline.

Here are high-impact spreadsheet issues the checker helps you spot before you rely on the numbers:

• Wrong “start date” column

  • Example: using the “received date” instead of the “event date” (or vice versa).
  • A single swapped column can move the expiration date by months.

• Wrong “end date” column

  • Example: using the “draft filing date” instead of the actual “filing date.”
  • Your spreadsheet might show “within time,” but the checker will flag inconsistency when the operative comparison date is different.

• Off-by-one logic around deadlines

  • Spreadsheets sometimes treat a deadline as inclusive vs. exclusive without making the rule obvious.
  • DocketMath’s outputs encourage you to confirm boundary behavior (for example, whether a date exactly 3 years later is treated as timely in your workflow).

• Text dates stored as strings

  • In Excel/Google Sheets, dates can be stored as text, which can break comparisons and date arithmetic.
  • The checker’s sanity checks help you detect dates that don’t behave like true date values.

• Time components that shouldn’t matter

  • A timestamp like 2023-01-15 13:45 can cause unexpected comparisons if other columns are plain dates.
  • The checker nudges consistent “date-only” inputs so you don’t accidentally mix formats.

• Blank or partially filled cells

  • A missing value can make formulas return empty strings, zeros, or misleading “true/false” outcomes.
  • The checker helps surface those gaps before you proceed.

• SOL period miswired

  • Since the New Hampshire general period for this baseline is 3 years under RSA 508:4, your spreadsheet should not allow hidden “years” inputs to be changed to 2 or 4 without you noticing.
  • DocketMath’s workflow helps keep your assumptions aligned with the 3-year default used here.

Practical takeaway: The most expensive spreadsheet error usually isn’t arithmetic—it’s a date-field mismatch (using the wrong “start” or “end” date). A checker can’t confirm legal conclusions, but it can prevent you from trusting the wrong inputs.

Quick reference: baseline assumptions used in this checker workflow

When to run it

Use the checker before you finalize any “timely vs. time-barred” flag, before you produce review-ready reports, and before you lock dates into narrative case summaries.

A practical rule of thumb:

• Run it at the earliest stage where both dates exist

  • For example, once you have:

    • the relevant event/start date (whatever your spreadsheet uses as the trigger date), and
    • the filing date (or operative date your workflow compares against).

• Rerun it after every spreadsheet edit that touches dates

  • Any change to:

    • the source data sheet,
    • the date format,
    • the formulas referencing the date columns,
    • or the SOL-period cell (e.g., “years”)

• Re-run it after importing from another system

  • Imports often convert dates to text, strip timezones, or shift formats (for example, MM/DD/YYYY vs. DD/MM/YYYY).

Checklist you can use immediately:

Try the checker

If you’re using DocketMath’s statute-of-limitations tool, treat it like a “preflight” step for your spreadsheet math. Your goal is to verify that the expiration date and the timely/timed-out comparison are computed from the same dates and assumptions your spreadsheet uses.

Inputs to double-check in your spreadsheet

When you open your dataset, make sure your columns match what you intend to compare:

• **Start date (trigger date)

  • The date you believe starts the SOL clock for your workflow.
• **Filing date (comparison date)

  • The date you believe determines whether the filing is within the SOL period.
• SOL period

  • For this default New Hampshire civil SOL baseline: 3 years, under RSA 508:4.

Output behaviors to sanity-check

After you run the tool, verify these three outputs:

1. Calculated expiration date

   • Does it land exactly 3 years after the start date (with boundary logic consistent with your workflow)?
2. Comparison result

   • Is the tool marking “timely” vs. “potentially outside” based on your filing date?
3. Consistency across rows

   • If one row is wildly different from nearby rows, it often indicates:

     • a single date typed incorrectly,
     • a swapped column reference,
     • or a copied formula pointing at the wrong cells.

To start directly, use DocketMath here: /tools/statute-of-limitations.

Minimal “spot check” procedure (2–3 minutes)

Pick 3 representative rows:

• one with an older start date,
• one with a start date near the middle of your dataset,
• one with the newest start date.

Then:

• Run the checker.
• Compare the tool’s expiration date to what your spreadsheet produces.
• If you see any mismatch, fix the input columns/formulas first—don’t adjust the spreadsheet by guesswork.

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