Worked example: Damages Allocation in Kentucky

7 min read

Published April 15, 2026 • By DocketMath Team

Example inputs

Run this scenario in DocketMath using the Damages Allocation calculator.

This worked example shows how DocketMath’s damages-allocation calculator can translate a mixed-damages demand into separate line items using Kentucky’s default rules. I’ll also show how the result changes when you adjust key inputs.

Primary CTA: Use the tool here: /tools/damages-allocation

Jurisdiction-aware timing rule used (Kentucky)

Because no claim-type-specific sub-rule was found for this scenario, the calculator uses Kentucky’s general/default statute of limitations:

  • General SOL period: 5 years
  • Governing statute: KRS 500.020

Note: This example uses Kentucky’s general SOL period (5 years) under KRS 500.020 because no claim-type-specific limitations rule was identified for the scenario. If a more specific Kentucky limitations provision applies to your claim, the allocation window and amounts may differ.

Scenario

Assume a business dispute where the plaintiff seeks three categories of damages:

  1. Past wage loss (by pay period/month)
  2. Reimbursement expenses (e.g., receipts for materials)
  3. Future/prospective damages (estimated for upcoming months)

We’ll compute an allocation that reflects a typical approach: splitting amounts into what falls within the limitations lookback window versus what falls outside it, using the date-based logic supported by the damages-allocation tool.

Key dates

  • Date of alleged last injury / triggering event: January 15, 2020
  • Date suit was filed: January 20, 2025

With a 5-year general SOL period under KRS 500.020, the limitations “lookback” window (general rule) begins January 20, 2020 (5 years prior to filing).

So, for a general SOL lookback framing in this example:

  • Amounts attributable to on/after Jan. 20, 2020 are treated as within the window.
  • Amounts attributable to before Jan. 20, 2020 are treated as outside the window.

Damages input values (what you’d enter into DocketMath)

Damages categoryHow the timeline is representedTotal claimedPeriod coverage
Past wage lossmonthly amounts$60,000Jan 2020 – Dec 2020
Reimbursement expensesdated list summarized into totals by month$24,000Dec 2019 – Feb 2020
Future/prospective damagesprojected amount beyond filing window$36,000Jan 2025 – Dec 2025

Monthly breakdown (compressed)

To keep this example readable, assume the calculator’s inputs include this monthly pattern.

  • Wage loss: $5,000 per month for Jan–Dec 2020
    • 12 months × $5,000 = $60,000
  • Reimbursement expenses: $8,000 per month for Dec 2019–Feb 2020
    • 3 months × $8,000 = $24,000
  • Future damages: $3,000 per month for Jan–Dec 2025
    • 12 months × $3,000 = $36,000

Inputs summary (date-sensitive elements)

These are the “raw” timeline facts the allocation depends on:

  • Wage loss months: Jan 2020 through Dec 2020
  • Expense months: Dec 2019 through Feb 2020
  • Future/prospective months: Jan 2025 through Dec 2025
  • Filing date: Jan 20, 2025

Practical tip: Before running the calculator, align the damages timeline (especially monthly buckets) with the date logic you intend to model for the limitations lookback.

Example run

Below is one way the DocketMath damages-allocation calculator can allocate totals using the Kentucky general SOL window under KRS 500.020 (5 years). (This is an example of modeling; it’s not legal advice.)

Run the Damages Allocation calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Step 1: Identify the limitations window

  • Filing date: Jan 20, 2025
  • Lookback start (5 years): Jan 20, 2020
  • Window end: Jan 20, 2025 (used here as the “within lookback” cutoff)

Step 2: Allocate each category by timeline overlap

1) Past wage loss ($60,000)

  • Covered months: Jan 2020–Dec 2020
  • Window start: Jan 20, 2020

Because this example models wage loss as monthly buckets and assumes the overlap method includes any bucket that overlaps the window at the month level, Jan 2020 is treated as included for modeling simplicity.

  • Included (within window): Jan–Dec 2020 = 12 months
  • Excluded (outside window): $0

Allocated past wage loss (within window): $60,000
Excluded past wage loss: $0

2) Reimbursement expenses ($24,000)

  • Covered months: Dec 2019–Feb 2020
  • Window starts: Jan 20, 2020

Here we apply a boundary-sensitive monthly approach for demonstration:

  • Included months: Feb 2020 only
  • Excluded months: Dec 2019 and Jan 2020

Using the stated expense rate of $8,000/month:

  • Included (Feb 2020): $8,000
  • Excluded (Dec 2019 + Jan 2020): $16,000

Allocated reimbursement expenses (within window): $8,000
Excluded reimbursement expenses: $16,000

3) Future/prospective damages ($36,000)

This category is prospective (projected after the filing date). In many damages-allocation workflows, you treat these amounts as not being “older than” the lookback in the same way as past categories.

For this example run, we treat future/prospective damages as fully allocable:

  • Included: $36,000
  • Excluded: $0

Allocated future/prospective damages: $36,000
Excluded future/prospective damages: $0

Step 3: Produce totals

Here’s how the allocation ends up at the category level:

CategoryClaimedAllocated within general SOL lookbackExcluded (general SOL lookback)
Past wage loss$60,000$60,000$0
Reimbursement expenses$24,000$8,000$16,000
Future/prospective damages$36,000$36,000$0
Total$120,000$104,000$16,000

Interpretation of the output

  • Under the assumptions used here, the main reduction comes from reimbursement expenses occurring before Jan. 20, 2020.
  • Wage loss and future/prospective damages remain fully included based on the modeling choices for this example.

If you want the output to be more conservative, you can adjust the bucket overlap logic (see Sensitivity check).

Sensitivity check

Small changes to inputs can shift what falls inside the 5-year general SOL window under KRS 500.020. This section shows how those changes affect the allocated total.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity 1: Move the filing date by 30 days

Change the filing date from Jan 20, 2025 to Dec 21, 2024.

  • New lookback start: Dec 21, 2019
  • Under the same monthly-bucket assumptions for expenses:
    • Dec 2019 now overlaps the window
    • Jan 2020 and Feb 2020 remain overlapping

Recalculate reimbursement expenses:

  • Included: Dec 2019 + Jan 2020 + Feb 2020 = 3 months × $8,000 = $24,000
  • Excluded: $0

Allocated total increases from $104,000 to $120,000
(Change: +$16,000)

Sensitivity 2: Keep the filing date, but adjust the “trigger” date you align to buckets

If the “last injury / triggering event” is actually earlier or later (e.g., Nov 30, 2019 instead of Jan 15, 2020), your bucket alignment may shift—especially for categories that straddle the start of the lookback window (here, reimbursement expenses).

Practical approach in DocketMath:

  • Keep claimed totals the same.
  • Re-run the allocation using the alternate trigger/alignment input.
  • Watch the reimbursement expenses line first, because it’s closest to the window boundary.

Sensitivity 3: Change the expense bucket inclusion method at the boundary

The biggest modeling choice in this example is whether January 2020 is treated as “within the window” when the window starts on Jan 20, 2020.

Two alternate expense allocation outcomes:

Expense methodIncluded monthsAllocated expenses
Strict boundary (used above)Feb 2020 only$8,000
Overlap (more generous)Jan 2020 + Feb 2020$16,000

Effect on the total:

  • Strict: $104,000
  • Overlap: $112,000
    (increase of +$8,000)

Pitfall: Monthly-bucket time modeling can create boundary effects around the SOL cutoff. If your case depends heavily on those edge months, validate how your timeline is mapped into buckets.

Related reading