Common Wage Backpay mistakes in New Hampshire

The top mistakes

Run this scenario in DocketMath using the Wage Backpay calculator.

When employers miss wage obligations in New Hampshire, wage backpay claims can quickly turn into schedule-and-math problems—especially when you’re using DocketMath (the wage-backpay calculator) to estimate timing and amounts. In US-NH cases, these are the most common mistakes we see.

Not legal advice. This is practical guidance to help you structure your inputs clearly.

1) Using the wrong statute of limitations window

New Hampshire’s general/default civil statute of limitations is 3 years under RSA 508:4. DocketMath will use that default when no claim-type-specific rule is provided.

Common error: assuming the SOL is longer/shorter based on federal norms or because you saw a different state’s rule.

What goes wrong in practice

• Claims filed after the 3-year lookback can be time-barred for older wages.
• Your estimate may reflect wages a court could treat as outside the actionable period.

2) Incorrect wage baseline (gross vs. take-home vs. “what should have been paid”)

A wage backpay estimate must anchor to the wages the employee should have received under the governing wage arrangement and applicable wage framework (for example, an hourly wage and the hours that should have been paid).

Common error: using net pay, take-home deposited amounts, or another number that already reflects deductions or unrelated adjustments.

Example of a typical error

• Entering what the employee received “after deductions” instead of the wage rate × hours that should have been paid.
• The calculator then produces backpay numbers that don’t track the wage obligation.

3) Miscounting work hours (especially overtime, missed shifts, and partial weeks)

Backpay math is extremely sensitive to hour totals and how they’re allocated.

Common mistakes

• Double-counting hours (for example, using both timesheets and payroll extracts that include the same time).
• Dropping unpaid time where the employee worked but payroll didn’t capture it.
• Treating “scheduled” hours as “worked” hours without matching them to the records used for the calculation.

Practical approach: reconcile at least three record types where available:

• timesheets / punch logs
• payroll registers
• corrected payroll (if any)

4) Calculating beyond the actionable window (lookback concept)

Even when the general SOL is 3 years, wage backpay is typically focused on wages that fall within the actionable lookback period tied to the claim/filing date.

Common error: calculating backpay for the entire employment gap (e.g., 4–5 years) even though only 3 years can be pursued under the general/default SOL framework.

Result: inflated estimates that may not match what the actionable period supports.

5) Entering dates in the wrong order or using inconsistent formats

Data hygiene matters because the tool’s date window drives which weeks are included.

Common mistakes

• Setting the “claim date” earlier than the wage start date.
• Mixing date formats (e.g., MM/DD/YYYY vs. DD/MM/YYYY) and accidentally shifting the window.
• Using termination date as the claim date without confirming what you’re modeling in DocketMath.

6) Forgetting adjustments that change the wage math inputs

Backpay estimates often need segmented inputs or exclusions.

Common mistakes

• Using a single wage rate across a period where the employee received known raises or different rates.
• Treating unpaid leave as if it were backpay-eligible work time.
• Failing to incorporate corrected timekeeping records when they change the hours.

7) Assuming interest/penalties are included automatically

Wage disputes can involve add-ons (depending on the governing statute and facts), but your calculator output may be only backpay.

Pitfall: treating an “amount” output as the full judgment number.

If you’re using DocketMath, treat results as backpay estimate components unless you confirm what the output includes.

How to avoid them

DocketMath helps make wage backpay calculations more transparent. The best results come from treating inputs like evidence-backed variables: dates, wage rate, hours, and the actionable window.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

1) Lock down the SOL rule you’re applying (and document it)

For New Hampshire, the general/default civil SOL is 3 years under RSA 508:4. DocketMath’s default aligns with that 3-year lookback when no claim-type-specific rule is provided.

Workflow

• Identify the claim/filing date you’re modeling.
• Use the 3-year lookback for wages under the default framework.
• If another SOL may apply, don’t force the RSA 508:4 assumption—use the correct rule set.

2) Build the wage baseline from the governing wage measure

Use one consistent wage reference:

• hourly rate × worked hours that should have been paid, or
• the correct pay structure used for the role (entered consistently)

Avoid:

• net pay
• “what was deposited”
• totals that already include adjustments you can’t reconcile

Practical checklist

3) Validate hours at the week level (not only the overall total)

Instead of relying on one grand total, sanity-check:

• weeks with missing payroll
• weeks with partial shifts
• overtime weeks

If you need to enter totals, spot-check a few representative weeks to ensure the logic matches your source records.

4) Use consistent date entry and confirm the modeled window

A reliable approach:

• enter the earliest wage period date
• enter the claim/filing date you’re modeling
• ensure the system interprets them consistently

Sanity checks

5) Split the calculation by wage rate changes

If pay changed during the period, run the math in segments rather than one blended wage rate:

• Segment 1: wage rate from Date A to Date B
• Segment 2: wage rate from Date B+1 to Date C

This prevents mixing rates and creating misleading backpay totals.

6) Treat outputs as “backpay estimate components” and keep notes

For each run, write down what the run assumes. For example:

• “Backpay modeled using default 3-year SOL (RSA 508:4)”
• “Wages calculated using hourly rate × worked hours”
• “This run does not include interest/penalties” (if that’s how the tool behaves)

7) Use DocketMath for iteration—then reconcile with records

Once inputs are stable, DocketMath helps you test scenarios quickly, such as:

• changing the claim date slightly (which can shift the lookback boundary)
• moving the wage start date
• updating hours using corrected timekeeping records

If you want to run the numbers, start here: /tools/wage-backpay

Related reading

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