How to run Structured Settlement in DocketMath for New Jersey

How to run Structured Settlement in DocketMath for New Jersey

6 min read

Published August 11, 2025 • Updated April 23, 2026 • By DocketMath Team

Verification issue found

Trust release 4

This page includes a legal claim or source that failed the current primary-source review.

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

This guide shows how to run a Structured Settlement using DocketMath for New Jersey (US-NJ) using jurisdiction-aware rules. It focuses on the default New Jersey timing rules for bringing claims, which can matter when you model expected payout schedules and settlement timing.

Note: DocketMath can help you model settlement structures and timelines, but this walkthrough isn’t legal advice. Use it to organize calculations and scenario planning, then confirm details for your specific case.

1) Open the Structured Settlement calculator

  • Go to the primary call-to-action: /tools/structured-settlement
  • Select New Jersey (US-NJ) inside the tool if the UI prompts for jurisdiction.

If you don’t see a jurisdiction selector, look for a jurisdiction setting or rule preset near the calculator header. Your goal is to ensure the run uses US-NJ.

2) Enter the settlement structure inputs

DocketMath’s structured-settlement calculator typically collects the core parameters of the payout stream. Use these categories to guide your input order:

  • Lump sum amount (if any)
    Enter the up-front payment that occurs at or near the settlement effective date (if your scenario includes one).
  • Periodic payments
    Input the payment amount for each periodic installment (monthly, annual, or another frequency—use the exact frequency the UI provides).
  • Number of installments / term length
    Enter how long the periodic payments run (for example, 10 years = 120 monthly installments if monthly is selected).
  • Payment timing (start date)
    If there is a field for “first payment date” or “start time,” use the settlement date or the first scheduled payout date you want to model.
  • Discount rate / return assumption (if available)
    Some structured settlement models ask for an assumed rate used to compute present value. If the tool provides this field, use an assumption consistent with your scenario planning (and document it).

How outputs change:

  • Increasing periodic payment amount raises both total payout and (usually) present value.
  • Extending the term length increases total payout and affects present value depending on the discount/return assumption.
  • Moving the start date later can reduce present value because more cash flows occur further in the future.

3) Apply New Jersey timing rules using the default SOL

After you enter the structure, DocketMath may reference timing assumptions tied to claim deadlines. For New Jersey, the jurisdiction data indicates a general/default SOL of:

Important limitation for this guide:
The provided jurisdiction data did not identify a claim-type-specific sub-rule. That means this run uses the general/default 4-year period as the governing timing assumption inside DocketMath.

Warning: If your fact pattern involves a claim category with a different deadline than the general default, DocketMath’s timing-related outputs may not match the actual legal deadline. This guide uses the general/default period: 4 years.

4) Choose the scenario that matches your settlement narrative

Run multiple passes in DocketMath to see how variations affect outputs:

  • Scenario A (more front-loaded): higher lump sum + shorter periodic term
  • Scenario B (more back-loaded): lower lump sum + longer periodic term
  • Scenario C (timing shift): same structure, but delay the first payment by 6–12 months

For each run, keep the structure inputs consistent except for the variable you’re testing. Then compare the tool outputs (typically present value, total payout, schedule, and/or any timing-related modeled fields).

5) Review the schedule and calculated figures

After calculations complete, review:

  • Payment schedule summary (dates and amounts per installment)
  • Total payout (lump sum + periodic totals)
  • Present value (if the tool calculates it using your discount/return assumption)
  • Timing alignment with any SOL-related modeling fields or notes in the output/settings

How outputs change—quick reference:

Input you changeTypical output impact
Higher lump sumHigher total payout; present value typically increases (often more noticeably when cash is received earlier)
Longer periodic termTotal payout increases; present value depends on discount/return assumption and how far out payments extend
Later first payment dateTotal payout unchanged; present value typically decreases
Higher discount ratePresent value typically decreases (future payments are discounted more aggressively)

6) Export or capture results for documentation

If DocketMath provides export options (PDF/CSV/copy-to-clipboard), use them to save:

  • The scenario inputs you used
  • The jurisdiction setting (US-NJ)
  • The resulting schedule and summary numbers

This makes it easier to compare runs and keep assumptions consistent.

Common pitfalls

Use this checklist to avoid errors that commonly distort structured settlement models in DocketMath:

If the calculator defaults to another jurisdiction, your timing logic may not reflect New Jersey’s 4-year general/default SOL under N.J.S.A. 12A:2-725. The provided jurisdiction data uses the general/default SOL only. No claim-type-specific sub-rule was found. If your case involves a different deadline category, DocketMath may not reflect it. Example: entering annual payment amounts while the tool is set to monthly frequency can inflate totals. If the first payment date is after the settlement effective date by a large margin, present value may drop materially. When comparing scenarios, alter one factor at a time (e.g., only lump sum or only start date). Otherwise you can’t tell what drove the change in results. If DocketMath uses a discount rate, record the value you entered so others can understand why present value differs between runs.

Pitfall: A 1-year shift in start date can have a bigger effect on present value than a small change in periodic payment amount, especially when discounting is enabled.

Try it

Follow these quick test runs inside DocketMath to confirm your setup for US-NJ:

  1. Baseline run

    • Set jurisdiction to US-NJ
    • Enter a simple structure:
      • Lump sum: a single value (if the tool supports it)
      • Periodic: a fixed amount
      • Term: e.g., a 10-year term (or the tool’s preferred format)
      • Start date: settlement date or the next payment date you want to model
    • Record the output totals and any present value figure.
  2. Start-date sensitivity

    • Keep everything the same
    • Move the first payment date forward by 6 months
    • Compare the present value change to your baseline
  3. Front-load vs back-load

    • Increase lump sum
    • Decrease periodic amount to keep total payout roughly comparable (if your goal is comparison)
    • Check how present value responds to cash-flow timing
  4. Confirm timing rule linkage

    • Look for any SOL/timing note or modeled deadline reference inside the output or settings panel
    • Ensure it reflects 4 years using N.J.S.A. 12A:2-725 as the general/default period

If your outputs look dramatically off after these tests, re-check:

  • jurisdiction selection (US-NJ)
  • payment frequency
  • start date and installment count consistency

Related reading