Spreadsheet checks before running Wage Backpay in New Mexico
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
Before you run Wage Backpay in New Mexico (US-NM) with DocketMath, do a quick spreadsheet “sanity pass.” Wage Backpay calculations are often spreadsheet-heavy: they pull dates, hourly rates, hours worked, pay periods, and (sometimes) deductions into one pipeline. A small data issue—especially around dates and row totals—can distort your outcome even if every formula “looks right.”
This checker focuses on common failure modes that affect totals and lookback filtering, without trying to change the underlying legal analysis or your own spreadsheet design.
Key issues the checker is designed to catch in a New Mexico wage backpay spreadsheet
**Expired lookback window (statute of limitations)
- DocketMath uses the general/default statute of limitations for wage claims in New Mexico.
- N.M. Stat. Ann. § 31-1-8 provides a 2-year general SOL period.
- No claim-type-specific sub-rule was found for this checker, so the 2-year default applies to the spreadsheet’s lookback logic.
- Practically, the checker helps ensure rows that fall outside the 2-year window do not incorrectly remain in (or get excluded from) your backpay totals.
Date parsing errors
- Pay period start/end dates entered as text (for example,
04/01/2024) that may be stored inconsistently across rows. - Blank or partially blank date fields that can cause rows to be treated as “in range” or “out of range” incorrectly.
- Mixed date formats that lead to misordered comparisons and unexpected filtering results.
Off-by-one period boundary problems
- Inclusive comparisons like
>=and<=can accidentally include a day you intended to exclude (or exclude a day you intended to include). - Misalignment between the date you use for “work performed” versus the date you use for “payment” or “posting.”
- These issues can create small but meaningful swings in totals—especially near the boundary of the 2-year window.
Rate / hours mismatches
- Hourly rate stored in the wrong scale (for example, entering
20when the sheet expects0.20, or vice versa). - Hours entered in minutes but interpreted as hours (for example, entering
90meaning “1.5 hours,” but the sheet reads it as “90 hours”). - Unit mismatches usually cause large total jumps, which the checker flags as anomalies.
Sign and direction errors
- Deductions added instead of subtracted (or vice versa).
- Negative hours carried forward in a way that flips intended direction and impacts totals.
- These can look subtle until you compare checker warnings with your underlying row math.
Row duplication
- Data imported twice from multiple exports, or repeated pay statements added into the table.
- Even if dates, rates, and hours are correct, duplicated rows will inflate totals.
- The checker is designed to catch patterns consistent with duplication.
Missing pay components
- If your sheet models “wages” using only base rate, you may undercount components you separately included elsewhere (like overtime or differentials).
- This checker can’t fix incomplete input categories on its own, but it can help you notice when totals behave unexpectedly given your modeled fields.
Pitfall to watch: A spreadsheet can be mathematically consistent and still be “off” if the lookback window is applied to the wrong date column (for example, filtering by payment date instead of work performed date). The checker’s purpose is to highlight those mismatches before you finalize totals.
When to run it
Run the New Mexico Wage Backpay spreadsheet checker right after you import your data and before you run any final calculations. The goal is to catch structural issues early (columns, date formats, row alignment), while the dataset is still easy to correct.
A practical workflow:
Import pay statements / timesheets into a single table
- Normalize your column names and types (dates, hours, rates, and any wage-component fields you use).
Do a quick column validation pass
- Ensure the date fields used for “work performed” are populated on every relevant row.
- Check that pay period start/end fields are complete or that your model uses a consistent single date.
Run DocketMath Wage Backpay with the checker enabled
- Treat results like a preflight checklist—use them to identify the highest-impact data problems first.
Fix flagged rows and rerun
- Start with warnings tied to SOL filtering, missing/invalid dates, duplicate rows, and unit scale (hours/rates).
- After those are stable, you can have more confidence in the final totals.
Only then finalize totals
- Once filtering and input normalization are consistent, downstream calculations are far less fragile.
How the output changes when a flag appears (quick reference)
| Checker flag | Typical cause | How your output changes |
|---|---|---|
| Out-of-range for SOL | Work dates older than the 2-year window | Those rows should be excluded from backpay totals |
| Date format warning | Dates stored as text / inconsistent formats | Rows may be misclassified into/out of range |
| Boundary warning | Inclusive/exclusive logic differs from intended rule | A small slice of days flips between included vs excluded |
| Rate/hour anomaly | Hours or rates interpreted at the wrong scale | Totals jump sharply—sometimes by 10× or 100× |
| Duplicate row warning | Same pay period imported twice | Totals inflate even though dates/rates may look correct |
Because this checker uses the general 2-year SOL under N.M. Stat. Ann. § 31-1-8 (and not a claim-type-specific period), the calculator’s lookback behavior is based on that default assumption. This is intentional so DocketMath and your spreadsheet filtering don’t silently diverge.
Try the checker
Use DocketMath’s Wage Backpay tool as your jurisdiction-aware validation step:
- Primary CTA: /tools/wage-backpay
For an efficient first trial:
- Paste or upload a small slice first (for example, 2–4 pay periods).
- Confirm the checker warnings match what you expect from your data.
- Then run the full dataset.
Before testing, quickly confirm these inputs match how the checker will interpret your table:
Note / gentle disclaimer: This checker helps validate spreadsheet inputs and filtering behavior, and it applies the general 2-year SOL from N.M. Stat. Ann. § 31-1-8 because no claim-type-specific sub-rule is included in this checker’s rule set. It’s not a substitute for legal advice, but it can help you avoid avoidable spreadsheet errors before you rely on totals.
Open the tool here while you test: /tools/wage-backpay.
