Spreadsheet checks before running small claims fees and limits in Texas

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Run this scenario in DocketMath using the Small Claims Fee Limit calculator.

A spreadsheet that calculates Texas small claims fees and limits is only as reliable as its inputs, units, and logic paths. DocketMath’s small-claims-fee-limit checker is designed to catch the kinds of errors that quietly skew totals—especially when you’re converting dates, applying caps, or stitching together fee schedules.

Use the checker to sanity-check things like:

  • Wrong date basis

    • Mixing up “filing date” vs. “incident date”
    • Converting dates to numbers incorrectly (e.g., treating MM/DD/YYYY as DD/MM/YYYY)
    • Off-by-one errors from time zones or midnight cutoffs
  • Mismatched units

    • Days vs. months vs. years
    • Treating a “year” as 365 days when your spreadsheet uses 365.25 or vice versa
  • Incorrect conversion of the general limitations period

    • For Texas, the checker’s default baseline comes from Texas Code of Criminal Procedure, Chapter 12.
    • The general period your checker logic should use is 0.0833333333 years (≈ 1 month).
    • If your spreadsheet converts that to days incorrectly (for example, using the wrong day conversion factor), thresholds can shift so the “gate” behaves earlier or later than you intended.

    Important: Don’t assume “general” rules automatically cover every claim type. In the provided briefing notes, no claim-type-specific sub-rule was found, so the checker should be run using this general/default period only, not as a substitute for a claim-type rule.

  • Fee and limit logic branching bugs

    • IF statements that invert conditions (e.g., “if under cap” vs “if over cap”)
    • Missing rows because of filtering (common when a sheet “helpfully” hides blanks)
    • Double-counting when a fee component is included in both a base amount and a line item
  • Formula drift

    • Copy/paste that changes cell references (e.g., absolute vs relative references)
    • Hardcoded numbers replacing a lookup table
    • Sorting a data range without re-synchronizing formulas

If you want the checker to be maximally effective, make sure your spreadsheet inputs are consistent—especially date fields and any cap/limit thresholds you feed into the model.

Quick input/output checks to look for

What you inputCommon errorWhat the checker should flag
DatesWrong format or basisLimit window shifts by ~1 month or more
AmountsUsing cents vs dollarsFees become 100× too high or too low
Cap/thresholdWrong variable wired to the IFOutput jumps to max cap unexpectedly
Period in yearsBad conversion from years to daysTime-based gate flips too early/late

Gentle note: This is a spreadsheet QA sanity check—not legal advice. If you’re unsure which limitation period applies to a specific situation, confirm with a qualified professional.

When to run it

Run DocketMath’s checker at four predictable points in your workflow. Timing matters because some mistakes are easier to catch before you aggregate totals.

  • Before you populate the final spreadsheet

    • Confirm date parsing and conversions.
    • Verify that any year-to-day conversion for the general/default SOL period matches your sheet’s intended logic.
    • This is where you stop “structural” errors from entering the dataset.
  • After you update inputs, but before recalculating totals

    • If you add a batch of cases (or refresh an import), run the checker immediately.
    • It’s faster to catch a wrong column mapping than to debug after the totals look “plausible.”
  • After you confirm fee schedule lookups

    • If the model uses tables (e.g., amount buckets), test a few boundary values:
      • Just below a threshold
      • Exactly at a threshold
      • Just above a threshold
  • Right before you rely on the results

    • This final pass is about catching copy/paste drift, filter side effects, and stale cached values.

For Texas, your timing logic should align to the general/default baseline drawn from Texas Code of Criminal Procedure, Chapter 12 (source: https://statutes.capitol.texas.gov/Docs/CR/htm/CR.12.htm) and the provided general period: 0.0833333333 years (≈ 1 month).

Pitfall: If your spreadsheet logic assumes a different “general period” than the checker uses, you may see outputs that look internally consistent while still not matching your intended rule set.

Try the checker

Give DocketMath small-claims-fee-limit a workout on a small slice of your sheet before you run it at scale. The goal isn’t to “get a correct answer” immediately—it’s to confirm the spreadsheet mechanics are sane.

Suggested 10-minute test plan

  1. Pick 3 rows representing different scenarios:
    • One well within the time window
    • One near the boundary (around the ~1-month general/default window)
    • One outside the time window
  2. Ensure the spreadsheet has consistent date formatting (ideally true date values, not text).
  3. Confirm your fee inputs use consistent currency units (dollars vs cents).
  4. Run the checker: /tools/small-claims-fee-limit
  5. Compare outputs across the 3 rows:
    • If changing dates by a few days flips the result, inspect date conversion first.
    • If changing amounts has no effect, inspect lookup keys and formula references first.

If the checker returns warnings, prioritize in this order

  1. Date parsing / time-window conversion
  2. **Branching logic (caps/limits/IF conditions)
  3. **Units (currency and days/years)
  4. Table lookups and row alignment

What “sanity-checking” should look like in practice

A spreadsheet that passes basic sanity checks typically shows behavior like:

  • Output changes smoothly with amount inputs (no unexplained jumps).
  • Boundary tests behave as expected:
    • Below threshold → not capped
    • At threshold → capped (or “capped-equivalent”)
    • Above threshold → capped
  • Time gating behaves consistently with the general/default ~1-month period and does not fluctuate wildly from a small date shift.

If you’re unsure how your sheet is computing the time window, do one manual verification for a single row (compute the underlying date difference once), then align the spreadsheet’s conversion steps to match the checker’s approach.

Direct CTA

Try it here: /tools/small-claims-fee-limit
If you also want related tools, browse: /tools

Related reading