How to run Structured Settlement in DocketMath for South Carolina
6 min read
Published September 20, 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
This guide walks you through running a Structured Settlement calculation in DocketMath for South Carolina (US-SC). You’ll also see how South Carolina’s default statute of limitations affects what you choose to model—without making any legal determinations.
Note: DocketMath helps with math and organization. This walkthrough doesn’t replace legal judgment about eligibility, enforceability, or strategy.
1) Open the Structured Settlement calculator
- Go to the primary CTA: **/tools/structured-settlement
- Select or confirm the jurisdiction as South Carolina (US-SC).
2) Enter the structured settlement inputs
DocketMath’s Structured Settlement workflow typically centers on a few core inputs. Use the values you have (or plan to test) and keep them consistent across scenarios.
As you go, check the items that match your situation:
How outputs change (what to watch while typing):
- A higher discount rate usually lowers present value (PV) because future payments are valued less.
- A longer time horizon (payments extending further out) generally reduces PV for the same nominal payment amounts.
3) Align your timeline with South Carolina’s default SOL window (GS 15-1)
When you model structured payments, the timing you choose often needs to be consistent with whether a claim could be timely. For South Carolina, this post uses DocketMath’s jurisdiction-aware context based on the general/default statute of limitations.
Use these jurisdiction inputs:
- General SOL period: 3 years
- General statute: GS 15-1
Important scope clarification for this post:
- No claim-type-specific sub-rule was found in the provided jurisdiction data. That means this guide treats GS 15-1’s general/default 3-year period as the working SOL reference point (not a specialized rule for a particular claim category).
Practical effect on your modeling:
- If your proposed payment schedule runs well beyond the 3-year window and you’re using the SOL window to frame “what’s plausibly in play,” consider running scenarios that either:
- start immediately and complete within the 3-year reference frame, or
- clearly separate payments inside vs. outside the 3-year frame.
You’re not “changing” the law by how you input dates—rather, you’re testing whether your timeline assumptions track the default 3-year reference period.
4) Run scenarios to see how changes affect PV and totals
After entering your inputs:
- Click Calculate (or the equivalent run button in DocketMath).
- Review the outputs, typically including:
- Total nominal payments (undiscounted sum)
- Present value (PV) (discounted total)
- Payment-by-payment schedule (if your view shows it)
Then change one variable at a time so you can interpret the difference.
A simple approach:
- Scenario A: Keep schedule the same; change the discount rate (lower vs. higher).
- Scenario B: Keep the discount rate the same; change the start date so cash flows occur earlier vs. later.
- Scenario C: Keep totals the same; change payment frequency (if your tool lets you) to see how granularity affects PV.
How outputs change (common interpretation tips):
- Payment timing is often the biggest driver of PV. Two plans with the same nominal total can produce different PV if one delivers cash earlier.
- Frequency can matter if DocketMath discounts each payment individually (e.g., monthly vs. quarterly can create different discounting “paths”).
5) Save or export results for comparison
If DocketMath offers saving/exporting/copying:
- Save each scenario with a clear label, for example:
- “US-SC / baseline discount 3% / start within 3-year window”
- “US-SC / later start / same discount rate”
- Keep the jurisdiction constant as US-SC for apples-to-apples comparisons.
- If available, record:
- the inputs used
- nominal total vs. PV
- the as-of / evaluation date used for discounting
Common pitfalls
Structured settlement modeling is math-heavy, but most failures are input/timing mistakes—especially when you add SOL awareness.
- missing a required input
- using a stale rate or rule
- ignoring calendar or holiday adjustments
- skipping documentation of assumptions
When rules change, rerun the calculation with updated inputs and store the revision in the matter record.
Pitfall checklist
The jurisdiction context controls the SOL reference used to frame the modeling timeline. This guide uses only the general/default 3-year period under GS 15-1 from the provided jurisdiction data. It does not assert a claim-category-specific exception. If the evaluation date doesn’t align logically with when payments begin, PV can look surprising. PV is discounted; nominal total is not. If you adjust start date, discount rate, and payment amount simultaneously, you won’t know what caused the PV change.
Tip: If you’re trying to model “within vs. beyond 3 years,” avoid changing unrelated assumptions (like discount rate) in the same run—otherwise your comparisons get muddy.
Quick diagnostic table
| If you see… | Likely cause | Fix |
|---|---|---|
| PV is unexpectedly low | Discount rate too high or payments start too late | Lower discount rate or move the start earlier |
| PV is close to nominal total | Discount rate near 0% or payments occur soon | Verify discount rate and check payment dates |
| Payment dates look “off” | As-of/evaluation date mismatch with schedule | Re-check evaluation date and timing inputs |
| Results don’t match another run | Jurisdiction or one input changed | Confirm US-SC and compare inputs side-by-side |
Try it
Use DocketMath to run a quick baseline vs. sensitivity set for South Carolina (US-SC) using the general/default 3-year SOL reference under GS 15-1.
Here’s a practical 4-run mini-plan:
- Run 1 (Baseline):
- Discount rate: your baseline assumption
- Payments: level payments across a schedule that fits within the 3-year SOL reference framing
- Start: at the earliest date you intend to model
- Run 2 (Earlier start):
- Move the start date earlier (keep everything else identical)
- Run 3 (Later start):
- Move the start date later (keep everything else identical)
- Run 4 (Discount rate sensitivity):
- Keep timing fixed; change only the discount rate
As you review outputs, track:
- PV vs. nominal total
- Whether PV changes mainly due to timing (earlier/later cash flows) or mainly due to discount rate
- Whether the schedule you’re testing stays consistent with the default 3-year reference framing
For a clean workflow:
- Keep jurisdiction set to US-SC
- Run one variable change per scenario
- Label each run so you can compare results quickly
