Inputs you need for Wage Backpay in New Hampshire

5 min read

Published April 15, 2026 • By DocketMath Team

Inputs you will need

Run this scenario in DocketMath using the Wage Backpay calculator.

If you’re planning to calculate wage backpay in New Hampshire (US-NH) with DocketMath, start by collecting the same core facts every time. Wage backpay calculations are only as accurate as your inputs—especially when you’re comparing what was paid versus what should have been paid.

Below is a practical input checklist designed for the DocketMath wage-backpay calculator for New Hampshire.

Core inputs (most important)

Keep this consistent with the pay records you’ll reference (pay stubs, payroll summaries, agreements). This affects how amounts map to pay periods in many backpay workflows.

  • If hourly: your hourly rate
  • If salary: the hourly/daily-equivalent basis you’re using for backpay
  • Prefer per pay period entries, or
  • Provide totals broken down by time period (so the calculator can reconcile correctly) Examples you might encounter: unpaid hours, incorrect rate, missed premium pay

Jurisdiction-aware limitation input (critical)

  • New Hampshire’s general civil SOL period is 3 years under RSA 508:4.
    • No claim-type-specific sub-rule was found in this brief, so the 3-year general/default period is the rule to apply for this calculator setup.

Practical reminder: A common error is choosing a backpay start date that effectively attempts to cover an “entire employment period” even though RSA 508:4 may restrict the earliest recoverable portion. That error can inflate your result. Your number might still be useful for internal estimation, but it may not match what you can recover under a 3-year lookback approach.

Optional “data-quality” inputs

These don’t always change the headline outcome, but they can prevent avoidable mismatches: Examples: on-call time, training time, missed breaks/premium time

Where to find each input

Collecting the right evidence is faster when you know where to look. Here are common sources for each input in real-world documentation.

Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.

Pay dates, rates, and hours actually worked

  • Pay stubs / earnings statements
    • Hourly rate or salary figures (or conversion info)
    • Gross pay and deductions
    • Pay dates
  • Payroll register / payroll summaries
    • Total earnings by pay period
    • Useful for verifying “what the employer says was paid”
  • Timesheets or time tracking
    • Hours by day/pay period
    • Useful for supporting unpaid or underpaid time

Backpay window dates

  • Offer letter / employment agreement
    • Start date of employment (useful for aligning your backpay start)
  • Pay policy documents
    • Any documented change in rate, method, or compensation structure
  • Your calendar or time logs
    • Especially helpful if access to payroll documentation was limited

Statute-of-limitations alignment (New Hampshire)

  • DocketMath “wage-backpay” calculation settings
    • You’ll enter your chosen start and end dates.
    • Use RSA 508:4 (3-year general SOL) to sanity-check how early your “recoverable window” begins.
  • Your own timeline workflow
    • Count back 3 years from the date you’re treating as the relevant trigger for your workflow.
    • Because this brief did not identify claim-type-specific exceptions, treat the 3-year general/default rule as the baseline lookback for this calculator setup.

Source for the limitation reference: https://www.thelaw.com/law/new-hampshire-statute-of-limitations-civil-actions.391/?utm_source=openai
Statute: RSA 508:4

Run it

Once you have your inputs, you can run the DocketMath wage-backpay calculator for New Hampshire (US-NH).

Enter the inputs in DocketMath and run the Wage Backpay calculation to generate a clean breakdown: Run the calculator.

Suggested workflow (to reduce errors)

  1. Enter your end date first
    This anchors the most recent pay period you’re accounting for.
  2. Enter your start date with SOL alignment in mind
    • New Hampshire’s general civil SOL is 3 years under RSA 508:4.
    • Because this brief found no claim-type-specific sub-rule, apply the 3-year general/default period for SOL alignment.
  3. Add wage rate assumptions
    Use the rate you can support from pay stubs or agreements. If your pay structure changed, consider splitting into different rate segments where your records support it.
  4. Enter what you were actually paid
    Prefer per-pay-period amounts so the output is easier to reconcile against payroll records.
  5. Review output and reconcile with your source documents
    If the result seems high or low, the cause is usually:
    • a mismatched date window
    • an incorrect wage rate
    • entered totals that don’t align cleanly with pay-period logic
    • missing paid amounts (or double-counting)

How outputs change when you adjust inputs

A few input changes commonly drive most of the difference in wage backpay outputs:

  • Backpay start date moved earlier by 12 months
    • Usually increases total backpay, but it may conflict with a 3-year lookback concept under RSA 508:4.
  • Wage rate increases
    • Backpay increases proportionally for any underpaid/unpaid time covered at the higher rate.
  • Pay frequency entered incorrectly
    • Can distort totals if the calculator applies pay-period logic based on the selected frequency.
  • Using one wage rate for a period with rate changes
    • Often causes over- or underestimation. Splitting by distinct rate segments can improve accuracy.
  • Entering actual pay as totals vs. per pay period
    • Totals can work, but per-pay-period entries typically make reconciliation easier.

To start, use the primary CTA and run your numbers here:

  • DocketMath wage-backpay tool: /tools/wage-backpay

Related reading