How to run Settlement Allocator in DocketMath for Kentucky
6 min read
Published December 5, 2025 • Updated April 23, 2026 • By DocketMath Team
Trust release 4
This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.
Step-by-step
This guide shows how to run Settlement Allocator in DocketMath for Kentucky (US-KY) using jurisdiction-aware rules, including the default Kentucky statute of limitations used when a more specific claim-type rule isn’t available.
Note (important): For Kentucky, the jurisdiction data provided only includes a general/default limitations period of 5 years under KRS 500.020. No claim-type-specific sub-rule was identified, so Settlement Allocator should rely on the general rule rather than a narrower carve-out.
1) Open the tool and confirm the calculator
- Open the tool here: Settlement Allocator.
- If the tool prompts for jurisdiction, choose:
- Kentucky
- jurisdiction code: US-KY
- Confirm you’re in the Settlement Allocator calculator mode (not a different calculator).
If you’re arriving from a blog page, start from the tool link above to ensure the correct calculator loads first.
2) Enter settlement and allocation inputs
Settlement Allocator typically asks for the settlement context and how you want the settlement amount distributed. Use the available fields to enter:
- Settlement total (gross):
The total amount you plan to allocate. - Allocation buckets (if enabled in the UI):
These are the categories or “buckets” you want the tool to distribute across (for example, different damages components). - Timeline anchors:
- Date of event / accrual date (the earliest relevant start date you’re using)
- Settlement date (the date you’re measuring the allocation against)
- Allocation weights or proportions (if the UI supports them):
- If weights/factors are provided, enter your assumptions directly.
- If the tool offers defaults, you can keep them for a baseline run and adjust after you review the output.
Practical tip: If you’re unsure what “accrual date” means in the tool context, use the earliest date you believe starts the clock for the claim as you’re modeling it—then test alternatives in “Try it.”
3) Confirm the limitations rule used for Kentucky (default period)
After you enter your dates (or before you run), check whether the tool shows which limitations rule it applied.
For Kentucky in this setup:
- General SOL Period: 5 years
- Authority: KRS 500.020
Because no claim-type-specific sub-rule was found in the provided Kentucky jurisdiction data, the tool should apply the general/default 5-year period rather than a cause-of-action-specific period.
4) Run the calculation
Click Calculate (or the equivalent action).
Then review:
- Allocated results (per bucket, if buckets are enabled)
- Any timing/feasibility indicators the tool provides (some calculators may flag whether the model is sensitive to whether amounts could be affected by limitations)
- If available, a used-SOL summary showing that the 5-year period under KRS 500.020 was used
5) Interpret outputs: how changing inputs affects results
Use these patterns to understand what the tool is doing and how results move when you adjust inputs.
- Changing the date of event / accrual date
- Affects the time elapsed relative to the settlement date.
- If the tool models limitations sensitivity, longer elapsed time may shift allocation away from buckets treated as less likely to survive under the limitations logic.
- Changing the settlement date
- Also changes elapsed time (because the distance between dates changes).
- Changing bucket weights or category assumptions
- Directly changes the share each bucket receives.
- If timing logic interacts with bucket outcomes, the tool may further adjust shares based on the limitations-based behavior.
- Changing the settlement total
- Usually scales allocated amounts proportionally, assuming the same dates, weights, and modeling logic.
Sanity check: If you keep dates and weights constant but halve the settlement total, the allocated totals should typically come out about half as well.
Gentle disclaimer: A settlement allocator is structured modeling based on your inputs and the tool’s jurisdiction settings. It is not legal advice and shouldn’t be treated as a determination of liability or final statute-of-limitations outcomes.
6) Save or export your output (if available)
If DocketMath offers export options (for example, download, PDF, or CSV), use them to:
- Preserve the exact inputs and results for your scenario
- Compare multiple runs (e.g., “earliest plausible accrual” vs. “latest plausible accrual”)
Common pitfalls
Most issues when running Settlement Allocator in Kentucky come from date inputs, jurisdiction selection, or assuming a claim-type-specific SOL rule exists when only a general rule was provided.
- missing a required input
- using a stale rate or rule
- ignoring calendar or holiday adjustments
- skipping documentation of assumptions
Pitfalls to watch for
- Wrong jurisdiction selected
- If the tool is not set to Kentucky (US-KY), the limitations logic may not use KRS 500.020 (5 years).
- Assuming a claim-type-specific SOL rule is available
- Your jurisdiction data includes only:
- General SOL Period: 5 years
- KRS 500.020
- If you enter claim-type details in the UI (if offered) without a corresponding claim-type-specific SOL sub-rule being present in the jurisdiction setup, the tool should still fall back to the general/default rule.
- Swapping dates
- Entering the settlement date into the event/accrual date field (or vice versa) can shift elapsed time by years and produce misleading allocation changes.
- Changing multiple assumptions at once
- If you adjust dates, weights, and bucket amounts in the same run, it becomes hard to identify what caused output changes.
- Relying on a single run
- If the accrual/event date is uncertain, run at least two reasonable scenarios:
- earliest plausible accrual date
- latest plausible accrual date
Then compare how allocations and any SOL-related indicators change.
Quick checklist before you calculate
Try it
Use this quick workflow to generate your first Kentucky baseline run in DocketMath:
- Open Settlement Allocator.
- Set jurisdiction to Kentucky (US-KY).
- Enter:
- a settlement total (the amount to allocate),
- an event/accrual date (your best-supported starting point),
- a settlement date.
- Leave allocation buckets at defaults for a baseline run (if you’re not sure what to change yet).
- Run the tool and verify the limitations basis shows:
- General SOL Period: 5 years
- KRS 500.020
- Run a second scenario by adjusting the event/accrual date by a meaningful interval (for example, 90–180 days) and observe:
- whether bucket allocations shift,
- whether any SOL-related flags or indicators change.
If the output changes a lot from a small date shift, pause and double-check:
- that dates are entered into the correct fields, and
- that the tool is still indicating the Kentucky rule is KRS 500.020 (general 5-year).
Tip: When troubleshooting, change one input at a time—typically the accrual/event date or settlement date—so you can see what actually drives the results.
