How to run Damages Allocation in DocketMath for New Hampshire

Step-by-step

This guide walks you through running Damages Allocation in DocketMath for New Hampshire (US-NH) using jurisdiction-aware rules. It also explains how New Hampshire’s general statute of limitations (SOL)—3 years under RSA 508:4—can affect which portions of your damages timeline may be treated as allocable.

Educational only; this is not legal advice.

1) Open the calculator

1. Go to DocketMath’s Damages Allocation tool: /tools/damages-allocation
2. Select or confirm the jurisdiction as New Hampshire (US-NH) so the calculator applies the correct jurisdiction rules.

2) Understand the SOL rule DocketMath uses for New Hampshire

For New Hampshire, DocketMath uses the general/default civil SOL period:

• General SOL Period: 3 years
• General Statute: RSA 508:4
• Baseline assumption in this guide: Because no claim-type-specific SOL sub-rule was found in the jurisdiction data provided, this article treats the 3-year general period as the baseline limitation model. In other words, the calculator’s SOL filtering is based on that general default unless you supply inputs that reflect a different limitation treatment.

What this means practically: DocketMath is designed to filter/allocate damages based on how your damages timeline overlaps a rolling 3-year window tied to your reference date and the dates you enter.

3) Enter damages inputs (and keep them time-indexed)

Damages Allocation typically works best when you provide damages in time buckets or dated components.

To get clean, understandable outputs:

• Provide each damages component with an associated date range (for example, by year, month, or phase).
• Use consistent date boundaries (for example, “01/01/2022–12/31/2022” style ranges).
• Avoid mixing a lump sum without coverage dates with dated buckets; if you do use a total, ensure its coverage is clearly described so the tool can allocate consistently.

Common types of inputs you may see in the tool interface:

• Damage component amount(s) (e.g., economic losses, fees, or other categories)
• Start and end dates for each component
• Optional toggles for allocation logic (if exposed by the calculator)

4) Add the claim timing information the calculator needs

Next, enter the dates that define the limitation window the tool will apply.

At minimum, you typically provide:

• A reference point such as a filing/trigger date (the date the 3-year window is counted back from)
• The relevant event/accrual/conduct dates (or however the tool maps your timeline—usually via the dates you included with each damages bucket)

Because the applicable SOL baseline here is 3 years under RSA 508:4, DocketMath can determine how much of your dated damages timeline falls inside vs. outside that rolling 3-year period.

A practical way to anticipate results:

• If a damages bucket is entirely within the last 3 years before your reference date, it is more likely to be treated as allocable/includable.
• If a bucket is partly outside, the calculator may allocate a portion (often pro-rata, depending on its method).
• If a bucket is entirely outside, it is more likely to be treated as non-allocable for SOL-filtering purposes.

5) Run the allocation

1. Click Calculate
2. Review the outputs, especially:

   • The allocable damages total
   • The included vs. excluded breakdown (by component and/or time period)
   • Any displayed explanation of the SOL filtering logic (for example, what the tool considered the “in-window” portion)

6) Check outputs against your timeline

Before exporting or using results:

• Confirm the calculator reflects the 3-year SOL baseline consistent with RSA 508:4.
• Look for any output rows/periods labeled as outside the SOL window.
• If results are unexpected, the most common cause is a date mismatch, such as:

  • using a different accrual/event date than your records,
  • or selecting a reference/filing date that shifts the rolling 3-year window.

7) Iterate: adjust dates, not just amounts

To test sensitivity and verify your modeling assumptions:

• Keep amounts the same.
• Change one date input at a time (for example, shift a bucket by 30–90 days).
• Compare how the allocable total changes. This makes it easier to reconcile results later and understand why the tool included or excluded specific parts.

Common pitfalls

• Relying on the wrong SOL baseline

  • This guide assumes the general/default 3-year SOL under RSA 508:4, because no claim-type-specific sub-rule was found in the provided jurisdiction data.
• Using inconsistent date granularity

  • Mixing year-only dates with exact timestamps can create subtle gaps/overlaps that affect allocation.
• Changing the reference date without realizing the window shifts

  • If the filing/trigger/reference date changes, the “3-year back” window moves, which can change inclusion/exclusion.
• Entering lump sums without date coverage

  • A single total without a clear coverage range can force the tool into assumptions or push the result toward allocation you didn’t intend.
• Double counting overlapping periods

  • If two damages buckets cover the same time range, totals may effectively stack unless the buckets are mutually exclusive.
• Assuming SOL exclusion is strictly all-or-nothing

  • When a bucket partially overlaps the SOL window, the calculator may include a portion rather than excluding the entire bucket.

Try it

Use this quick “sanity check” workflow:

1. Set jurisdiction to New Hampshire (US-NH).
2. Add at least two damages buckets:

   • one clearly inside the 3-year window (RSA 508:4),
   • one clearly outside the window.
3. Set both bucket amounts to the same figure (for example, $10,000 each).
4. Run the calculator and confirm whether:

   • the “inside” bucket is included (or allocable), and
   • the “outside” bucket is excluded (or allocable reduced to zero/near zero).
5. Controlled variation: shift the outside bucket’s date range so its start is exactly 3 years before your reference date, then re-run and observe the change.

If you need a consistent place to build this workflow, start at /tools/damages-allocation and keep your date boundaries consistent with any other DocketMath modeling you do.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules