Spreadsheet checks before running small claims fees and limits in Delaware

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Spreadsheets are great for modeling Delaware small-claims scenarios—until a single wrong cell, swapped column, or misapplied statute turns a court-ready number into a silent error. DocketMath’s small-claims-fee-limit checker is designed to sanity-check the logic before you rely on outputs for fees, totals, or eligibility calculations.

Here are the most common spreadsheet issues the checker is built to detect or prevent:

  • Wrong statute inputs

    • If your sheet assumes an incorrect deadline rule, the downstream “eligible / not eligible” outputs can flip.
    • Delaware’s general/default limitations period is 2 years under Title 11, §205(b)(3).
    • If you’re mapping a “small claims” category to a different limitations sub-rule, treat it carefully: no claim-type-specific sub-rule was found, so the default period should be used for the general SOL input.
  • Mismatched date math

    • Off-by-one issues show up when spreadsheets mix:
      • date formats (text vs date),
      • timezone/time components,
      • or different “start date” definitions (e.g., incident date vs demand date).
    • Even when the limitation is “2 years,” the calculation still needs consistent date handling.
  • Fee/limit thresholds driven by the wrong variable

    • Some sheets calculate fees based on:
      • claimed amount,
      • outstanding balance, or
      • a net figure after credits/offsets.
    • If the checker expects one input (for example, “amount in controversy” or “claimed amount”) but your sheet feeds a different number, the model may still run—but it can be logically wrong.
  • Unit confusion

    • A frequent spreadsheet failure: amounts stored as cents vs dollars.
    • Example pattern: a value entered as 1250 (meant $12.50) but treated as $1,250 can push your totals past a fee/limit threshold.
  • Cell reference drift

    • After copying formulas across rows, logic can accidentally point to the wrong column (e.g., “amount” references “days late”).
    • The checker’s goal is to catch these inconsistencies by validating key inputs and the overall relationship between inputs and outputs.

Pitfall: If your spreadsheet uses the correct formulas but one column is shifted by even one row, totals can still look plausible while producing the wrong fee/limit category. A checker helps validate the relationships, not just the final number.

When to run it

Run DocketMath’s small-claims-fee-limit checker at specific points in your workflow—especially when you’re changing dates, adjusting amounts, or importing data.

A practical checklist:

  • Before finalizing any “fee” or “limit” outputs

    • Use the checker immediately after you:
      • enter or import amounts,
      • set the governing dates (incident date, accrual/start date, or whatever your sheet uses as the SOL-relevant date),
      • define the calculation basis (claimed amount vs balance, or whatever your spreadsheet’s logic uses).
  • After every spreadsheet edit that touches assumptions

    • This includes changes to:
      • limitation period logic (e.g., anything referencing the assumed “2 years” rule),
      • fee threshold rules (e.g., if you changed the input that feeds a tier table),
      • date parsing (e.g., converting text dates to real dates).
  • When you copy the model across scenarios

    • If you’re running multiple rows/sheets for different transactions, validate at least one:
      • low-amount scenario,
      • mid-amount scenario,
      • high-amount scenario,
      • and one scenario near any threshold where behavior changes.
  • When you add new claim rows from a case management export

    • External exports commonly introduce:
      • inconsistent date formats,
      • missing values that Excel/Sheets quietly treat as blanks (which can force default logic).

To anchor the SOL logic: Delaware’s general/default limitations period is 2 years under Title 11, §205(b)(3). If your sheet tries to apply a specialized sub-rule for a category, be sure you’re not overriding that default without a clearly verified basis. Since no claim-type-specific sub-rule was found, the 2-year default should remain the governing SOL input unless you have a separately verified reason to diverge.

Try the checker

Use DocketMath to sanity-check your spreadsheet inputs before you commit to the fee/limit results. The goal isn’t just to “get a number”—it’s to verify that:

  1. The model is using the expected limitations period, and
  2. Your amounts and dates feed the fee/limit logic consistently.

Inputs to line up in your sheet

Use these as “must-match” checks for your spreadsheet setup:

  • SOL period basis

    • Default/general SOL: 2 years (Del. Title 11, §205(b)(3))
    • Apply this as the governing period unless you have a separate, verified rule for a specific claim type.
    • Because no claim-type-specific sub-rule was found, treat the 2-year default as the governing assumption.
  • Key dates used for limitations math

    • Your sheet should clearly define:
      • the start/accrual date (whatever your workflow uses),
      • the comparison/end date (often “today” or a filing date).
    • The checker will surface inconsistencies when date math doesn’t behave like a clean 2-year structure.
  • Claim amount basis used for fees/limits

    • Ensure the amount in the spreadsheet matches what your checker expects.
    • If your fee/limit tiering is sensitive to dollars, double-check:
      • dollars vs cents,
      • gross vs net,
      • whether any offsets/credits were applied.

Output behavior you should expect

When inputs align, the checker should behave predictably:

  • If the date math indicates the SOL window is not satisfied, the “eligible/not eligible” or “limitations exceeded” outcome should reflect the 2-year default timeline.
  • If the amount crosses a tier threshold, fee/limit outputs should change accordingly—without sudden flips caused by shifted cell references or swapped columns.

Gentle disclaimer: This is a spreadsheet sanity check, not legal advice, and it may not capture every case-specific nuance. But it can help prevent common “spreadsheet went wrong” failures.

Primary CTA

If you want to run the sanity-check now, start here:
/tools/small-claims-fee-limit

If your spreadsheet logic is already built, compare your sheet’s computed results against the checker’s expectations before you proceed to totals, filings, or fee estimates.

Related reading