Choosing the right Wage Backpay tool for New Mexico

7 min read

Published April 15, 2026 • By DocketMath Team

Choose the right tool

Run this scenario in DocketMath using the Wage Backpay calculator.

If you’re looking at wage backpay in New Mexico (US-NM), the first decision is picking the right DocketMath setup so your results reflect the rules that apply to your situation. Even when the law gives a single, simple default deadline, the inputs you enter can change the outcome dramatically—especially when backpay spans multiple pay periods.

This guide walks you through how to choose the right modeling approach inside DocketMath (tool: wage-backpay) using N.M. Stat. Ann. § 31-1-8 as the default statute of limitations for wage-backpay timelines. (If a different limitations rule applies to your specific scenario, your recoverable window may be different.)

Start with the New Mexico deadline (default rule)

For most wage-backpay calculations where you don’t have a claim-type-specific limitation identified, use the general/default statute of limitations:

  • General SOL period: 2 years
  • General statute: N.M. Stat. Ann. § 31-1-8

Important clarity: the brief instruction for this jurisdiction notes that no claim-type-specific sub-rule was found. So this content uses the 2-year general/default period as the baseline. If your matter involves a different limitations rule, the deadline could change.

Note: Because this page uses the general/default SOL in N.M. Stat. Ann. § 31-1-8, your deadline may differ if your case involves a statute or scenario with a different limitations rule. DocketMath can help you model outcomes, but it’s not a substitute for legal review.

Use the DocketMath wage-backpay tool (and pick the right modeling path)

In the DocketMath Wage Backpay tool (wage-backpay), you’ll typically model backpay by entering wage amounts and the date range you want evaluated. Your goal is to calculate:

  • total unpaid or underpaid wages within the recoverable window, and
  • the effect of your start date and end date boundaries when measured against the 2-year default SOL.

When you choose the tool setup correctly, two things line up:

  1. The date logic (what portion falls inside 2 years) matches New Mexico’s general SOL.
  2. Your wage inputs reflect how wages were actually calculated (for example, hourly vs. salary converted to an hourly equivalent, and the correct wage/rate basis).

Even small differences in wage assumptions (like how “regular” wage is determined) can move the final number.

Key inputs to enter for New Mexico wage backpay

Before you run /tools/wage-backpay, use this checklist to make sure your inputs match your records:

  • Work dates
    • Enter the earliest and latest dates that wages were allegedly unpaid or underpaid.
  • **Anchor or decision/trigger date (if your workflow uses it)
    • If DocketMath’s structure uses an “anchor” date to measure the recoverable period, enter the date that drives the “two-year window” in your timeline.
  • Wage basis
    • Provide the hourly rate when that’s how the job was paid, or use a salary-to-hourly conversion method that matches how your pay was computed and documented.
  • Pay schedule
    • Weekly, biweekly, semimonthly, etc.—this affects how totals map to pay periods.
  • Underpayment amount
    • Either:
      • the difference between “should have been paid” and “was paid,” or
      • unpaid hours multiplied by the correct rate.
  • **Hours (if applicable)
    • If you have time records, enter hours per pay period or totals in the structure the tool expects.

How the output changes when you change dates

A common issue isn’t the arithmetic—it’s assuming the entire time span is recoverable. Under the default New Mexico rule, your modeling window should default to 2 years under N.M. Stat. Ann. § 31-1-8.

In practice, that means:

  • If you set a start date earlier than two years before your anchor date, DocketMath should exclude the portion outside the 2-year window (under the default rule).
  • If you shift the anchor date forward, you may include more of the earlier period—up to what the 2-year SOL allows.
  • If the alleged underpayment is concentrated near the start of your claimed period, small date changes can produce large percentage swings in the recoverable amount.

That’s why the “right tool” is partly about using the tool’s date slicing correctly, not just entering numbers.

Pick the “right tool” by matching your data quality (what matters most in DocketMath)

Not every set of documents tells the same story. Choose the approach that best matches how complete your facts are:

If your records look like…Your best emphasis in DocketMath
Pay stubs + exact underpaid hoursFocus on hour totals and rate differences
Pay stubs but not exact hoursFocus on pay-period deltas (what should vs. what was paid)
You know only the overall time span and a rateUse date-range logic carefully; validate assumptions about hours
Multiple wage rates over timeSplit the period so each rate segment is modeled correctly

If you’re unsure where the best emphasis lies, start simple: align your date inputs and wage basis first, then refine.

For quick access, start here: /tools/wage-backpay.

Next steps

After you’ve chosen the DocketMath Wage Backpay tool and committed to the New Mexico general/default SOL of 2 years under N.M. Stat. Ann. § 31-1-8, you can move from data gathering to calculation.

Use the Wage Backpay tool to produce a first pass, then share the output with the team for review. You can start directly in DocketMath: Open the calculator.

Step 1: Confirm your anchor date logic in DocketMath

Before running calculations, decide what date you’ll treat as the anchor in your workflow (for example, the date that drives the wage-backpay limitations window in your timeline). Then verify:

  • the anchor date is applied consistently, and
  • your input start and end dates create the slice of time you intend.

Pitfall to avoid: an anchor date that doesn’t match your case timeline can change how many pay periods fall inside the default 2-year window. The output may look precise, but it would be precise about the wrong period.

Step 2: Build a clean wage picture before you calculate

Gather the items that most directly map to the tool’s inputs:

  • pay stubs for the relevant period
  • any time records or schedules
  • the wage rate source (e.g., offer letter, policy, written agreement)
  • evidence showing why the amount was underpaid (even in a general sense—like rate mismatch or corrected hours)

You don’t have to attach documents to run /tools/wage-backpay, but you do need accurate facts to avoid “math on top of wrong assumptions.”

Step 3: Run two scenarios to understand sensitivity

Before relying on the result, run at least:

  • Scenario A (baseline): use your best estimate of start/end dates and apply the 2-year window based on N.M. Stat. Ann. § 31-1-8.
  • Scenario B (stress test): shift the start date or anchor date slightly (for example, about 30 days) to see whether the recoverable amount changes sharply.

If the output is very sensitive, treat that as a prompt to re-check:

  • date boundaries, and
  • whether you have complete records for every pay period the tool included.

Step 4: Validate totals against pay-period expectations

After you run the tool:

  • sanity-check that your calculated wages roughly align with the pay periods included inside the window
  • confirm that the tool used the rate logic you intended, especially if rates changed over time

This helps ensure the tool is calculating the right thing—not just calculating correctly.

Step 5: Prepare the output for your next workflow step

When you’re ready, capture:

  • the recoverable backpay total within the 2-year window
  • the date range used
  • the wage inputs (rate/basis and deltas) that drove the calculation

DocketMath outputs are most useful when you can explain them quickly: what time period counted and why, and which wage/rate assumptions were applied.

Related reading