How to run Structured Settlement in DocketMath for Wisconsin

How to run Structured Settlement in DocketMath for Wisconsin

6 min read

Published January 4, 2026 • Updated April 23, 2026 • By DocketMath Team

Verification issue found

Trust release 4

This page includes a legal claim or source that failed the current primary-source review.

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

Structured Settlement calculations in DocketMath help you model how future payments and purchase options can affect a settlement’s present value and timing. This walkthrough shows how to run a Wisconsin (US-WI) structured settlement workflow using jurisdiction-aware rules—with Wisconsin’s default statute of limitations (SOL) period applied as the governing timeline assumption.

Note: This article explains how to run the workflow in DocketMath and which Wisconsin default timeline rule the calculator uses. It’s not legal advice and doesn’t replace case-specific review.

1) Start the Structured Settlement tool

  1. Open DocketMath and navigate to:
    • /tools/structured-settlement
  2. Select Jurisdiction: Wisconsin (US-WI).
  3. Confirm the calculator mode is Structured Settlement (not a general “present value” or “annuity” mode, if you see multiple options).

2) Enter the settlement payment structure

Provide the inputs that describe the payment stream. DocketMath typically expects items such as:

  • Payment type (e.g., periodic payments vs. a lump sum conversion)
  • Number of installments or payment schedule
  • Payment amount(s) for each installment (or a single recurring amount)
  • Start date (or “first payment timing”)
  • Payment frequency (monthly, yearly, etc., depending on what the interface offers)

If the structure includes multiple phases (for example, higher payments early on), enter each phase as its own schedule segment if the tool supports segments.

3) Enter valuation assumptions (discounting)

Most structured settlement models require a time-value-of-money assumption. In DocketMath, that usually appears as inputs like:

  • Discount rate (annual)
  • Compounding convention (if selectable)

How this affects outputs:

  • A higher discount rate generally reduces present value of future payments.
  • A lower discount rate generally increases present value.

4) Apply Wisconsin’s default SOL timeline rule (jurisdiction-aware)

For Wisconsin, DocketMath uses the general/default SOL period when no claim-type-specific sub-rule is identified.

Important constraint for the workflow:
Your jurisdiction data indicates no claim-type-specific sub-rule was found, so the calculator must rely on this default/general period:

  • If the tool asks for a “limitation period,” choose 6 years for Wisconsin under Wis. Stat. § 939.74(1).
  • If the tool asks for a “time horizon,” set it to 6 years unless you have a reason and documentation to depart from that default assumption (DocketMath won’t infer exception logic automatically from the calculator screen).

5) Set the “as-of” date and connect it to timing outputs

To make the calculation consistent, choose:

  • As-of date (the date you’re treating as the valuation date), and
  • Ensure it aligns with your payment start date and the 6-year SOL horizon applied above.

How this affects outputs:

  • If payments begin after the as-of date, present value will shift depending on how far away the payments are.
  • If DocketMath displays a timeline banding the “SOL window,” shifting the as-of date can change which payments are counted “inside” the model’s limitation horizon.

6) Run the calculation and review results

After clicking Calculate, review the output sections DocketMath generates. Typical structured settlement results include:

  • Present value of the scheduled payments (based on discounting)
  • Payment timeline (dates and amounts)
  • Discounted totals (if the tool shows both undiscounted and discounted totals)
  • Any SOL-window overlays (if the tool uses the limitation period to frame the model)

If the output includes a summary table, capture the key figures:

  • Total undiscounted payout
  • Total discounted present value
  • Any “horizon” totals (payments in/around the limitation window)

7) Iterate with scenario changes (inputs ↔ outputs)

Structured settlements are usually scenario-driven. Use DocketMath’s calculator controls to test:

  • Earlier vs. later start dates
  • Different payment amounts
  • Alternative discount rates (e.g., 3%, 4%, 5% if the tool permits)
  • Different frequency (monthly vs. annual)

A good practice is to change one input at a time so you can interpret what caused the output to move.

Common pitfalls

Below are operational mistakes that repeatedly affect structured settlement outputs in DocketMath when using Wisconsin’s default SOL rule.

Ensure US-WI is selected. A mismatch can alter the limitation period and timeline logic.

Your provided jurisdiction data states: no claim-type-specific sub-rule was found, so the workflow should use the general/default 6-year period from Wis. Stat. § 939.74(1).

Even if the payment stream is entered correctly, an inconsistent as-of date can distort which payments fall within the modeled horizon.

If DocketMath lets you choose compounding or time basis, make sure it matches how you intend to interpret discounting. Small convention differences can materially affect present value.

If you have multiple phases (e.g., year 1–3 payments differ from year 4+), enter them as segments if the tool supports it. Otherwise, totals can be off.

Warning: The SOL window you apply in the model is a default timeline assumption based on Wis. Stat. § 939.74(1). If your fact pattern involves a different limitations theory, DocketMath won’t automatically “discover” it from the inputs on-screen.

Try it

Use this quick “sanity check” path inside DocketMath /tools/structured-settlement:

  1. Set jurisdiction: Wisconsin (US-WI)
  2. Set time horizon / limitation period: 6 years (default/general under Wis. Stat. § 939.74(1))
  3. Enter a simple structure:
    • Example structure conceptually: equal periodic payments for a defined number of installments
    • Choose a payment start date after your as-of date
  4. Set a discount rate (pick one consistent assumption for the first run)
  5. Run calculation
  6. Compare outputs when you change one variable:
    • Increase the discount rate → confirm present value drops
    • Move start date later → confirm present value drops
    • Shorten the modeled schedule → confirm total present value decreases

To make your own test outputs easier to interpret, you can track results in a small checklist:

If those checks fail, re-check:

  • jurisdiction selection (US-WI),
  • horizon set to 6 years,
  • and payment schedule frequency/amount entries.

Related reading