Step-by-step

This guide walks through running a Structured Settlement calculation in DocketMath for Wisconsin (US‑WI) using jurisdiction-aware rules—so your schedule aligns with the Wisconsin Structured Settlement Protection Act framework.

1) Open the right tool

1. Go to the primary CTA: /tools/structured-settlement
2. Select Wisconsin (US‑WI) as the jurisdiction (if DocketMath prompts you to choose a jurisdiction).
3. Confirm you’re using the structured-settlement calculator (not a generic annuity or single-payment calculator).

2) Collect the inputs DocketMath needs

Structured settlement calculations usually depend on timing and discounting assumptions. Gather these items before you start so your entries reflect the settlement paperwork consistently:

Use this checklist:

• Payment stream type
  (e.g., periodic payments rather than a single lump sum)
• First payment date (month/day/year)
• Payment frequency (monthly, quarterly, annual—whatever the award uses)
• Payment amount (or a rule for varying payments)
• Number of payments or end date
• Discount rate (if DocketMath asks for it)
• Computation date (“as of” date for the calculation)

If you don’t know a discount rate (or need to mirror the one used in your present value assumptions), use the exact rate shown in the settlement agreement or its exhibits.

3) Enter payments exactly as drafted

Now translate the settlement schedule into DocketMath inputs:

• Use the same payment frequency as the settlement.
• Enter payment dates using the same calendar basis as your award schedule (especially for monthly vs. quarterly timing).
• If payments step up or change amounts over time, enter each segment using the tool’s supported structure—or run multiple scenarios if DocketMath only supports uniform streams.

4) Apply Wisconsin jurisdiction-aware rules (US‑WI)

In Wisconsin, the primary statutory framework you’ll see relevant to structured settlement transfers is:

• Wis. Stat. § 422.435 — the Wisconsin Structured Settlement Protection Act (Transfers of structured settlement payment rights)

A key baseline rule from the statute is:

• “No direct or indirect transfer of structured settlement payment rights shall be effective…” (and related restrictions on structured settlement obligors/annuity issuers)

Source: https://docs.legis.wisconsin.gov/statutes/statutes/422/iv/435

How this affects your DocketMath run

DocketMath’s jurisdiction-aware behavior typically shows up in practical ways:

1. Transfer/compliance framing: the calculator will use Wisconsin assumptions consistent with the statutory environment rather than treating transfers as freely assignable.
2. Timing or “calculation window” considerations: Wisconsin protections can depend on a defined period.

In this content brief, no claim-type-specific sub-rule was found, so DocketMath should use the general/default period rather than switching rules by claim type. This matters when you’re modeling cashflow across protected stages.

5) Choose the calculation mode in DocketMath

Depending on the calculator options, select the output you need:

• Present value of the payment stream as of a specific date
• Total payout (nominal sum of all scheduled payments)
• Payment schedule output (to verify dates and amounts)
• Scenario comparisons (if multiple discount rates or dates are supported)

If DocketMath offers scenario runs, use them to test:

• different discount rates
• different as-of dates
• different payment timing (for example, confirming the first payment date)

6) Review the outputs for Wisconsin-aligned assumptions

After calculation, inspect outputs for two categories:

A) Math outputs

Check:

• number of payments included
• start/end dates
• whether the frequency matches your inputs
• whether discounting behaves as expected for your setup

B) Wisconsin framing outputs

If DocketMath includes a “jurisdiction note” or compliance-related output panel, confirm it reflects:

• Wisconsin’s protections under Wis. Stat. § 422.435
• default/general period treatment (because no claim-type-specific sub-rule was found in this brief)

7) Export or save the result

Finally:

• Save the run for auditability.
• If DocketMath generates a shareable summary, ensure the jurisdiction tag is set to US‑WI and that the settlement schedule details are correct.

Practical “before you hit calculate” checklist

• Jurisdiction set to US‑WI
• First payment date matches the settlement exhibit (first scheduled payment, not an award date unless that’s truly the first payment)
• Frequency matches the award schedule (monthly/quarterly/annual)
• End condition is correct (end date vs. number of payments)
• Discount rate matches the scenario assumptions you’re modeling
• You’re not assuming transferability beyond what Wis. Stat. § 422.435 supports in the protection framework

Common pitfalls

Structured settlement math is usually straightforward—most mistakes come from schedule details and compliance assumptions. Here are the most common pitfalls to watch for in Wisconsin + DocketMath use.

Pitfall 1: Modeling the wrong period rules (default vs. claim-type-specific)

In this brief, no claim-type-specific sub-rule was found, so the correct approach is to rely on the general/default period rather than expecting claim-type-driven rule switching.

• Symptom: outputs shift when you change claim-type labels even though the settlement schedule didn’t change.
• Fix: keep claim-type selection aligned with what the tool supports, and rely on the default-period behavior for Wisconsin (as described in this content).

Pitfall 2: Assuming transfers are automatically effective

Wisconsin’s Wis. Stat. § 422.435 does not treat transfer of structured settlement payment rights as automatically effective.

• Symptom: you model proceeds from a transfer as if it’s permitted without conditions or timing considerations.
• Fix: use DocketMath for the financial schedule, but validate legal effectiveness and timing separately against Wis. Stat. § 422.435.

Pitfall 3: Off-by-one payment errors from date interpretation

This often happens when:

• the first payment date is entered as the award date instead of the first scheduled payment date

• the end date is treated inclusive/exclusive in a way that doesn’t match the settlement’s counting method

• Symptom: nominal total payout differs by exactly one payment.

• Fix: compare DocketMath’s payment schedule output against the settlement exhibit month-by-month.

Pitfall 4: Mixing monthly and annual frequencies

A schedule described as “monthly for 60 months” can be mistakenly entered as “annual for 5 years.”

• Symptom: discounted present value changes dramatically (often far beyond what discounting alone would explain).
• Fix: enter payment frequency exactly as drafted.

Try it

If you want to run a Wisconsin structured settlement scenario right now:

1. Open /tools/structured-settlement
2. Set jurisdiction to Wisconsin (US‑WI)
3. Enter:

   • first payment date
   • payment frequency
   • payment amount (and any step-ups)
   • end condition (end date or number of payments)
   • “as of” date
   • discount rate (if requested)
4. Run the calculation and compare:

   • Nominal total payout vs. the expected schedule sum
   • Payment schedule output vs. the settlement exhibit
5. Save your result with the Wisconsin jurisdiction tag

Then do a quick sensitivity check:

• Run one scenario using your discount rate.
• Run a second scenario with a slightly different discount rate (for example, ±1%) to see how sensitive present value is to assumptions.

This helps catch date/frequency issues early because those usually create obvious, non-linear changes in present value.

Related reading

• How to calculate Structured Settlement in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Structured Settlement in Philippines — Worked example with real statute citations
• Inputs you need for Structured Settlement in Philippines — Input checklist with sourcing guidance