How to run Structured Settlement in DocketMath for North Carolina

How to run Structured Settlement in DocketMath for North Carolina

6 min read

Published March 30, 2025 • Updated April 23, 2026 • By DocketMath Team

Article claim inventory in progress

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 North Carolina (US-NC). The goal is to show exactly which inputs you’ll enter and how the outputs will change when you adjust key assumptions. This is a workflow explanation—not legal advice.

1) Start at the Structured Settlement calculator

  1. Open DocketMath’s tool here: /tools/structured-settlement
  2. Confirm the jurisdiction context is set to North Carolina (US-NC).

If your DocketMath screen includes a jurisdiction selector, set it to US-NC before entering numbers. Jurisdiction-awareness matters when the tool applies timing defaults and rule logic.

2) Enter the settlement structure parameters

On the structured-settlement interface, you’ll typically see fields for items like:

  • Lump sum vs. periodic payments (how much is paid immediately vs. over time)
  • Number of installments
  • Payment frequency (monthly/quarterly/annual—whatever your UI provides)
  • Start timing (e.g., first payment date or offset)
  • Discount rate / interest assumption (used to translate future payments into present value, depending on the calculator design)
  • Cost of annuity / investment assumptions (if your tool includes an annuity-related cost input)

Use DocketMath to model the structure you’re considering. As you change these inputs, watch for outputs such as:

  • Total nominal payout (sum of all payments)
  • Present value estimate (often the most decision-relevant figure)
  • Schedule table (payment by payment timing and amounts)

3) Apply North Carolina timing defaults (SOL context)

DocketMath may display jurisdiction-aware timing assumptions. For North Carolina, the general/default period is 3 years.

Per the brief you provided:

  • General SOL Period: 3 years
  • No claim-type-specific sub-rule was found. That means DocketMath will use the general default period unless a more specific rule is added to the tool’s knowledge base for a specific claim type.

In other words, treat “3 years” as the baseline timing window used by the calculator’s jurisdiction-aware logic. Don’t try to infer claim-specific limitations from this setting.

Where the “SAFE Child Act” context fits (and what it doesn’t do here)

Your jurisdiction data set also references the SAFE Child Act via the North Carolina Department of Justice (NC DOJ) page on supporting victims and survivors of sexual assault:

Important: Your provided tool ruleset for this workflow indicates no claim-type-specific sub-rule was found, so the calculation should still treat 3 years as the applicable general/default SOL period in this DocketMath context—not as a claim-specific timing override.

Pitfall: Don’t assume the tool’s “3 years” timing window automatically matches every case theory or claim type. Your dataset indicates no claim-type-specific sub-rule was found, so DocketMath is using the general default SOL period.

4) Verify the payment timeline against the SOL default

Once you enter the structure (installments and dates), review the schedule output:

Checklist:

  • ☐ Does the first payment fall within your intended timeline?
  • ☐ Are significant installments stretching beyond the 3-year default window?
  • ☐ If DocketMath reflects timing in outputs (e.g., “when a claim must be brought”), confirm those references align with the schedule and your assumptions.

If you see mismatches, adjust either:

  • the start timing, or
  • the distribution across installments (e.g., fewer longer payments vs. more frequent smaller payments),
  • or the timing logic if the UI allows toggles.

5) Generate the structured settlement output and compare scenarios

Run your base scenario, then change one variable at a time. A practical comparison approach:

  • Scenario A: Baseline structure (same totals, different installment frequency)
  • Scenario B: Shift the first payment earlier/later
  • Scenario C: Change the discount/interest assumption (if adjustable)

What to watch:

  • Present value: typically moves meaningfully with discount rate and start dates.
  • Nominal totals: usually stays constant if you’re only changing timing (unless you’re also changing installment amounts).
  • Schedule table: should reflect date changes precisely.

You’ll get the most leverage by changing one assumption at a time, so you can attribute differences in results to a single input.

6) Export or record results for review

If DocketMath supports copying results, saving a view, or exporting a schedule:

  • Save the base scenario
  • Save at least one alternative
  • Capture the present value and schedule outputs

This makes later review faster—especially if you’re reconciling different settlement proposals.

Common pitfalls

Structured settlement modeling is easy to get “almost right” but wrong in a way that changes the math. Here are the most common issues to avoid when using DocketMath for North Carolina (US-NC):

  1. Using the general SOL default as if it were claim-specific
    Your dataset indicates no claim-type-specific sub-rule was found, so DocketMath uses the general/default 3-year period. Don’t treat it as universal across all theories.

  2. Forgetting that timing changes present value
    If you move payments later, the present value estimate usually decreases (because future dollars are discounted more heavily).

  3. Mixing nominal totals and present value outputs
    Some outputs represent the sum of payments (nominal), while others represent present value. Always check the label next to each number before comparing scenarios.

  4. Assuming the SAFE Child Act reference changes the SOL logic in this tool run
    The NC DOJ page provides background context (SAFE Child Act framework and related supporting materials), but your brief’s tool ruleset indicates a general/default 3-year SOL period with no claim-type-specific sub-rule. Don’t “upgrade” the tool’s timing logic without an explicit rule or UI toggle.

  5. Not validating the payment schedule
    A tiny date entry error (e.g., wrong month or offset) can shift multiple installments and distort the present value.

Warning: If your schedule spans beyond the 3-year default window and you’re relying on timing-based outputs, you may get results that appear internally consistent but don’t match the assumptions you intended to test.

Try it

Ready to run your first North Carolina structured settlement scenario?

  1. Set jurisdiction to US-NC (North Carolina)
  2. Enter:
    • payment frequency
    • number of installments
    • start timing (date/offset)
    • lump sum amount (if applicable)
    • discount/interest assumption (if your UI includes it)
  3. Generate the schedule and compare:
    • Scenario A: baseline structure
    • Scenario B: shift first payment by +30 days
    • Scenario C: change discount rate (e.g., lower vs. higher)

As you run it, keep this constraint clear:

  • DocketMath’s North Carolina timing context in your provided dataset uses a general/default SOL period of 3 years.
  • No claim-type-specific sub-rule was found, so the tool is not applying special periods for specific claim types.

For background on the SAFE Child Act materials referenced in your jurisdiction data set, you can review:

Related reading