Why Damages Allocation results differ in New Hampshire
4 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
Run this scenario in DocketMath using the Damages Allocation calculator.
When you run DocketMath → damages-allocation (US-NH), you may see different allocations across two cases that look similar on the surface. In New Hampshire, the biggest drivers of divergence tend to be timing and how the calculator applies the jurisdiction’s general limitations rule to your inputs.
Below are the top 5 reasons allocation results differ in US-NH, using the jurisdiction-aware default.
Jurisdiction rule to know up front: New Hampshire’s general civil SOL is 3 years under RSA 508:4. DocketMath applies this general/default period because no claim-type-specific sub-rule was found for US-NH. That means your results can still vary depending on how the tool filters/weights damages that fall inside vs. outside that 3-year window.
Different claim timing relative to the statute of limitations
- In US-NH, DocketMath uses the 3-year general period under RSA 508:4.
- Practical effect: if your dataset includes damages, payments, or accrual/incident-related timing that falls outside the 3-year window, the calculator may allocate different amounts (or exclude more/less) after applying the SOL filter.
Accrual date vs. filing/measurement date mismatch
- Two cases can share the same “incident date,” but have different accrual date assumptions.
- If the accrual date you enter is later or earlier, the boundary of the 3-year SOL window shifts—changing which damages portions land inside vs. outside the actionable period.
**Inconsistent allocation period (partial vs. full time ranges)
- Damages allocation often depends on a start/end measurement range (or time-series structure).
- If one run uses a broader measurement range (e.g., 4–5 years) while another uses a narrower one, different segments of the damages timeline can be cut off by the RSA 508:4 (3-year) limit, producing different totals.
Different damage component mix
- Even with the same dates, the mix of components (for example, recurring vs. lump-sum) can change how much of the total sits near the SOL boundary.
- Amounts concentrated near the cutoff are especially sensitive to even small date changes.
**Data normalization differences (rounding and units)
- If inputs are stored or entered with different units (monthly vs. yearly) or different rounding conventions, computed totals can drift.
- After SOL filtering, small fractional differences can become more noticeable because parts of the timeline may be clipped differently.
Pitfall: If you compare two DocketMath runs without checking accrual date and the measurement range, you can incorrectly assume “the law changed,” when the real reason is that the RSA 508:4 (3 years) cutoff falls on a different part of the timeline.
How to isolate the variable
To identify the exact driver, isolate inputs in a controlled sequence (change one thing at a time):
For US-NH, DocketMath should apply RSA 508:4’s general 3-year period.
Reminder: because no claim-type-specific sub-rule was found, the default period applies.
Run #1: baseline accrual date.
Run #2: change only accrual date by ±30 days.
If allocations swing sharply, the output is likely sensitive to where the SOL cutoff lands.
Run #3: shorten the measurement window end date by 12 months.
Run #4: extend it by 12 months.
If totals shift, the SOL boundary (within the 3-year window) is likely the main reason for discrepancy.
First keep only component mix constant (e.g., recurring vs. lump-sum proportions).
This helps separate SOL timing effects from structural/component effects.
Ensure recurring values use the same cadence (e.g., all monthly or all yearly).
Re-run the same scenario to see whether differences persist after normalization.
Fast triage order for US-NH: start with accrual date and then the measurement range. Under RSA 508:4, time placement relative to the 3-year window is usually the quickest path to explaining allocation differences.
Next steps
- Use /tools/damages-allocation and rerun the comparison in DocketMath, changing only one variable at a time:
- accrual date
- measurement range end date (and/or start date)
- component mix (only after time variables are fixed)
- Track what changes between runs:
- total allocated damages
- which portions fall inside vs. outside the SOL window
- Sanity-check against the jurisdiction default:
- RSA 508:4 (general civil SOL): 3 years
- If you’re comparing multiple filings, build a small “input matrix” of the fields you control:
- accrual date
- measurement start/end
- component cadence
- totals by component
Gentle reminder: this is not legal advice. But aligning your inputs with DocketMath’s US-NH default RSA 508:4 rule can make the “why” behind different damages allocations much easier to see.