Common Damages Allocation mistakes in New Mexico

6 min read

Published April 15, 2026 • By DocketMath Team

The top mistakes

Run this scenario in DocketMath using the Damages Allocation calculator.

When people use DocketMath to allocate damages in New Mexico, they usually hit the same allocation errors—often because the jurisdiction-aware inputs are incomplete or inconsistent (even when the underlying math looks fine). Below are the most common mistakes we see in US-NM workflows, and what breaks when you enter the wrong inputs into the /tools/damages-allocation calculator.

1) Using the wrong New Mexico statute of limitations (SOL) for timeliness gates

A common failure pattern is building a damages model and only later checking whether claims are timely. In New Mexico, the general SOL for civil actions is 2 years under N.M. Stat. Ann. § 31-1-8.

Important: No claim-type-specific sub-rule was provided in this brief, so the content below uses the general/default period. Don’t assume a longer or shorter SOL applies unless you confirm it for the specific claim type.

Impact on allocation:
If you include damages that accrue outside the 2-year window, your allocation may overstate recoverable categories and inflate the totals returned by the damages-allocation tool.

Warning: A model can look mathematically “clean” while still counting legally non-recoverable losses. Always treat the SOL gate as an input, not a final afterthought.

2) Treating “total damages” as if it can’t be decomposed

Another frequent issue is entering only a single lump-sum value (e.g., “$120,000 total”) and skipping category inputs like medical expenses, lost wages, or other components.

Impact on DocketMath outputs:

  • The output may stay in a single bucket rather than splitting into categories.
  • Later adjustments (like excluding time-barred amounts) become harder because there’s nothing to re-cut by category.
  • Sensitivity checks (“what happens if medical is reduced by $X?”) become impractical.

Quick check: If you can’t explain where each dollar came from, you probably haven’t allocated far enough for timeliness filtering to be reliable.

3) Mixing dates in a way that causes inconsistent “time window” math

Even when users remember the 2-year rule, they sometimes apply it inconsistently across categories—for example:

  • Using the incident date for one category but a notice date for another
  • Treating settlement dates as if they were accrual dates
  • Updating totals without updating the associated date ranges

Impact on DocketMath:
You can end up with a breakdown that looks coherent, but effectively uses different timeliness cutoffs per category. That’s when allocations stop being defensible.

4) Double-counting overlapping losses across categories

Double-counting is common when the same economic harm shows up in multiple documents (for instance, wage statements plus a damages report that already includes those wages).

Examples of overlap patterns:

  • “Lost wages” already include overtime, but overtime is added again
  • Medical bills are split into multiple categories, but the same bill appears twice under different labels
  • Benefits received or reimbursements are included both as gross amounts and again as separate additions

Impact on allocation totals:
Your grand total can inflate even when each category subtotal seems internally consistent.

5) Relying on generic timing instead of New Mexico’s general SOL gate

Many workflows assume a default SOL unless you actively configure jurisdiction-aware settings. When you forget to align the model with US-NM and N.M. Stat. Ann. § 31-1-8, you can end up filtering the wrong set of losses.

Impact on DocketMath:
Even with correct facts, incorrect jurisdiction or an unset timeliness window can produce an allocation that doesn’t match the 2-year general gate.

6) Not separating “accrual” from “filing”

A subtle but common error is anchoring the cutoff to the filing date when the model should be applying an accrual-based time window (or vice versa).

Impact on DocketMath:
If the time window is anchored incorrectly, category totals can shift dramatically—even if the underlying dollar amounts are accurate.

Pitfall: If you can’t identify which date rule you used (incident vs. accrual vs. discovery vs. filing), you won’t be able to explain why some losses were excluded and others weren’t.

How to avoid them

The goal is simple: make your damages model explainable, consistent, and aligned to New Mexico’s general SOL of 2 years under N.M. Stat. Ann. § 31-1-8. Use the checklist below to tighten your DocketMath → /tools/damages-allocation workflow.

Gentle note: This is a practical modeling guide and not legal advice. SOL rules can be claim- or fact-specific, so verify the applicable standard for your situation.

Step 1: Lock the timeliness gate first (US-NM)

  • Confirm the general/default SOL applies: 2 years under N.M. Stat. Ann. § 31-1-8
  • Apply the same cutoff logic across every damages category you input

If you later determine the claim requires a different timing rule, update the gate and rerun the allocation.

Step 2: Use category-level inputs, not one lump sum

Build explicit buckets so you can:

  • Remove or adjust time-barred portions
  • Run internal consistency checks
  • Explain the allocation to a reviewer (or to your future self)

A practical set of buckets in DocketMath includes:

  • Medical expenses
  • Lost wages / income losses
  • Property damage (if applicable to your model)
  • Other provable out-of-pocket losses

Step 3: Standardize the date fields

Pick one date approach per category and apply it consistently:

  • Use the same “start date” basis across comparable categories
  • Use the same “end date” basis across comparable categories
  • Ensure each amount is tied to a coherent date range

Examples of consistency (illustrative):

  • Lost wages: use pay-period dates tied to each wage amount
  • Medical: use invoice/service dates tied to each bill amount

Step 4: Run a double-counting scan

Before generating totals, check whether any source appears twice:

  • Review whether “net” amounts were already calculated in supporting documents
  • Confirm whether reimbursements/credits were netted correctly (not both reduced and added again)

A fast method: list each bill/invoice/pay-period reference once and verify it maps to only one place in your inputs.

Step 5: Translate inputs into output changes (debugging)

Use controlled changes so you can see what the tool is doing and why.

Input you change in DocketMathTypical output changeWhat it signals
SOL gate / timeliness cutoffTotals decrease for categories outside the windowDate anchoring or cutoff logic needs review
Category breakdown (split lump sum)Allocation becomes more granularBetter explainability; easier adjustments
Category date rangesAffected category subtotal changesAccrual/date inconsistency
Netting reimbursementsTotals may drop in medical/out-of-pocket categoriesDouble-counting or missing credits

Step 6: Keep a one-page “allocation rationale”

You don’t need a long narrative, but you should be able to answer:

  • What SOL gate did you use? (2 years, N.M. Stat. Ann. § 31-1-8)
  • What date rule defined inclusion vs. exclusion?
  • Which categories were adjusted, and why?

This turns a spreadsheet into an auditable model—without guessing.

Related reading