Kentucky · structured settlement

How to run Structured Settlement in DocketMath for Kentucky

By DocketMath TeamJune 4, 20266 min read
Abstract background illustration for How to run Structured Settlement in DocketMath for Kentucky
Under review

missing_or_unverified_packet

Step-by-step

Here’s a practical workflow for running a Structured Settlement calculation in DocketMath for Kentucky (US-KY), using jurisdiction-aware rules tied to KRS § 454.430 to § 454.435 (Kentucky’s Structured Settlement Protection Act).

Note: This guide focuses on how to run the calculation in DocketMath and what jurisdiction constraints commonly matter for structured settlement planning in Kentucky. It’s not legal advice and doesn’t replace reviewing the statute or any court-required order for transfers.

1) Open the Structured Settlement calculator

  1. Go to the tool page: /tools/structured-settlement
  2. Choose the jurisdiction: Kentucky (US-KY)
  3. Confirm the tool is set to use the Structured Settlement Protection Act framework from KRS § 454.430 to § 454.435.

2) Enter the structured settlement inputs

DocketMath’s structured settlement calculator typically centers on modeling the payment stream (timing + amounts). Use the tool’s input fields to represent your scenario:

  • Payment frequency (e.g., monthly, annual)
  • Start date (the first payment date)
  • Number of payments or an end date
  • Payment amount (and whether amounts are level or vary)
  • Discount rate / interest assumptions (use the assumptions you’re comfortable documenting for the record)

If DocketMath displays additional modes (for example, converting to a lump sum or showing present value), select the mode that matches what you’re trying to quantify and fill the fields that correspond to your scenario.

3) Use Kentucky jurisdiction constraints (authorization for transfers)

Kentucky law governs certain transfers of structured settlement payment rights.

Under KRS § 454.430 to § 454.435, Kentucky generally prohibits transferring structured settlement payment rights unless the transfer is authorized in advance in a final court order of a court of competent jurisdiction, based on the statute’s required express findings. In other words, the key “gate” is not the spreadsheet math—it’s whether a court order exists that meets the statutory requirements.

In DocketMath, this usually means:

  • keeping the jurisdiction set to Kentucky (US-KY) so your work is presented in the correct jurisdiction context (especially if the tool changes how it labels assumptions or applies jurisdiction-aware logic).

Warning: Kentucky’s Structured Settlement Protection Act is a restriction on transfer authorization, not a computational formula. If your scenario involves a transfer of payment rights, the statute’s requirement for a final court order with express findings under KRS § 454.430–454.435 is the legal gating item.

4) Confirm the “default period” behavior

Some structured settlement calculations require a time horizon or a “period” setting.

In this Kentucky configuration, no claim-type-specific sub-rule was found. That means:

  • Use the general/default period behavior unless the tool explicitly offers a different option tied to a claim type.

If the calculator shows a “period” selector, choose the general/default option rather than assuming there is a special claim-type-driven rule.

5) Review outputs and export a scenario

After submitting inputs, review what DocketMath produces in your chosen mode:

  • Payment schedule (confirm dates and payment amounts)
  • Valuation output (such as present value, depending on the selected calculator mode)

Then save/export your scenario so you can compare versions:

Practical workflow

  • Run Scenario A with your initial assumptions.
  • Run Scenario B changing one variable at a time (for example, discount rate or start date).
  • Compare outputs side-by-side so it’s clear what drove the change.

6) Map outputs to Kentucky timing considerations

DocketMath can’t determine whether a transfer is legally permissible under Kentucky law—it can help you quantify the numbers that are often referenced in case discussions and documentation.

Create a short internal “calculation narrative” noting:

  • the inputs you used (frequency, dates, payment amounts, discount rate)
  • the resulting schedule
  • the computed output shown by DocketMath (e.g., present value)
  • whether your scenario is strictly valuation/scheduling or is intended to support a transfer, since KRS § 454.430–454.435 imposes transfer authorization requirements

Common pitfalls

Avoid these common issues when running Structured Settlement in DocketMath for US-KY:

  • Using the wrong jurisdiction

    • If you leave the jurisdiction set to another state, you may miss Kentucky-specific structured settlement transfer constraints referenced under KRS § 454.430 to § 454.435.
  • Assuming a claim-type-specific rule exists

    • As noted in Step 4: No claim-type-specific sub-rule was found. Use the general/default period unless the tool clearly indicates a claim-type-specific option.
  • Mismatching dates

    • Payment schedule errors often come from:
      • confusing the start date input with the actual first payment date
      • off-by-one errors caused by month/quarter alignment with the selected frequency
  • Conflating valuation with transfer authorization

    • DocketMath can compute values, but Kentucky law controls whether a transfer of payment rights is allowable without the required procedural step.
    • For transfers, authorization in advance via a final court order with express findings under KRS § 454.430–454.435 is the critical legal requirement.
  • Changing multiple inputs at once

    • If you update rate, dates, and payment pattern simultaneously, you lose the ability to explain why outputs changed between runs.

Try it

Try a Kentucky run directly from the tool:

  1. Open /tools/structured-settlement
  2. Set jurisdiction to Kentucky (US-KY)
  3. Enter:
    • payment frequency
    • start date
    • payment amount (and any variation)
    • number of payments or end date
    • discount rate / interest assumption
  4. Run the calculation and do two quick checks:
    • Schedule sanity check: confirm the payment dates align with the frequency starting from your first payment date.
    • Sensitivity check: rerun after changing one input (commonly the discount rate) to see how valuation shifts.

If you’re documenting assumptions for a record, capture:

  • what discount rate you used and why (or what source/assumption you relied on)
  • the schedule produced
  • the valuation output displayed by DocketMath

Pitfall to watch: If valuation is sensitive to the discount rate, make sure your discount-rate assumption is defensible and consistently applied—Kentucky’s statutory transfer restrictions focus on court authorization, but the numeric computation still needs clear inputs.

Related reading


Run the numbers for your matter against the verified rule for this jurisdiction.

Calculate now