Spreadsheet checks before running statute of limitations in Texas

What the checker catches

DocketMath’s statute-of-limitations calculator is a fast way to test deadlines in Texas, but spreadsheets can silently sabotage accuracy. Before you run any Texas statute-of-limitations math, use the checker to validate your inputs and logic—especially if you’re calculating dates, tolling assumptions, or “derived” fields (like days-since-filing).

Because Texas criminal limitations rules are found in Texas Code of Criminal Procedure, Chapter 12, the calculator’s baseline default for this jurisdiction is the general period from that chapter. Treat it as a default/general starting point, not a claim-type-specific rule—no claim-type-specific sub-rule was identified in the jurisdiction data provided.

Here are the spreadsheet problems the checker is designed to catch early:

• Date format drift

  • Common failure: one column is real dates, another is text (e.g., "01/05/2024" stored as text).
  • Symptom: results look nonsensical—negative days, or “0 years” where you expected a normal interval.
• Off-by-one errors

  • Excel/Sheets date math can shift by a day depending on whether you treat endpoints as inclusive or exclusive.
  • Symptom: two rows that should match differ by exactly 1 day, flipping borderline “within/outside SOL” outcomes.
• Wrong direction of subtraction

  • Failure: using StartDate - EndDate instead of EndDate - StartDate.
  • Symptom: your “elapsed time” flips sign and any SOL comparison may reverse.
• Using the wrong baseline date

  • Spreadsheet rows often mix dates like:

    • date of alleged conduct
    • date charge was filed / complaint issued
    • date case was initiated
  • Symptom: results converge around a “plausible” year count that doesn’t match your timeline logic.
• **Unit mismatch (days vs years)

  • Your sheet might store “days elapsed,” while your SOL logic expects “years.”
  • In the jurisdiction data you were given, the general SOL period is 0.0833333333 years, which is about 30.4 days (since ~1 year ≈ 365.25 days).
  • Symptom: converting 30.4 days to years incorrectly (or double-converting) can move borderline rows across the line.
• Mixed-row contamination

  • A filter might hide bad rows, while summary cells still reference the full range.
  • Symptom: the count or average changes even though your filtered view doesn’t show the issue row(s).
• Hardcoded constants that drift from your sheet

  • If you hardcode 0.0833333333 in one place but use a different conversion factor elsewhere, outputs can disagree across tabs.
  • Symptom: the calculator says “expired,” while the sheet’s conditional formatting says “not expired.”

When to run it

Run the checker right when you’re about to turn spreadsheet rows into “SOL decision” outputs. In practice, that means:

1. Before you feed values into DocketMath

   • Verify each row’s key dates are true date types (not text).
   • Confirm the baseline date matches your sheet’s definition (e.g., “alleged conduct to charge filing,” if that’s what you’re modeling).
2. After you apply transforms—but before you summarize

   • This includes:

     • DATEVALUE() conversions
     • TEXT() formatting changes
     • time-zone or locale conversions (especially after CSV imports)
3. Right before you bucket/filter into “expired / not expired”

   • If you wait until the end, the checker can’t reliably tell you which transformation introduced the error.

A simple workflow:

• Step A: Run the checker on the raw date columns.
• Step B: Run the checker again after you compute any derived “elapsed” fields.
• Step C: Then run the DocketMath statute-of-limitations calculator and lock in your decision logic.

Also, keep your default assumptions explicit in the sheet:

• Texas criminal limitations baseline: Texas Code of Criminal Procedure, Chapter 12
• Default period from your jurisdiction data: 0.0833333333 years
• Treatment: general/default period (no claim-type-specific sub-rule was found in the provided data)

Warning (non-legal advice): If you’re modeling multiple scenario categories, relying on a single “general/default” SOL period can underperform—even when the spreadsheet math is otherwise correct.

Try the checker

Use DocketMath like this:

1. Open the tool

   • Go to: **DocketMath statute-of-limitations

2. Map your spreadsheet inputs to the calculator inputs

   • In your sheet, identify:

     • the start date (the event/date you measure from)
     • the end date (the filing/charging milestone you compare to)
   • Then compare them row-by-row with what the calculator expects.

3. Sanity-check against the default period

   • The default general SOL here is 0.0833333333 years (≈ 30.4 days).
   • Quick rule of thumb:

     • If your elapsed time is clearly weeks but your outputs frequently fall on the “within SOL” side, your sheet’s date math likely has a problem.
     • If your elapsed time is just a few days, results should consistently reflect “not expired” under a default-only model.

4. Verify the “years vs days” conversion

   • If your spreadsheet uses days elapsed:

     • confirm you convert to years once and only in the step used for the SOL comparison.
   • If your spreadsheet uses years elapsed:

     • ensure it uses the same year basis as your logic (small differences like 365 vs 365.25 can matter on the margin).

5. Watch for threshold comparisons

   • Borderline flips often come from:

     • >= vs >
     • <= vs <
   • The checker helps you catch upstream date math so you’re not forced to “fix” outcomes by arbitrarily changing thresholds.

Practical checklist before you calculate a batch:

If you want a faster path, start with 5 rows you’re confident about. Compare your spreadsheet output vs. DocketMath output. Once the obvious rows agree, scale up.

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