How to run Settlement Allocator in DocketMath for New Jersey

How to run Settlement Allocator in DocketMath for New Jersey

6 min read

Published April 18, 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 Settlement Allocator calculator.

This guide walks you through running Settlement Allocator in DocketMath for New Jersey (US-NJ). The calculator uses jurisdiction-aware rules. For New Jersey, it applies the general/default statute of limitations (SOL) for certain contract-style claims: N.J.S.A. 12A:2-725, which provides a 4-year general SOL period.

Note: No claim-type-specific sub-rule was found in the provided jurisdiction data. Because of that, this walkthrough uses the 4-year general/default period.

1) Open the calculator

Start at the primary CTA:

  • Go to /tools/settlement-allocator

2) Confirm the jurisdiction setting

In the calculator’s jurisdiction selector, choose:

  • New Jersey — US-NJ

If the UI already defaults to US-NJ, still double-check it. Even small jurisdiction mismatches can change time-based calculations.

3) Review what inputs the Settlement Allocator expects

Settlement allocation is date-driven, so the most important inputs are the ones that let the tool determine:

  • the relevant start date (often tied to a case timeline trigger like accrual, delivery, or another event), and
  • what portion of the exposure falls within the SOL window for New Jersey.

Typically, you’ll enter (or map) inputs like:

  • Event/trigger date: the date your facts/timeline indicate as the start for SOL analysis
  • Evaluation date: the “as of” date for the allocation output
  • Settlement amount: the total settlement value to allocate (and, if the UI supports it, any breakdown categories you want allocated)

How outputs change based on inputs

  • If you move the event/trigger date later, the SOL window shifts later too, which can increase the portion considered within SOL.
  • If you move the evaluation date later, more time may pass after the start date—often resulting in a higher chance that older portions fall outside SOL.
  • If you change the settlement amount, the allocable vs. non-allocable amounts generally scale accordingly, assuming the same timing inputs.

If the calculator asks for additional timing fields (for example, a notice or loss date), fill them using the same internal timeline logic you already use. The exact wording matters less than consistency across the inputs you provide.

4) Understand the New Jersey SOL rule used

For New Jersey, the calculator will apply a 4-year general SOL period under:

Because no claim-type-specific sub-rule was found in the jurisdiction data, the tool uses this 4-year general/default period. In practical terms, that means:

  • Events that occur more than 4 years before the evaluation date may be treated as time-barred for allocation purposes.
  • Events within the last 4 years are more likely to be treated as allocable (within the SOL window).

Gentle reminder: This is a tooling explanation, not legal advice. SOL application can depend on many fact-specific issues not captured by calculators.

5) Run the calculation and interpret the output sections

After you submit, review the sections that reflect SOL-adjusted allocation. Common output patterns include:

  • Allocable amount: the portion treated as within the SOL window
  • Non-allocable / time-barred portion: the portion outside the SOL window
  • Timeline sensitivity indicators (if shown): explanations of which dates drove inclusion/exclusion, or breakdowns by time bucket

Quick sanity checks using your dates

  • If your evaluation date is more than 4 years after your event/trigger date, you should expect a reduced allocable portion.
  • If the event/trigger date is within 4 years of the evaluation date, you should expect a larger allocable portion (often closer to the full amount, depending on how the UI models partial periods).

If the tool provides intermediate breakdowns, confirm they align with your timeline assumptions. For example, if the timeline is logically segmented into multiple periods, the output should reflect that segmentation in a way that matches your inputs.

6) Iterate with scenario inputs

To make your allocation more decision-ready, run at least two scenarios and compare the outputs:

  • Scenario A (earlier trigger date): move the event/trigger date earlier (only if your facts support that interpretation)
  • Scenario B (later evaluation date): set the evaluation date closer to the present or to the date relevant for your settlement analysis

This is especially useful around the 4-year boundary—small timing shifts can change what proportion falls inside vs. outside SOL.

7) Export or record your result

If DocketMath provides any export options (such as PDF/CSV or a copyable result), save:

  • the jurisdiction (US-NJ),
  • your date inputs (event/trigger date and evaluation date),
  • the settlement amount, and
  • the resulting allocable vs. time-barred amounts.

Keeping a timestamped record makes it easier to compare versions across the team and across different timeline assumptions.

Common pitfalls

Settlement allocation is date-driven, and most mistakes come from timeline mismatches rather than math errors.

  • The calculator applies N.J.S.A. 12A:2-725’s 4-year window based on the event/trigger date you provide.
  • For this New Jersey setup, the jurisdiction data indicates no claim-type-specific sub-rule was found, so the 4-year general/default period is used.
  • Even a small change in dates can move part of the timeline from within SOL to outside SOL, which can materially affect allocable amounts.
  • If Scenario A uses one evaluation date (e.g., a draft demand date) and Scenario B uses a different evaluation date (e.g., a mediation date), the results won’t be directly comparable.
  • If the UI splits the settlement into categories or buckets, ensure those splits align with your case timeline logic. Misaligned categories can change allocation outcomes even when the SOL window is correct.

Warning: If you input a trigger/event date that is more than 4 years before your evaluation date, the allocation may exclude that portion as time-barred under the general SOL used for New Jersey.

Try it

To run a working New Jersey example in minutes:

  1. Go to /tools/settlement-allocator
  2. Select **New Jersey (US-NJ)
  3. Enter:
    • Event/trigger date
    • Evaluation date
    • Settlement amount
  4. Click Calculate
  5. Sanity-check the 4-year logic:
    • If Evaluation date − Trigger date > 4 years, expect a reduced allocable portion.
    • If ≤ 4 years, expect a larger allocable portion.

If you want to understand sensitivity, repeat using one change at a time:

  • keep settlement amount constant,
  • keep jurisdiction constant,
  • adjust only the trigger date slightly (for example, by a week or a month),
  • then compare the allocable output.

For broader workflow support, you can also browse DocketMath tools (including timeline-related ones) from /tools before running allocations—so your dates match your broader litigation timeline.

Related reading