How to interpret Wage Backpay results in New Hampshire
6 min read
Published April 15, 2026 • By DocketMath Team
What each output means
Run this scenario in DocketMath using the Wage Backpay calculator.
DocketMath’s Wage Backpay calculator (jurisdiction: New Hampshire (US-NH)) uses your wage inputs to estimate an exposure window and an estimated backpay amount based on New Hampshire’s general statute of limitations for civil actions.
In New Hampshire, the default limitations period for civil actions is 3 years under RSA 508:4. For this calculator’s wage backpay modeling, no claim-type-specific sub-rule was found, so the results reflect the general/default period (not a special rule for a specific wage claim type).
When you run the calculator via /tools/wage-backpay, the outputs generally fall into three categories:
1) Backpay window (how long the claim reaches back)
This is the “lookback” period used to determine which wage dates are potentially included.
- General SOL period used: 3 years (RSA 508:4)
- Anchor date used: typically the date tied to when the backpay claim is filed or another event you select in DocketMath’s input flow.
- Practical meaning: if the window reaches back 3 years, wages earned more than 3 years before the anchor date may not be included in the tool’s estimate.
2) Covered wages vs. excluded wages (what’s counted)
Your wage timeline is partitioned based on whether each wage period falls inside or outside the 3-year lookback window.
- Potentially covered portion: wage amounts occurring within the 3-year window
- Potentially excluded portion: wage amounts occurring outside the window
This partition is meant to help you interpret why the estimated total looks the way it does. DocketMath can’t account for every litigation detail, but the window logic is the core reason some wage dates are counted and others are not.
3) Estimated wage backpay amount (the computed total)
This is the dollar figure derived from your wage inputs, such as hourly rate and hours, or from a wage shortfall input—depending on the exact DocketMath form you use.
In practical terms:
- If your work history includes multiple months or pay periods, the calculator sums only the portions that fall inside the backpay window.
- If your alleged wage shortfall overlaps the lookback boundary (for example, some months are inside the window and some are outside), the estimated total reflects only the inside-the-window portion.
Important clarification (not legal advice): The “backpay amount” is an estimate produced by applying a 3-year default SOL (RSA 508:4) to the dates you enter. It is not a guarantee of what a court would award, and it does not replace case-specific legal analysis.
What changes the result most
In the New Hampshire version, the output is most sensitive to the inputs that determine (1) which dates fall inside the 3-year window and (2) the size of the wage gap for those covered dates.
These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.
- date range
- rate changes
- assumption changes
1) The anchor date (what the 3-year window is measured from)
Changing the anchor date shifts the entire 3-year lookback window.
- Moving the anchor date forward moves the 3-year window forward.
- That can cause earlier wage periods (previously inside the window) to become excluded, which typically reduces the estimated total.
Because the calculator is applying RSA 508:4’s general 3-year period, anchor date changes can materially affect the result—especially where the alleged underpayment occurred largely more than ~36 months before the anchor.
2) The start/end dates for the wage shortfall (timeline overlap)
Even if your wage rate stays the same, altering the wage shortfall timeline changes how much of it overlaps the 3-year window.
Use this quick check:
- Does the shortfall begin more than 3 years before the anchor date?
- Does the shortfall end within the 3-year window?
- Is the shortfall long enough that only part of it overlaps the window?
Long-running disputes often produce large swings because part of the timeline may be cut off by the RSA 508:4 limitations horizon.
3) Wage arithmetic inputs (rate and hours)
Once the window is set, the per-period wage math drives the magnitude of the estimate.
- Higher hourly rate or higher hours per pay period generally increases the calculated backpay for covered periods.
- If the wage gap is concentrated inside the lookback window, the rate/hours inputs have an outsized effect on the total.
If a result seems too high or too low, a practical first step is to validate the rate and pay-frequency assumptions used to compute the covered portion.
4) Methodology inputs (if your form includes them)
Some DocketMath flows include toggles or fields that affect how the shortfall is computed (for example, “expected vs. actual” approaches). If the tool asks you to represent wages in a particular way, that delta is critical.
Common pitfall: Mixing concepts (for example, entering a wage measure that doesn’t match the tool’s expected baseline) can make the computed total misleading. Keep your wage inputs consistent across all dates and entries.
Next steps
Use the results as a structured way to sanity-check your inputs and understand what drove the estimate.
After you run the Wage Backpay calculation, capture the inputs and output in the matter record. You can start directly in DocketMath: Open the calculator.
Step 1: Confirm the SOL-driven timeline logic
Since New Hampshire uses the general 3-year statute of limitations under RSA 508:4, check:
- Which date DocketMath treated as the anchor date
- How far back the window reaches in the calculator output
- Whether your entered shortfall periods overlap that window
Step 2: Identify which periods are counted vs. excluded
If the calculator provides any breakdown or summary, look for:
- which months/pay periods fall inside the 3-year window (counted)
- which fall outside (excluded)
A smaller estimate than expected often comes from timeline cutoff, not necessarily from a smaller wage gap.
Step 3: Run “what changes the most” sensitivity checks
To understand whether the estimate is driven more by timeline overlap or by wage arithmetic, re-run two variations:
- Adjust anchor date within a realistic range tied to filing timing (keep wage numbers constant)
- Adjust the shortfall start date (keep rates/hours constant)
If the total changes dramatically, the estimate is likely being driven primarily by SOL window overlap.
Step 4: Create a simple input record
Document the inputs you used so you can reproduce or revise the estimate:
- wages expected vs. wages paid (as you entered them)
- pay frequency (weekly/biweekly/etc., if used)
- shortfall start/end dates
- rate and hours assumptions
Even without seeking advice, having a clean record helps you validate whether the calculator is reflecting your intended timeline and math.