How to run Structured Settlement in DocketMath for Kentucky

How to run Structured Settlement in DocketMath for Kentucky

6 min read

Published July 4, 2025 • Updated April 23, 2026 • By DocketMath Team

Article claim inventory in progress

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 walks you through running a Structured Settlement calculation in DocketMath for Kentucky (US-KY) using jurisdiction-aware rules. You’ll see exactly what to enter, how Kentucky’s default time-based logic is applied in this workflow, and what outputs to expect. (This is general guidance for using the calculator—not legal advice.)

1) Start your Structured Settlement run

  1. Open DocketMath’s Structured Settlement tool: /tools/structured-settlement.
  2. Select the jurisdiction as Kentucky (US-KY).
  3. Confirm the calculator is in Structured Settlement mode (not a different calculator type).

2) Enter the settlement payment schedule

In the structured settlement section, build the payment stream you want to evaluate. Use the same structure you expect in the settlement documents, such as:

  • Number of payments (or an end date, if that’s what the UI supports)
  • Payment frequency (monthly, quarterly, annual—whatever matches the proposed agreement)
  • Payment amounts
  • Any lump sums (if included in the deal)

If your schedule includes multiple phases (for example, higher payments for years 1–3, then lower payments later), enter each phase as a separate block/line—whatever the DocketMath interface allows (e.g., multiple payment lines or phase entries). Avoid collapsing phased payments into a single “average” unless the agreement truly treats it that way.

3) Provide the discount / interest assumptions

Structured settlement math depends on the time value of money. In DocketMath, you’ll typically provide inputs such as:

  • Discount rate (often an annual rate you choose)
  • Compounding method (if the tool prompts for it)
  • Timing convention (if the tool prompts—e.g., start vs. end of period)

How inputs change outputs (quick intuition):

  • A higher discount rate generally lowers the present value (PV) of future payments.
  • A lower discount rate generally raises PV because each future dollar is discounted less.

If the tool has toggles or formatting options (for example, percent vs. decimal), enter the value in the format the UI expects.

4) Apply Kentucky “general/default period” rules (jurisdiction-aware)

DocketMath will apply time-based jurisdiction logic for Kentucky. For this workflow, the calculator uses the general/default limitations period, because no claim-type-specific sub-rule was found.

Use the following values:

  • General SOL Period: 5 years
  • General Statute: KRS 500.020

In other words, the tool’s baseline time guidance here is the 5-year default tied to KRS 500.020. If the DocketMath UI provides an option to select an alternative rule or category, only use it if you are confident it matches your exact scenario; otherwise, this workflow relies on the general/default period above.

Important note: This content applies the 5-year general/default period only because no claim-type-specific sub-rule was identified for this workflow. If your matter involves a specific limitations category, confirm whether the DocketMath structured settlement workflow supports that category (and only then switch away from the default).

5) Run the calculation and review results

Once your payment schedule and discount assumptions are entered, run the calculation. DocketMath will compute structured settlement figures based on:

  • Your payment schedule
  • Your discount/interest assumptions
  • Kentucky’s default time period logic in this workflow tied to KRS 500.020 (5 years general/default)

When you review results, look for categories such as (names may vary slightly in the interface):

  • Total nominal value (sum of scheduled payments)
  • Present value (PV) (discounted value based on your rate and timing assumptions)
  • Payment-by-payment breakdown (if shown)
  • Any time-based overlays connected to the 5-year general/default period (as applicable in the workflow)

6) Validate by stress-testing inputs (quick checks)

Before treating results as final, do a few fast “sanity checks” to catch data entry issues:

  • Single-payment test: Temporarily reduce to one payment and verify PV responds correctly (a farther-future payment should produce a lower PV).
  • Rate sensitivity: Change the discount rate by a small step (e.g., +1%) and confirm PV moves in the expected direction (higher rate → lower PV).
  • Frequency consistency: Confirm monthly vs. annual frequency matches the amounts you entered. A mismatch can distort both nominal totals and PV.

These checks often catch mistakes faster than re-reading every output line.

Common pitfalls

Structured settlement calculations typically go wrong because of input mismatches, not because of “bad math.” Use this checklist to avoid the most common issues when running US-KY in DocketMath.

  • Make sure Kentucky (US-KY) is selected before running.
  • For this workflow, Kentucky is handled using the general/default 5-year period tied to KRS 500.020, because no claim-type-specific sub-rule was found.
  • If payments are due at the start of each period but you enter them as end-of-period (or vice versa), PV can shift materially.
  • Example: if the agreement says $5,000 monthly but you enter $5,000 annually (or select the wrong frequency), totals and PV will both be incorrect.
  • If payment amounts change over time, don’t combine everything into one line unless that matches the agreement’s structure.
  • Confirm whether the tool expects a decimal (0.05) or a percent (5) and keep compounding/timing consistent with the UI.
  • Even if results look reasonable, changing the rate slightly (+/-1%) helps confirm the PV behavior is stable and directionally correct.

Pitfall to watch: The most misleading outputs can look “plausible” while using the wrong discount/interest convention (rate format, compounding, or start/end timing). When in doubt, run the one-change tests above.

Try it

Use this quick workflow to run a first pass in DocketMath for Kentucky (US-KY):

  1. Select US-KY jurisdiction.
  2. Enter a simple schedule:
    • Example structure: 24 monthly payments with a single fixed amount (adjust to match your scenario).
  3. Choose a discount rate:
    • Pick one rate and run the calculation.
  4. Confirm Kentucky default time logic is shown as:
    • **5 years under KRS 500.020 (general/default)
  5. Review outputs:
    • Total nominal value
    • **Present value (PV)
    • Any schedule timing / breakdown elements

Then repeat with one change to understand sensitivity:

  • Keep the schedule fixed, change the discount rate slightly, and observe how PV changes.
  • If your scenario includes a lump sum or a different payment start date, add/adjust that item and confirm PV reacts in the expected direction.

This “first run + one change” approach is the fastest way to confirm your inputs align with how DocketMath is computing PV and applying Kentucky’s default 5-year limitations guidance in this workflow.

Related reading