Why Wage Backpay results differ in New Mexico

5 min read

Published April 15, 2026 • By DocketMath Team

The top 5 reasons results differ

In New Mexico, DocketMath’s Wage Backpay calculator uses jurisdiction-aware rules built around the state’s general limitations period. For New Mexico, the default statute of limitations (SOL) is 2 years under N.M. Stat. Ann. § 31-1-8. DocketMath applies this general/default period because no claim-type-specific sub-rule was found for wage backpay timing. In other words, the calculator doesn’t switch to a different SOL just because the wage theory changes.

Even with the same jurisdiction and the same general SOL, wage backpay results can diverge from one run to another. Here are the top 5 reasons you’ll commonly see different totals in New Mexico:

  1. **Different “lookback” cutoffs (when you count from)

    • With a 2-year general SOL, DocketMath generally limits included wages to the relevant 2-year window from the start date you enter (or the operational event date you select).
    • Small date changes can shift which pay cycles fall inside vs. outside the window—sometimes changing the result by whole pay periods.
  2. **Incorrect pay-period inputs (frequency mismatch)

    • Backpay is sensitive to whether wages are entered as weekly, biweekly, semimonthly, or monthly.
    • If you input weekly wages but the case is effectively biweekly (or vice versa), the calculator may count the wrong number of pay periods and produce a different total—especially around month boundaries.
  3. Holdback or off-by-one day effects

    • Date-based backpay windows can include or exclude partial periods depending on how start/end dates map into covered pay periods.
    • A 1-day difference in the anchor date can affect whether a paycheck is treated as fully covered, partially covered, or excluded.
  4. Rate vs. hours mix-ups

    • Some runs use hourly rate × hours; others rely on a precomputed wage amount per period.
    • If you blend approaches (for example, providing a total pay figure but also entering hours/rate assumptions that imply a different total), you can get a swing in the computed “owed” amounts.
  5. Different earnings baseline assumptions

    • Backpay is typically “what was owed minus what was actually paid” (or minus whatever interim-earnings baseline you provide).
    • If two runs use different baseline inputs—such as different assumptions for interim earnings, paid amounts, or what counts as already compensated—the net backpay can change even when the SOL window and pay frequency match.

Pitfall to watch: The SOL difference doesn’t only change the final number—it can change the set of pay periods included. If two runs use different date anchors, you’re not comparing “the same case with different math.” You may be comparing different covered time spans.

How to isolate the variable

To diagnose why your New Mexico results differ, treat DocketMath like a controlled test: change one thing at a time, and keep everything else constant.

Use this checklist:

  • Verify the date you used to define the 2-year lookback consistent with N.M. Stat. Ann. § 31-1-8 (and remember: the calculator is using the general/default SOL because no claim-type-specific rule was found).
  • Ensure the payroll frequency (weekly/biweekly/semimonthly/monthly) matches the pay schedule relevant to the wage calculations.
  • Use either an hourly approach (rate + hours) or a pay-per-period wage approach—don’t unintentionally mix methods across runs.
  • If you’re using dates, confirm they align with how the tool maps dates into included/partial pay periods.
  • Keep interim earnings and “already paid” values consistent across runs; differences here often change the net result even if the gross owed portion is the same.

If you want the fastest path to diagnosis, run DocketMath multiple times with only one change per run:

  1. Keep all wage and date inputs fixed; change only the SOL anchor date.
  2. Keep dates fixed; change only pay frequency.
  3. Keep dates and frequency fixed; change only rate/hours (or pay-per-period amounts).
  4. If totals still don’t match, change only baseline/paid/interim-earnings inputs.

If you’re running calculations directly, start at:
Run DocketMath’s Wage Backpay calculator

Gentle note: This is troubleshooting guidance for calculator inputs and outputs, not legal advice. In real cases, the exact facts and how dates/wages are characterized can materially affect results.

Next steps

  1. Create a “two-run” comparison table
    • Side-by-side fields: dates (start/end anchors), pay frequency, rate/hours or pay-per-period method, baseline/paid amounts, and any interim earnings assumptions.
  2. Determine whether the mismatch is time-window or rate/math driven
    • If the date inputs cause different included paychecks, the issue is likely SOL-window/date anchoring.
    • If the covered time span appears the same but totals differ, focus on payroll math inputs (frequency, rate vs. hours, period counting) and baseline/paid assumptions.
  3. Re-run with corrected inputs
    • After correcting the suspected variable, verify that the included pay periods match your expectations—then confirm the updated totals.

Related reading