Spreadsheet checks before running Closing Cost in New Mexico

What the checker catches

Before you run a Closing Cost calculation in New Mexico with DocketMath, a spreadsheet can silently drift out of sync with the timing rules that govern whether a claim is timely. This “spreadsheet checker” is designed to catch the most common spreadsheet issues that can cause you to compute closing costs for a matter that is later challenged on statute of limitations grounds.

DocketMath’s closing-cost calculator may be jurisdiction-aware, but your spreadsheet still has to be consistent with the inputs that drive those calculations—especially dates.

Here’s what the checker is built to catch for US-NM under N.M. Stat. Ann. § 31-1-8:

• Missing or blank key dates

  • Examples: blank “accrual date,” blank “filing date,” blank “calculation cutoff date.”
• Inverted date order

  • Example: a “filing date” earlier than the “accrual date,” which can push the computed limitations window negative or misleading.
• Date typed as text

  • Common spreadsheet issue: dates stored like 01/15/2026 as plain text. Many formulas then treat them as strings, producing wrong comparisons.
• Wrong limitations period selected

  • For New Mexico, the default/general limitations period is 2 years under N.M. Stat. Ann. § 31-1-8.
  • No claim-type-specific sub-rule was found for this workflow—so the checker applies the general/default 2-year period and flags anything that suggests you used a different baseline.
• Multiple rows, one timeline assumption

  • Example: multiple transactions listed, but the spreadsheet uses the same accrual date for every row without confirming whether each row represents a separate event.
• Timezone/format inconsistencies

  • Example: some dates imported as YYYY-MM-DD while others are MM/DD/YYYY. Comparisons can fail or sort incorrectly.

To keep this practical, the checker doesn’t only validate dates—it also validates the logic that uses them. For example, it can:

• Verify that your “days in limitations window” (or equivalent) is computed from the same date fields across the sheet.
• Flag rows where the limitations window is “close,” so you can verify the exact date inputs before relying on results.
• Catch situations where the workbook is internally consistent for totals, but inconsistent for timing (a common source of “why does this analysis look off?” problems).

Gentle reminder: This is a spreadsheet QA workflow, not legal advice. If you’re making filing/timeliness decisions, confirm with qualified counsel or the relevant procedural record.

When to run it

Run the spreadsheet checker before you run DocketMath’s closing-cost calculator, not after. Closing cost totals can look correct even when the timing inputs are wrong, and those timing errors can change the conclusions you draw from the output.

A good cadence for US-NM is:

1. After you import or paste data

   • Especially when you bring dates from emails, PDFs, or a case management export.
2. Before you calculate or re-calculate totals

   • If you adjust any date fields, rerun the checker immediately.
3. Before sharing the workbook

   • When multiple people touch the sheet, date format drift becomes more likely.

Date fields the checker expects you to standardize

Use consistent column names and ensure the values are real spreadsheet dates (not text). Common patterns that work well:

• Accrual/Event Date (the date from which limitations would start)
• Filing Date (the date the case was filed)
• Calculation Cutoff Date (if your closing-cost model uses a cutoff)
• Optional: Hearing/Order Date(s) if your sheet tracks post-filing events separately

What “output change” looks like

When the checker finds an issue, it usually changes one of two things:

• It blocks the run of the closing-cost calculator until you fix date order/type problems, or
• It highlights which rows are unreliable, so you can correct them before totals are treated as dependable.

Even if your closing cost math is correct, a wrong date can distort the “timeliness” portion of your workflow—because the limitations baseline is tied to N.M. Stat. Ann. § 31-1-8 (2 years).

Try the checker

You can try the workflow by using DocketMath’s closing-cost tool here:

• /tools/closing-cost

Before you click into results, use this quick checklist:

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Mini example: how a date error can flip your timeline

Consider a sheet where:

• Accrual/Event Date: 2024-03-01
• Filing Date: 2026-03-01
• Limitations period: 2 years (default under § 31-1-8)

If your filing date is accidentally stored as text like 03/01/2026 (or imported in a way that changes the day/month interpretation), the computed days in the limitations window can change dramatically—potentially turning a “right at the edge” scenario into something that looks early or late.

That’s exactly the kind of failure the checker is designed to prevent: it keeps your date logic aligned with the 2-year baseline so your closing cost workflow isn’t operating on broken timelines.

Related reading

• Average closing costs in Alabama — Rule summary with authoritative citations
• Average closing costs in Alaska — Rule summary with authoritative citations
• Average closing costs in Arizona — Rule summary with authoritative citations