Spreadsheet checks before running Wage Backpay in New Hampshire

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Running a wage backpay calculation in New Hampshire with DocketMath Wage Backpay is only half the workflow—the other half is confirming that your numbers won’t be thrown off by time limits. The Spreadsheet checker helps you validate the inputs that affect whether wages fall inside the applicable statute of limitations window before you run the calculation.

For New Hampshire, the general/default civil statute of limitations period is 3 years under RSA 508:4. No claim-type-specific sub-rule was found for this wage backpay workflow, so the checker applies the general 3-year rule rather than switching logic based on a particular wage theory. (In other words: if your spreadsheet varies treatment by claim type, the checker will not assume different SOL rules—your sheet’s date logic still needs to align with your intended approach.)

Here’s what the checker is designed to catch before you calculate:

  • Out-of-window wage rows

    • Detects line items with work dates earlier than the 3-year lookback from the relevant reference date you use in the spreadsheet.
    • Flags those rows so you can confirm whether they should be excluded or retained with a clear rationale in your workbook.
  • Reference date mismatches

    • Many spreadsheets accidentally use the wrong date column as the “anchor” (for example, using an incident date instead of a filing or demand date).
    • The checker highlights whether the “as-of” date drives the 3-year window consistently across the sheet.
  • Off-by-one spreadsheet errors

    • Date math errors are common: using month/year text fields, mixing UTC and local time conversions, or storing dates as strings.
    • The checker ensures dates are treated as real date values, so the lookback calculation behaves predictably.
  • Duplicate or overlapping periods

    • When employees or pay categories are split across multiple rows, spreadsheets can double-count days (e.g., two rows that both cover “Week of 1/15/2022”).
    • The checker flags overlaps so the total backpay figure isn’t inflated.
  • Unclear pay-date vs. work-date conventions

    • Wage backpay worksheets often include both work dates and pay dates.
    • The checker helps you confirm you’re using the same “date basis” across the entire sheet (so the 3-year window doesn’t accidentally change halfway through).

Pitfall: If your spreadsheet uses a work-date column in one tab and a pay-date column in another, the 3-year window can silently shift—producing a backpay number that looks precise but is internally inconsistent.

Statute-of-limitations rule the checker uses (New Hampshire)

Because this is the general rule, the checker applies it as the default across the spreadsheet flow.

Gentle note: This tool-oriented checker is meant to surface date and spreadsheet logic issues. It isn’t legal advice, and it can’t determine how a specific legal position should be framed in your case.

When to run it

Run the checker at the point in your process where dates are still easy to fix—before DocketMath Wage Backpay locks in totals.

A practical sequence for New Hampshire wage backpay spreadsheets:

  1. Before you run DocketMath Wage Backpay

    • Run the checker immediately after importing or typing your wage rows (hours/dates/rates).
    • Fix date formats and the reference date first.
  2. After you adjust the date anchor

    • If you change the filing-related anchor date used to determine the 3-year lookback, rerun the checker.
    • This is the fastest way to catch “everything got pushed into/out of window” mistakes.
  3. After you consolidate or restructure rows

    • When you group by employee, week, or pay category, rerun the checker.
    • Overlaps and duplicates frequently appear during consolidation.
  4. After you exclude rows

    • If the checker flags out-of-window rows and you exclude them, do a final run to confirm the spreadsheet’s included set is consistent.

Use these quick checklist items to decide whether today is a “run the checker now” day:

Try the checker

To try the Spreadsheet checker in DocketMath, follow this approach for a clean jurisdiction-aware setup for US-NH:

  1. Open Wage Backpay

    • Start at the primary CTA: /tools/wage-backpay
  2. Add your New Hampshire dataset

    • Ensure your sheet includes, at minimum:
      • Work date (or the date basis you intend to use for the SOL window)
      • Hours or units
      • Rate (or enough fields for DocketMath to compute wage amounts)
      • The reference/anchor date your spreadsheet uses for the lookback calculation
  3. Run the Spreadsheet checker

    • Use it to validate:
      • Dates are real date values (not text)
      • The lookback window is computed as 3 years under RSA 508:4
      • Rows falling outside the window are identified rather than silently included
  4. Review flags and decide how to treat out-of-window rows

    • The checker doesn’t decide your legal strategy; it helps you avoid math errors.
    • Treat flagged rows consistently in your workbook (for example, exclude them from totals if that’s your defined workflow, or keep them in a separate ledger).
  5. Then run Wage Backpay

    • With verified date logic, DocketMath Wage Backpay output is less likely to be skewed by time-window mistakes.

How outputs change when inputs are fixed

Here’s the effect you should expect when the checker finds issues:

Issue the checker flagsTypical spreadsheet symptomLikely effect on Wage Backpay totals
Out-of-window work datesTotal includes older periodsTotal decreases once excluded rows are removed
Wrong reference/anchor dateWindow shifts forward/backTotal can swing significantly (days move across the 3-year cutoff)
Date stored as textInconsistent parsingMissing or misclassified rows → totals may be too low or too high
Overlapping weekly rowsDuplicate weeks in multiple linesTotal increases because wages are counted twice

Warning: Date logic problems often look like “real” wage differences. The checker is designed to surface those problems early so you don’t spend time reconciling totals that shouldn’t have been calculated that way.

Related reading