How to run Structured Settlement in DocketMath for South Dakota

Step-by-step

This guide walks you through running a Structured Settlement calculation in DocketMath for South Dakota (US-SD) using the structured-settlement calculator and jurisdiction-aware defaults.

1) Open the Structured Settlement calculator

1. Go to the primary CTA: /tools/structured-settlement
2. Confirm you’re viewing the Structured Settlement calculator (not a generic payment schedule tool).

2) Set the jurisdiction to South Dakota (US-SD)

In DocketMath’s jurisdiction selector:

• Choose South Dakota — US-SD

This step matters because DocketMath uses jurisdiction-aware rules and defaults to shape the calculation setup (including timing/periodicity assumptions where applicable).

3) Understand the payment timing rule used for South Dakota

DocketMath needs a basis for recurring payment schedules.

For South Dakota, no claim-type-specific sub-rule was found for timing/periodic payment assumptions. That means the tool uses the general/default period.

In practice, that means:

• You should expect DocketMath’s schedule to follow the default recurrence approach configured for US-SD.
• If your intended structure depends on a different claim-type-specific timing rule, you’ll need to reconcile that with the model you’re running (and adjust the inputs to the extent the calculator allows).

4) Enter the core financial inputs

Use the calculator inputs to model your structure, typically including:

• Total settlement principal / gross amount (the amount being structured)
• First payment date (the start of the income stream)
• Payment frequency (monthly, quarterly, annual—choose what matches your intended structure)
• Number of payments (or an end date, depending on the calculator UI)
• Discount rate / assumed return (the rate used to compute present value and/or derive payment amounts)

If DocketMath provides multiple calculation modes (for example, solve for payments vs. solve for present value):

• If you’re trying to determine payment size, use principal + rate + schedule and derive payments.
• If you’re trying to determine funding / lump sum needed, use desired payments + rate + schedule and derive the present value.

5) Choose the assumptions that affect output

Structured settlement models usually incorporate these assumption categories:

• Interest / discount rate

  • Affects how future payments translate into present value.
  • Generally, a higher assumed return lowers the periodic payment needed for the same present value.

• Payment cadence

  • Affects how many payment dates occur.
  • Changing cadence can change both payment size and totals depending on the direction of the calculation mode.

• Start date alignment

  • Small date shifts can materially change results—especially with longer durations or higher assumed return.

After entering inputs, use the result panels to confirm:

• the first payment date matches what you intend, and
• the schedule dates line up with your proposed structure.

6) Run the calculation and review outputs

When inputs look correct:

1. Click Calculate (or the equivalent button in the UI).
2. Review at minimum:

   • Payment schedule (dates + payment amounts)
   • Total of payments
   • Present value / present cost (if shown)
   • Any reconciliation lines (for example, relationships between principal and computed present value)

A practical sanity check:

• Does the first payment date match the schedule you intended?
• Does the count of payments match the configured “number of payments” (or ending date)?
• When you adjust the discount rate, do the results move in the expected direction?

7) Iterate inputs to match the intended structure

Structured settlements are often revised during planning. A useful workflow is iterative refinement:

• If payments are too high/low, adjust one of:

  • discount rate
  • payment frequency
  • end date / number of payments
• If timing doesn’t match, adjust:

  • first payment date
  • recurrence-related settings (if available)

Even small changes can shift:

• periodic payment amounts,
• the total payout, and
• present value.

Pitfall to avoid: Don’t change multiple inputs at once. If the payment amount changes unexpectedly, you won’t know whether the shift is due to a date change, cadence change, or rate change.

8) Document the run for reuse (practical workflow)

To keep revisions traceable:

• Record the key assumptions you used (principal/PV, dates, frequency, discount rate).
• Save or copy the output schedule (table/export if available).
• Use a simple note format like: “US-SD run v2: rate 3.5%, start 2026-07-01.”

This helps you compare versions consistently, especially when you’re testing scenarios.

Common pitfalls

Use this checklist to avoid common mistakes when running Structured Settlement calculations for South Dakota (US-SD) in DocketMath.

• Forgetting to set jurisdiction to US-SD

  • If you leave the jurisdiction unspecified, the calculator may apply different defaults (including how timing/periodicity is handled).

• Assuming a claim-type-specific timing rule exists

  • For South Dakota, no claim-type-specific sub-rule was found for timing/periodic payment assumptions, so the tool uses the general/default period.
  • If your contract or proposal relies on a different special timing rule, you may need to reconcile that with the tool’s default behavior.

• Mismatching first payment date vs. first scheduled payment

  • Many schedules “fail review” because the first payment date in the modeled timeline doesn’t align with the intended start of payments.

• Changing discount rate and payment cadence at the same time

  • Doing both makes it harder to explain why outputs changed and complicates reconciliation.

• Not validating payment count

  • Confirm the schedule includes the expected number of payments (or that it ends on the intended end date).

• Interpreting totals without checking present value

  • “Total of payments” may look consistent while present value does not align with expected funding logic or the calculator’s mode.

Try it

You can run a clean South Dakota structure in DocketMath in a few minutes:

1. Open /tools/structured-settlement
2. Select South Dakota — US-SD
3. Enter:

   • settlement principal (or desired PV, depending on the calculator mode),
   • first payment date,
   • payment frequency,
   • number of payments (or end date),
   • assumed return / discount rate
4. Click Calculate
5. Verify:

   • the schedule dates,
   • the count of payments,
   • the present value figure against your expectation.

If you want a faster sensitivity workflow, run two scenarios:

• Run A: baseline rate and cadence
• Run B: change only one input (for example, rate +0.50%)

This helps you understand how sensitive payment amounts are—without losing traceability.

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