How to run Structured Settlement in DocketMath for South Dakota
6 min read
Published August 21, 2025 • Updated April 23, 2026 • By DocketMath Team
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
Run this scenario in DocketMath using the Structured Settlement calculator.
Running a Structured Settlement workflow in DocketMath for South Dakota (US-SD) is mostly about (1) using the structured-settlement calculator and (2) making sure your modeled timeline reflects the correct jurisdiction-aware limitations baseline.
In South Dakota, the general/default statute of limitations period is 3 years, governed by SDCL 22-14-1. Per your note, no claim-type-specific sub-rule was found, so treat 3 years as the baseline unless you have a specific reason to use a different, more tailored rule.
Reminder (not legal advice): DocketMath helps with the math and scenario modeling, but you’re responsible for confirming that the limitations/timeline assumptions fit your situation.
1) Open the Structured Settlement tool
Start from the primary calculator link to ensure you’re using the right workflow:
- /tools/structured-settlement
2) Set South Dakota (US-SD) jurisdiction-aware assumptions
Inside the tool, set the jurisdiction to:
- **US-SD (South Dakota)
Then align the limitations/timeline assumptions used for your analysis to South Dakota’s general baseline:
- 3 years, based on SDCL 22-14-1
How this affects outcomes: when the tool ties a scenario window to the enforceability/limitations reference, the chosen period length influences what range of time the model considers relevant for the scenario.
3) Enter structured settlement inputs
Use the tool’s structured settlement fields to describe the payout schedule. Field names may vary slightly by UI, but the inputs typically include:
- Lump sum amount (if any)
- Annuity / periodic payments
- Payment frequency (e.g., monthly, annually)
- Start date and end date (or number of periods)
- Discount rate / assumed yield (used to compute present value)
- Payment escalation (if modeling increasing payments)
As you input values, watch how outputs change:
- Changing the start date: earlier payments are generally discounted for fewer periods, so present value often increases when payments begin sooner.
- Changing frequency: more frequent payments can shift the cash flow timing, which affects present value depending on your dates and discounting.
- Adding escalation: if payments increase over time, later payments may be larger in nominal terms, and the effect on present value depends on the discount rate.
4) Use the 3-year baseline when you choose the scenario window
Because South Dakota’s general/default limitations period is 3 years under SDCL 22-14-1, ensure your scenario’s timeline is consistent with that baseline.
In practice, focus on:
- the trigger/accrual date (or whatever date the workflow uses as the timeline anchor),
- whether your planned payout start/end interacts with that 3-year reference window.
DocketMath will recompute the valuation as you update schedule inputs and any related timeline parameters, so the tool output should shift as the assumed period length or dates change.
5) Review outputs and validate the modeled timeline
After you calculate, review the outputs closely—especially:
- Present value
- Total nominal payout
- Payment timing details (start/end and count)
- Any assumptions summary that shows the selected jurisdiction/timeline reference
If results look unexpected, the issue is usually one of these:
- the jurisdiction wasn’t set to US-SD
- the start date doesn’t match the timeline you intended
- the discount rate is different from what you assumed
6) Export or reuse the scenario for comparisons
Once your baseline scenario looks right, reuse/export it so you can compare alternatives (for example, different lump sum amounts, payment timing, or discount rates).
A practical best practice is to keep at least two versions:
- a base scenario, and
- a what-if scenario that changes one variable (commonly the start date or the discount rate) to see sensitivity.
7) Document the limitations reference you used (and keep it clear)
Structured settlement math is arithmetic, but the limitations/timeline reference is a modeling assumption. For this South Dakota setup, the baseline you should document is:
- SDCL 22-14-1 — 3-year general limitations period
And per your note: no claim-type-specific sub-rule was found, so 3 years is the default assumption in this content.
Common pitfalls
These issues commonly derail structured settlement runs, even when the calculator is working correctly.
- missing a required input
- using a stale rate or rule
- ignoring calendar or holiday adjustments
- skipping documentation of assumptions
Capture the source for each input so another team member can verify the same result quickly.
Pitfall: Using the wrong limitations baseline
- Expected South Dakota baseline: 3 years under SDCL 22-14-1
- If you accidentally model another period (e.g., 1 year or 5 years, or a claim-type-specific rule), your scenario window can drift from what you intended.
Pitfall: Mismatching the start date to the scenario window
If payments begin after the timeline you assumed, the present value can be materially lower than expected. Double-check:
- the start date you entered,
- payment frequency,
- and the total number of periods.
Pitfall: Discount rate confusion
The discount rate can meaningfully change present value. Quick directional check:
- Higher discount rate → lower present value
- Lower discount rate → higher present value
Pitfall: Confusing nominal totals with present value
Nominal totals (sum of payments) are not the same as present value (discounted). If you compare the wrong numbers, you may think the output is “wrong” when it’s actually reflecting valuation methodology.
Pitfall: Leaving jurisdiction unset or selecting the wrong one
If US-SD isn’t selected, DocketMath may not apply the SDCL 22-14-1 baseline you expect. Always verify the jurisdiction label in the assumptions summary.
Warning: Structured settlement outputs are sensitive to dates and valuation assumptions. Even small date or discount rate changes can shift present value enough to affect settlement comparisons.
Try it
Ready to run the workflow? Here’s a simple checklist:
- Open /tools/structured-settlement
- Select jurisdiction US-SD
- Confirm the limitations baseline is SDCL 22-14-1 (3 years) as the general/default period (since no claim-type-specific sub-rule was found)
- Enter your payout structure:
- periodic payments and their timing
- any lump sum
- discount rate (and escalation, if applicable)
- Compare at least two scenarios:
- Scenario A: earlier payment start date
- Scenario B: later payment start date and/or a different discount rate
- Validate by checking:
- the payment schedule totals
- the present value trend (earlier payments generally increase PV)
- that the scenario window aligns with the 3-year baseline
If you want to cross-check related workflows, you can also revisit the tool navigation inside the app after opening /tools/structured-settlement.
