How to run Structured Settlement in DocketMath for New Jersey
6 min read
Published August 11, 2025 • Updated April 23, 2026 • By DocketMath Team
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:
- General statute of limitations (SOL): 4 years
- General statute: N.J.S.A. 12A:2-725 (general/default period)
Source: https://law.justia.com/codes/new-jersey/title-12a/section-12a-2-725/
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 change | Typical output impact |
|---|---|
| Higher lump sum | Higher total payout; present value typically increases (often more noticeably when cash is received earlier) |
| Longer periodic term | Total payout increases; present value depends on discount/return assumption and how far out payments extend |
| Later first payment date | Total payout unchanged; present value typically decreases |
| Higher discount rate | Present 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:
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.
Start-date sensitivity
- Keep everything the same
- Move the first payment date forward by 6 months
- Compare the present value change to your baseline
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
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
