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 check | What you expect | Red flag |
|---|---|---|
| Claim date format | Real date | Stored as text |
| Filing date format | Real date | Stored as text |
| SOL baseline | 3-year default | Any non-3-year output without a defined rule |
| Deadline logic | Consistent comparison | Contradictory 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)
- Clean/standardize dates
- Compute a deadline date using the 3-year default period
- Compare “filing date” to “deadline date” using one consistent rule
- 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
- 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
- Statute of limitations in United States (Federal): how to estimate the deadline — Full how-to guide with jurisdiction-specific rules
