Spreadsheet checks before running statute of limitations in Connecticut

5 min read

Published April 8, 2026 • Updated April 15, 2026 • By DocketMath Team

What the checker catches

A statute of limitations spreadsheet can look “right” while hiding common calculation failures—especially in Connecticut, where many claim types use the general/default limitations period in Conn. Gen. Stat. § 52-577a, which is 3 years for certain civil actions.

Before you rely on spreadsheet outputs, sanity-check the spreadsheet mechanics. DocketMath’s statute-of-limitations tool (paired with a spreadsheet checklist) is meant to catch spreadsheet issues—like date handling, swapped inputs, or inconsistent comparisons—rather than to replace legal analysis.

Below are the most frequent failure modes a spreadsheet checker catches.

1) Incorrect baseline year math (date arithmetic drift)

Spreadsheet formulas can drift when they mix text and date types, or when leap years and end-of-month behavior aren’t handled consistently. Even when the spreadsheet returns a deadline date, it may not be the deadline you think it is.

Checklist

2) Reversed dates (or swapped columns)

If “event/claim date” and “date filed” are swapped, the spreadsheet still often produces a result—just for the wrong timeline.

Checklist

3) Off-by-one counting (inclusive vs. exclusive comparisons)

Some workflows treat the limitations deadline as expiring on a specific calendar day, while others treat comparisons as strictly greater-than/less-than based on computed elapsed days. Either approach can be consistent—but mixing approaches within a spreadsheet causes contradictory flags.

Checklist

Pitfall: If one part of your sheet says “timely” while another part computes a conflicting deadline relationship, the comparison logic is almost always misaligned.

4) Missing or null dates (silent failures)

Blank cells and nulls can produce zeros, errors that get hidden by filters, or fallback defaults that still look “plausible.”

Checklist

5) Applying the wrong rule set (default vs. overrides)

Your brief notes that no claim-type-specific sub-rule was found. That means you should treat the Conn. Gen. Stat. § 52-577a period as the general/default period—explicitly 3 years—unless and until you add a clearly modeled, specific rule.

Action

6) Row-level consistency across multiple sheets

Many teams compute the deadline in one tab and compare results in another. If one tab normalizes dates differently (or uses different units), the “same case” can produce different conclusions.

Checklist

Here’s a quick “sanity table” you can mirror in your spreadsheet:

Row checkWhat you expectRed flag
Claim date formatReal dateStored as text
Filing date formatReal dateStored as text
SOL baseline3-year defaultAny non-3-year output without a defined rule
Deadline logicConsistent comparisonContradictory pass/fail flags

Gentle note: This is a spreadsheet QA step. It’s not legal advice, and it won’t determine the merits of any specific claim.

When to run it

Run DocketMath’s statute-of-limitations spreadsheet checks before you interpret outputs, and again any time inputs or formulas change. This helps prevent a spreadsheet from “looking stable” while logic quietly shifts.

Run the checker before importing a spreadsheet into the Statute Of Limitations workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Recommended cadence

  • Before first use
  • After every data import
  • After any formula edit
  • Before producing a report or exporting

Typical workflow (practical)

  1. Clean/standardize dates
  2. Compute a deadline date using the 3-year default period
  3. Compare “filing date” to “deadline date” using one consistent rule
  4. Export for review

If you skip date standardization, later steps may still compute numbers—but the numbers may be unreliable.

Try the checker

Use DocketMath’s statute-of-limitations calculator as a cross-check against what your spreadsheet is doing. The goal is to confirm your spreadsheet inputs produce the same direction of outcome (e.g., deadline earlier/later), and that your baseline assumption matches the default/general rule.

Primary CTA

Start here: **/tools/statute-of-limitations

Practical steps to test your spreadsheet

Pick 3 sample rows:

For each row, verify:

Input/output alignment rules for your spreadsheet

Use these “change the input, predict the output” tests:

  • If you change the claim date by +1 day, the computed deadline should move by +1 day (not by “nothing,” not by ~365 days, and not randomly).
  • If you change the filing date earlier by 30 days, a “timely” flag shouldn’t flip to “untimely” unless your sheet has a comparison-direction error.
  • If your spreadsheet produces a non-3-year period for the default model, your baseline parameter likely got overwritten.

Warning: If your spreadsheet includes other concepts (tolling days, exclusions, or claim-type overrides), treat the default 3-year rule as a separate baseline output. Combining them without a clear switch can make the checker seem “wrong” when the spreadsheet is mixing rules.

Related reading