Spreadsheet checks before running Damages Allocation in Connecticut

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

DocketMath’s Damages Allocation calculator turns a damages narrative into allocation-ready figures. Before you run it for Connecticut (US-CT), the spreadsheet checker helps you catch the most common mistakes that lead to allocation errors—especially mistakes that come from missed or mis-entered deadlines.

Using the general/default statute of limitations (SOL) period provided for Connecticut, the checker flags issues that can make the allocation output unreliable even if the spreadsheet “looks” correct.

Deadline risk checks (Connecticut baseline)

  • **SOL “staleness” indicators (3-year general period)
    • Connecticut’s general SOL period for the relevant civil actions baseline is 3 years under Conn. Gen. Stat. § 52-577a.
    • The checker uses this general/default period because the provided jurisdiction data contains no claim-type-specific sub-rule. In other words: 3 years is the clear baseline unless you explicitly set up different timeline logic in your workflow.

Warning: A spreadsheet can be arithmetically accurate but still be unusable if the underlying claims fall outside the governing SOL window. This checker is designed to surface those “deadline risk” issues early—so you don’t over-trust outputs that are based on stale dates.

Data quality and spreadsheet logic checks

The checker also focuses on practical spreadsheet integrity issues that frequently cause allocation math to go wrong:

  • Date-field inconsistencies

    • Flags rows with missing key dates, dates entered in inconsistent formats (text vs. date values), or inverted relationships (for example, an incident/occurrence date that appears later than the filing date, if your workflow expects the opposite).
  • Allocation math that won’t reconcile

    • Verifies totals and line-item sums.
    • Example: allocated amounts by category should reconcile to your overall damages figure, rather than diverging due to partial edits or broken formulas.
  • Unit mismatches and hidden scaling

    • Catches common spreadsheet scaling errors, such as:
      • storing percentages as 25 instead of 0.25
      • entering dollars in thousands without applying the matching scale factor
    • These errors can produce allocations that look plausible at a glance but are off by large multipliers.
  • Blank or duplicated identifiers that break row logic

    • Examples include:
      • duplicated category rows (e.g., two “Lost Wages” lines that should not both exist)
      • missing category labels
      • identifiers (claimant/borrower names, defendants, or incident keys) duplicated across distinct incidents or periods, which can cause rows to be grouped incorrectly.
  • Zero/negative inputs that create misleading outputs

    • Highlights entries that produce negative allocations or nonsensical distributions, often caused by:
      • sign errors (minus vs. plus)
      • missing factors
      • formulas that subtract when they should multiply or allocate proportionally.

Connecticut SOL baseline the checker uses

Because the provided jurisdiction data identifies only the general/default SOL rule, the checker uses 3 years as the baseline unless you explicitly choose different timeline logic in your workflow.

When to run it

Run the spreadsheet checker before you run DocketMath’s Damages Allocation calculation, and run it again after changes that could affect the results. Think in terms of checkpoints: one before calculations, and one any time you modify the date logic or the allocation structure.

Checkpoint moments (practical workflow)

  1. Before the first Damages Allocation run

    • Do this right after you export, compile, or paste your damages inputs into the spreadsheet.
    • Goal: prevent “garbage-in” data from generating confident-looking allocation outputs.
  2. Immediately after you adjust dates or reopen discovery

    • If you change any of the key date inputs your workflow uses (for example):
      • incident/occurrence date
      • accrual date
      • demand or notice date (if applicable in your workflow)
      • filing date
    • Goal: update the SOL staleness signal and reduce the risk of date-driven allocation distortions.
  3. After you change allocation categories or add line items

    • If you:
      • add a new category (e.g., “medical expenses”)
      • revise percentage splits
      • update multiple defendants/periods
    • Goal: ensure totals, scaling, and category integrity still reconcile.

Quick in-spreadsheet checklist

Use this while you work:

Note: This is not legal advice. It’s a data-quality and workflow guide to help you reduce avoidable spreadsheet issues.

Try the checker

If you want to use DocketMath efficiently, the workflow is:

  1. Open the DocketMath Damages Allocation tool page:

  2. Run the spreadsheet-checker step first (the “spreadsheet-checker” workflow):

    • Load your damages inputs
    • Review the flagged items
    • Fix the issues (dates, scaling factors, category totals, and identifiers)
    • Re-run until the integrity checks are clean
  3. Run the Damages Allocation calculation after the checker passes

    • Then do a quick “sanity pass”:
      • Confirm allocation totals match your master damages figure
      • Confirm the SOL baseline assumption aligns with your case timeline assumptions (3-year general SOL baseline)

Inputs that most often change outputs (what to watch for)

To keep results predictable, focus on the inputs the checker is most likely to link to allocation instability:

  • Date inputs

    • Shifting the incident/accrual date by weeks can change whether dates fall within/outside the 3-year general baseline signal.
  • Scaling inputs

    • A percent entered as 25 instead of 0.25 can inflate allocations dramatically.
  • Category completeness

    • Adding categories without updating reconciliation totals typically creates mismatches and unreliable allocations.
  • Sign conventions

    • Negative entries can propagate through totals and produce distorted distributions—even if the row-level entries seem intentional.

Related reading