Why Wage Backpay results differ in New Hampshire

The top 5 reasons results differ

When you run a Wage Backpay calculation in New Hampshire (US-NH) with DocketMath, you may notice that two seemingly similar scenarios produce different outputs. Those differences are usually caused by (1) time-limit filtering and (2) how wage amounts are converted and aggregated across the pay periods you input.

Baseline to keep in mind first: In New Hampshire, the general statute of limitations (SOL) for civil actions is 3 years under RSA 508:4. Jurisdiction data for this project did not identify a claim-type-specific sub-rule, so treat 3 years as the general/default period for SOL lookback in this calculator. (If a specific claim type applies differently, the result could change—but with the information provided, the default general rule is what DocketMath will model.)

Here are the top 5 reasons results differ in US-NH:

1. **Different “lookback start” date (SOL cutoff)

   • DocketMath uses the backpay start/end dates you enter to determine which backpay months fall within the 3-year window.
   • Practical impact: moving the earliest asserted shortfall date forward can exclude earlier months, reducing total backpay; moving it earlier can include more months, increasing total backpay.

2. Misaligned pay periods vs. calendar months

   • Two runs can effectively “bucket” wages differently (e.g., weekly/biweekly pay applied across months vs. monthly aggregation).
   • Even if the same pay rate is used, the way wages are distributed over time can change what DocketMath totals for each month.

3. **Rate inputs aren’t equivalent (hourly vs. salary conversion)

   • Wage backpay outputs can shift depending on whether you input:

     • an hourly rate plus expected hours, or
     • a salary amount plus an assumed hours basis.
   • Example: If the same salary figure is treated with different expected hours (e.g., 35 vs. 40 hours/week), the effective hourly/monthly wage changes—so the backpay difference can be large.

4. Mitigation / earnings offsets applied with inconsistent conventions

   • If your scenario includes interim earnings or offsets, users sometimes structure inputs differently (e.g., entering offsets as a net reduction vs. entering additional earnings to be subtracted later).
   • DocketMath will follow the structure you provide, so differences often come from inconsistent offset formatting between two runs.

5. **Start/end dates vary by a day (boundary effects)

   • A one-day shift can move an entire pay period into or out of the 3-year SOL lookback.
   • Practical impact: when the earliest included wage period is near the cutoff, small date changes can produce outsized total differences.

Common pitfall: If the earliest alleged underpayment date is off even slightly, SOL filtering can exclude/include multiple pay periods, leading to a noticeably different total.

For context on the time limit driving many of these differences: RSA 508:4 provides a general 3-year SOL, so DocketMath may “prune” backpay months outside that 3-year window when the calculation period extends farther back.

How to isolate the variable

To understand why two DocketMath results differ, isolate the inputs like a mini-audit. The goal is to determine whether the change came from (a) SOL cutoff filtering, (b) wage calculation/aggregation, or (c) offsets.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step 1: Freeze the date range first

• Keep wages (rates), expected hours, pay cadence, and offsets the same.
• Re-run by changing only the backpay start/end dates.

What you’ll learn: If totals change primarily with the dates, SOL lookback under the general 3-year rule (RSA 508:4) is likely the driver.

Step 2: Hold dates constant; compare period math assumptions

• Keep start/end dates the same.
• Change only one of the following:

  • pay cadence / aggregation approach (weekly vs. biweekly vs. monthly style inputs)
  • expected hours used for converting rate types

What you’ll learn: If totals change when you change cadence or expected hours, the difference is likely due to conversion/aggregation, not SOL filtering.

Step 3: Validate offsets consistently

• Keep dates and wage assumptions fixed.
• Adjust only offset/earnings inputs—making sure the convention matches between runs.

What you’ll learn: If differences cluster across specific months where offsets overlap, inconsistent offset structure is likely the cause.

Step 4: Use a one-change-at-a-time checklist

Before you interpret results, confirm:

To compare quickly, start from the same base inputs and run small variations rather than changing multiple fields at once.

To run your own comparison, use DocketMath here: /tools/wage-backpay.

Next steps

1. Create a single source-of-truth timeline

   • Write down the earliest date you can support for the wage shortfall.
   • Write down your calculation end date.
   • Because New Hampshire models a general 3-year SOL under RSA 508:4, the earliest date can strongly affect which months are included.

2. Standardize wage inputs

   • Pick one input style (hourly-based or salary-based) and use it consistently across runs.
   • Keep expected hours and pay cadence aligned.

3. Confirm offset entry method

   • If interim earnings exist, ensure both runs represent them the same way in DocketMath.
   • Inconsistent conventions are one of the most common causes of “mysterious” result differences.

4. Run a controlled boundary test

   • Make two versions:

     • Version A: backpay start at the earliest asserted date
     • Version B: backpay start moved forward by ~14–30 days
   • If totals change sharply, you’re likely near the 3-year SOL cutoff under RSA 508:4.

5. Keep a short calculation log

   • Save the input set that produced the result you consider most accurate.
   • When you correct dates or assumptions later, you’ll be able to trace why totals changed.

Related reading

• Wage & Backpay Calculator Guide for Alabama
• Wage & Backpay Calculator Guide for Arizona
• Wage & Backpay Calculator Guide for Colorado