Spreadsheet checks before running Damages Allocation in Kentucky

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a Damages Allocation workflow in Kentucky (US-KY) often means you’re about to allocate settlement proceeds, apportion fault/damages components, or compute totals by line item. The risk isn’t usually arithmetic—it’s that spreadsheets can look “right” while feeding the calculator with data that fails basic timing and eligibility checks.

DocketMath’s damages-allocation calculator can be paired with a spreadsheet pre-check so you catch these issues before you allocate anything. For Kentucky, the most common failure mode is accidentally treating claims as timely when they aren’t—especially when date fields are missing, formatted inconsistently, or tied to the wrong event.

Here’s what the spreadsheet checker is designed to flag for US-KY:

• Missing or invalid date fields

  • Blank “incident date,” “demand date,” or “filing date” cells
  • Dates stored as text (for example, 01/02/2024 entered as a string instead of a true date)

• Chronology errors

  • “Filing date” earlier than “incident date”
  • “Settlement agreement date” earlier than “demand date”
  • Any other order-of-events mismatch that breaks the timing logic

• **Wrong limitations period applied (or period not justified in the sheet)

  • Using a custom limitations period without confirming it matches your situation
  • Using Kentucky’s general/default SOL where no claim-type-specific sub-rule is established (this is the general fallback in this checker)

  Kentucky timing basis used by this checker: KRS 500.020 provides a 5-year general SOL period. No claim-type-specific sub-rule was found for this template—so the checker clearly treats the 5-year general/default period as the default for timing tests unless you adjust your inputs for a different applicable rule.

• Unit/rounding mismatches that distort allocations

  • Totals not reconciling (for example, sum of line items ≠ reported total)
  • Percentages adding up to 99.9% or 101% due to rounding or mixed precision
  • Currency formatting differences that can cause silent truncation or inconsistent numeric parsing

• “Eligibility gating” mistakes

  • An item incorrectly marked “included” when the dates suggest it’s outside the limitations period
  • A checkbox/flag not updated after you edit dates

Gentle reminder (not legal advice): This helps you validate spreadsheet integrity and timing logic, not guarantee legal outcomes. If your facts involve a different limitations rule than the general default, you should update your sheet inputs accordingly before running damages allocation.

When to run it

Run the checker before you run the Damages Allocation calculator. Two practical decision points:

1. Right after spreadsheet data entry

   • As soon as you populate dates and amounts, run the checker.
   • This catches formatting and chronology issues early—when changes are fastest.

2. After any edit that changes dates

   • If you update incident/occurrence date, demand date, or filing date, rerun the checker immediately.
   • Even a single corrected date can move an item from “included” to “excluded” under the applicable timing test.

A practical workflow that tends to work well:

• Step 1: Enter/verify all date fields using a consistent format (e.g., YYYY-MM-DD)
• Step 2: Enter damages line items and ensure totals match
• Step 3: Run the spreadsheet checker
• Step 4: Only then run DocketMath → damages-allocation
• Step 5: Reconcile outputs (totals, percentages, and excluded items)

Primary CTA to run the calculator: /tools/damages-allocation

Try the checker

Use this as a checklist while you prepare your spreadsheet for DocketMath (damages-allocation) in Kentucky (US-KY).

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Spreadsheet fields to verify (Kentucky / US-KY)

Use the following inputs as a minimum viable set so the checker can perform meaningful timing and integrity checks:

How outputs change when issues are fixed

Once the checker clears your spreadsheet, damages allocation results should become more reliable because:

• Eligibility gating becomes consistent

  • Items that were previously “included” may become “excluded” after you correct dates that fall outside the 5-year general SOL under KRS 500.020.

• Totals reconcile

  • Percentage and amount math stops drifting due to rounding/format issues.

• Less manual cleanup

  • Instead of correcting allocation problems after you see the results, you fix upstream inputs first.

One “do this first” tip

Before running anything, sort your rows by incident date (ascending). If you spot obvious chronology anomalies (like filing dates preceding incidents), fix those first—then rerun the checker.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules