How to run Structured Settlement in DocketMath for North Dakota

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

Running a Structured Settlement calculation in DocketMath for North Dakota (US-ND) is mainly about entering the right inputs and using the jurisdiction-aware options so the calculator’s timing/eligibility logic is applied correctly.

1) Open the Structured Settlement calculator

1. Go to: /tools/structured-settlement
2. Confirm you’re using the correct jurisdiction preset:

   • Jurisdiction: **US-ND (North Dakota)

If you don’t see a jurisdiction selector, look for a jurisdiction-aware rules toggle or a jurisdiction field near the inputs. Selecting US-ND is what helps ensure DocketMath applies the North Dakota-specific rule set you want.

2) Choose the payment structure pattern

Structured settlements typically model periodic payments (for example, monthly) that may start immediately or after an initial delay.

In DocketMath, select the option that best matches how the settlement is described:

• Immediate payments (start date equals the settlement close date, or a chosen start date)
• Deferred payments (payments begin after a specified deferral period)
• One-time lump sum + periodic stream (if your agreement includes both)

This choice affects:

• The timeline used for discounting future payments
• The projected payment schedule
• Which outputs you should compare (typically total nominal payout vs. present value)

3) Enter the funding amount or implied present value basis

Depending on how the settlement is drafted (and how DocketMath’s workflow is set up), you’ll either:

• Start with the total settlement value (funding amount), and let DocketMath distribute it across the payment stream parameters, or
• Start with periodic payment amounts, and let DocketMath compute the implied present value / funding target

Use the calculator fields consistently:

• If the agreement describes payment amounts, enter the periodic amounts and let DocketMath handle the implied valuation.
• If the agreement describes a total funding amount, enter that and use DocketMath’s stream parameters to model the resulting schedule.

4) Set payment frequency and term

Define both:

• Payment frequency (monthly, quarterly, annual, etc.)
• Term length (either number of payments or end date, depending on what the form expects)

Small differences here can change results a lot. For instance:

• 60 monthly payments and 60 annual payments are not comparable—they represent radically different timing and present value.

5) Set start date and (if applicable) deferral period

Now specify when payments begin:

• Start date (format typically YYYY-MM-DD)
• If deferred, enter either:

  • a deferral length (e.g., 6 months, 1 year), or
  • a deferred start date, depending on the fields DocketMath provides

DocketMath uses these dates to align the cash flow schedule. In general, moving the start date later will:

• Reduce the present value for a fixed nominal payment pattern (more time passes before cash arrives)
• Change the implied funding requirement the calculator derives

6) Enter the discount rate / interest assumptions

Structured settlement modeling depends on discounting future payments back to a present value.

In DocketMath:

1. Find the discount rate input.
2. Enter the annual rate in the format the field expects (decimal vs. percentage).

Why this matters:

• Higher discount rate → lower present value for the same payment stream
• Lower discount rate → higher present value

If you’re comparing scenarios, keep the discount rate consistent unless you intentionally want to test rate sensitivity.

7) Add escalation (and other modifiers) only if your agreement includes them

Some structured settlements include payment escalation, such as annual increases (e.g., 2–3%) or index-linked adjustments.

If DocketMath provides fields for escalation:

• Enter the escalation rate
• Confirm how often it applies
• Confirm when it starts (immediately vs. after the first payment)

Tax modeling can vary by product and calculator design. If DocketMath does not provide tax-specific inputs, keep the model focused on what the calculator supports and treat outputs as a financial projection, not a tax opinion.

8) Review outputs and sanity-check the schedule

Run the calculation and review what DocketMath returns. Common outputs include:

• Total nominal payout
• Present value / implied funding amount
• A payment schedule/table showing dates and payment amounts

Do a quick sanity check:

• Does the number of payments match your term × frequency?
• Do the first and last payment dates match the structure you intended?
• If escalation is on, do payment amounts increase over time in the expected pattern?

The payment table is often the fastest way to catch timing mistakes that totals alone won’t reveal.

9) Compare at least two scenarios

To understand sensitivity (and avoid “single-run surprises”), run minimum two versions by changing only one or two variables at a time, for example:

• Scenario A: earlier start date, escalation OFF
• Scenario B: later start date, escalation ON

In many models:

• Present value is usually most sensitive to start date and discount rate
• Total nominal payout is usually most sensitive to term and escalation

10) Export or record results

Once the results look right:

• Save/export the output if DocketMath provides that option
• Copy the key figures into your notes:

  • Total nominal payout
  • Present value
  • Number of payments
  • Payment start/end dates

Also record your inputs (jurisdiction, frequency, start date, discount rate, escalation) so you can reproduce the run later.

Common pitfalls

Structured settlement calculations can look straightforward, but small input issues can distort outcomes—especially in a jurisdiction-aware workflow like US-ND.

• Wrong jurisdiction preset

  • If you don’t set US-ND, DocketMath may apply the wrong ruleset for timing/logic.
• Start date off by one month

  • Because discounting is time-based, even a small date shift can materially change present value.
• Confusing frequency with term

  • Example: entering “60” as if it means “60 months” when the term field expects “60 payments.”
• Mismatch between “net” vs. “gross” expectations

  • If your settlement describes amounts in a specific basis, make sure your DocketMath inputs reflect the same basis the calculator assumes.
• Discount rate inconsistency

  • If the discount rate you choose doesn’t match the assumptions behind your intended structure, present value will be misleading.
• Forgetting escalation

  • If your settlement escalates but escalation is entered as 0%, totals for long-term schedules will be understated.
• Skipping scenario comparisons

  • One run hides sensitivity. At minimum, compare two scenarios (for example, start date and escalation on/off).

A particularly common “looks plausible but is wrong” issue:

• Units mismatch for deferral

  • Entering a deferral using “months” when the calculator expects “years” (or vice versa) can produce a schedule that appears reasonable, while the present value is significantly off.

Try it

Here’s a quick way to test your setup in DocketMath:

• Open: /tools/structured-settlement
• Set:

  • Jurisdiction: US-ND
  • Payment frequency: monthly
  • Start date: choose a near-term date so you can quickly verify the first payment
  • Term: pick a fixed number of payments that matches your structure (for example, 60 payments)

Run 1:

• Discount rate = your assumed annual rate
• Escalation = 0%

Run 2:

• Keep everything the same
• Escalation on (for example, 2% annually) only if your agreement includes it

Then compare:

• Total nominal payout (should generally increase when escalation increases future payments)
• Present value (typically shifts based on the timing of cash flows and the rate assumptions)

Finally, confirm the payment schedule table looks correct:

• First payment date
• Last payment date
• Number of rows/entries equals the expected number of payments

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado