How to run Settlement Allocator in DocketMath for New Hampshire

How to run Settlement Allocator in DocketMath for New Hampshire

7 min read

Published February 17, 2026 • 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

Run this scenario in DocketMath using the Settlement Allocator calculator.

This guide walks you through running Settlement Allocator in DocketMath for New Hampshire (US-NH), using jurisdiction-aware rules and the general statute of limitations (SOL) that applies to civil actions. (This is a modeling workflow, not legal advice.)

1) Start the tool from the primary CTA

  • Open the calculator here: /tools/settlement-allocator
  • If the tool prompts you to select a jurisdiction, choose New Hampshire (US-NH).
  • Before entering any amounts, confirm the run summary shows US-NH rules (so the SOL basis and timing logic align to New Hampshire).

2) Enter the case timing inputs

Settlement allocation often needs a timing anchor (commonly: when a claim accrued) so the tool can apply timing-based logic. In DocketMath, you’ll typically enter fields like:

  • Accrual date (sometimes labeled “date of the incident” depending on your workflow)
  • Filing date (if available—only use it if the tool asks for it, and ensure it’s mapped to the correct concept)
  • Evaluation date (the date the calculator uses to “evaluate” SOL/timing impact)

If your version of the tool uses different labels, keep the meanings consistent:

  • Accrual = when the claim legally “starts” for SOL purposes.
  • Evaluation = the date you’re allocating from (i.e., the point in time the calculator uses to decide whether the SOL window has run).

3) Set the applicable SOL rule (general/default period)

For New Hampshire, the DocketMath workflow should use the general/default SOL period for civil actions:

In plain terms for your workflow: New Hampshire’s default civil SOL is 3 years under RSA 508:4.

Important note: No claim-type-specific sub-rule was found for this workflow. That means you should treat RSA 508:4’s 3-year general period as the default SOL used by the calculator.

4) Enter claim amounts and allocation inputs

Next, provide the financial inputs required by Settlement Allocator. Common categories include:

  • Claim amount(s) by category (for example, any damage buckets you want the tool to allocate across)
  • Total settlement figure (if you’re distributing a fixed global settlement)
  • Any weights/priority variables the tool uses (e.g., whether certain buckets receive more or less allocation when timing factors apply)

Practical tip:

  • If the tool provides toggles such as “use SOL impact” or “apply timing rules,” keep them enabled so the calculator behaves jurisdiction-aware for US-NH.

5) Review how output changes with SOL timing

After you run the calculation, review the results panel for outputs tied to timing. You should expect allocation outputs to react when the SOL window changes—especially if the tool treats some categories as outside the 3-year RSA 508:4 period.

Use this quick checklist while reviewing results:

  • Does the tool show a timing status (e.g., within vs. beyond the SOL window)?
  • Do allocation percentages or allocated amounts shift across categories when you change the accrual date?
  • Are there any date warnings (for example, if evaluation date is more than 3 years after accrual)?

To test sensitivity, change only one date at a time:

  • Change accrual date by ±30 days, rerun, and observe what moves.
  • Then change evaluation date (if applicable) by ±30 days and compare outputs.
  • If the tool also asks for filing date, don’t change it unless you intend to test that specific input mapping.

6) Export or capture the allocation results

When the run looks right for your scenario:

  • Use any save/export/download option the tool provides.
  • In your notes, record the key run settings so you can reproduce the numbers later:
    • Jurisdiction: US-NH
    • SOL basis: **RSA 508:4 (3 years)
    • Any indication that the model uses the general/default period (not a claim-type-specific rule)

7) Add a short verification note for your internal workflow

DocketMath outputs are calculators for analysis and discussion support. To keep your workflow consistent, add a brief note in your case file such as:

  • Jurisdiction: US-NH
  • SOL default used: **RSA 508:4 (3 years)
  • Treatment: general/default period only (no claim-type-specific sub-rules applied in this workflow)

Caution: Treat settlement allocation figures as modeling outputs, not a final determination of timeliness or liability. Use them to support settlement discussions and internal analysis.

Common pitfalls

Settlement Allocator for New Hampshire (US-NH) is easiest to use when date inputs and the SOL basis are consistent. The following issues commonly cause incorrect or confusing results:

  • missing a required input
  • using a stale rate or rule
  • ignoring calendar or holiday adjustments
  • skipping documentation of assumptions

1) Mixing up accrual date vs. filing date

A frequent error is entering the wrong date into the wrong field, such as:

  • putting filing date where the tool expects accrual date, or
  • using an “incident date” without confirming it maps to the tool’s accrual concept.

Impact: The SOL window shifts, which can change which categories appear “in time” vs. “time-barred” in the model.

2) Assuming the SOL is claim-type-specific

This workflow should apply the general/default civil SOL:

  • RSA 508:4
  • 3 years

Pitfall: If you assume a claim-specific SOL but the calculator is using RSA 508:4 as the default SOL for this workflow, your results may not match your expectations.

3) Inconsistent “evaluation date” across runs

If you rerun with different evaluation dates and don’t record them, you can’t reliably compare outputs.

Checklist:

  • Keep evaluation date fixed while testing amounts or category weight changes.
  • Keep accrual date fixed while testing settlement totals or allocation weights.

4) Overlooking warnings

Date-related issues often show up as warnings or notes in the results. If you ignore those alerts, you may miss why allocations changed.

Quick scan:

  • Any SOL/timing warning banner?
  • Any note that the claim falls outside the 3-year RSA 508:4 window?

5) Changing multiple inputs during “what-if” analysis

If you modify accrual date, filing date, and settlement totals all at once, it’s hard to know what caused the allocation to move.

Better approach:

  • One change at a time
  • Compare output before/after each change

Try it

Here’s a practical, repeatable way to test Settlement Allocator for New Hampshire (US-NH) and see how the RSA 508:4 (3-year) general SOL affects results. (Again: this is for modeling and planning support.)

Open the Settlement Allocator calculator and follow the steps above: Run the calculator.

Quick run plan

  • Keep fixed:
    • Jurisdiction: US-NH
    • Evaluation date: choose one date for the analysis run
    • Total settlement amount and claim category amounts: keep constant
  • Vary only:
    • Accrual date

Run A and Run B using an accrual date positioned around the 3-year boundary:

  • Run A: accrual date set so it’s just under 3 years before the evaluation date
  • Run B: accrual date set so it’s just over 3 years before the evaluation date

What to look for

In the results, confirm the model reflects the SOL window by checking for:

  • Timing-status indicators (within vs. beyond the window)
  • Allocation shifts between Run A and Run B
  • Any SOL-related warnings tied to the date boundary

Minimal reference to keep by your notes

  • RSA 508:4 (New Hampshire): general civil SOL period = 3 years
  • Workflow assumption: general/default period only (no claim-type-specific sub-rules applied)

If allocations don’t change between the two runs, double-check:

  • that you’re entering the date into the correct field (especially accrual), and
  • that US-NH is truly selected in the run.

Related reading