Spreadsheet checks before running Closing Cost in New Hampshire
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Closing Cost calculator.
Running a Closing Cost calculator in New Hampshire is easiest when your spreadsheet is already “SOL-ready.” DocketMath’s Closing Cost tool can compute totals, but the spreadsheet checks before running it help you avoid a common failure mode: using the right numbers with the wrong legal timeline—so results may be misleading if the claim could be time-barred.
For New Hampshire, this checker is built around the general limitations period for civil actions: 3 years under RSA 508:4. Importantly, no claim-type-specific sub-rule was found for this workflow, so the checker uses the general/default 3-year period as the baseline. (If your scenario involves a different accrual trigger or a claim type with a specialized rule, you’ll want to adjust your spreadsheet logic accordingly.)
Below are the specific spreadsheet issues the checker is designed to flag before you trust any calculated totals.
Common spreadsheet problems the checker catches
Wrong date field
- Example: using “date received” instead of the date of accrual/occurrence that your SOL logic depends on.
- A shift of even 60–200 days can change whether a 3-year window is crossed.
Mixed time zones or inconsistent date formats
- Spreadsheets can behave differently with
MM/DD/YYYYvsDD/MM/YYYY, especially after copying/pasting from emails or PDFs. - The checker looks for signs of inconsistent date parsing so you don’t silently get incorrect elapsed time.
Silent blank cells that default to zero
- If a “notice date” or “event date” cell is blank, formulas can effectively compute the wrong elapsed period—often producing totals that look plausible while being wrong.
Using payment/transaction dates instead of legal timeline dates
- For the New Hampshire general SOL analysis under RSA 508:4, the worksheet should align to the legal timeline your logic is intended to measure—not the timeline of later payments.
Inconsistent “as-of” date across tabs
- One sheet might use
TODAY()while another uses a fixed date, which can produce conflicting elapsed-time answers for the same matter. - The checker checks for internal coherence so scenario comparisons don’t rely on mismatched time assumptions.
Misapplied limitations period
- The checker verifies you’re using the 3-year default period in the worksheet rules and not accidentally swapping in another timeframe (e.g., 2 years, 4 years, or a custom value not supported by your template’s RSA 508:4 baseline).
Note: This workflow uses New Hampshire’s general 3-year limitations period under RSA 508:4. Since no claim-type-specific sub-rule was found here, the general/default period is the baseline the checker enforces.
Quick reference: the SOL backbone used by the checker (US-NH)
| Item | Value used in the checker |
|---|---|
| Jurisdiction | New Hampshire (US-NH) |
| General civil SOL period | 3 years |
| Governing statute | RSA 508:4 |
| Rule basis | General/default period (no claim-type-specific sub-rule found for this workflow) |
When to run it
Run the checker before you run DocketMath’s Closing Cost calculations—especially before you finalize scenario selections. Doing checks after calculations can leave you with numbers that were generated from an internally inconsistent timeline.
Run the checker before importing a spreadsheet into the Closing Cost workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
Best times to run the checker
Before the first “scenario” tab is finalized
- Once the core dates are entered (event/accrual, relevant filing/commencement date, notice date if applicable to your timeline logic, and the “as-of” date), run the checker right away.
After you import or paste data
- Copying data from emails, PDFs, or other spreadsheets often introduces date parsing issues (format swaps, blank values, or date-as-text problems).
Before generating outputs for review
- If you’re preparing an internal or client-facing summary, validate the timeline first so the worksheet’s totals aren’t undermined by a SOL alignment issue.
Whenever you change “as-of” logic
- Switching from a fixed date to
TODAY()(or vice versa) can change whether a 3-year window is considered crossed.
What to check in your spreadsheet (inputs)
Use a simple checklist—these are the inputs that drive SOL alignment in your worksheet logic:
Try the checker
You can use DocketMath to run a fast, jurisdiction-aware spreadsheet sanity check as part of your workflow.
- Open DocketMath’s Closing Cost tool:
/tools/closing-cost - Start with your spreadsheet’s core dates first—the dates that determine your SOL timeline logic.
- Run the spreadsheet checks to confirm:
- Your date arithmetic is consistent
- Your period default is set to 3 years under RSA 508:4
- No worksheet cells create silent miscalculations (blank-to-zero effects, mismatched date sources, etc.)
- Only after the checker passes should you finalize and lock in your Closing Cost outputs.
Gentle reminder: This is workflow guidance, not legal advice. SOL questions can be fact-specific, and you should review the underlying assumptions used in your spreadsheet.
How outputs change when checks fail
When the checker detects a date or logic problem, it typically affects results in these ways:
Time-barred eligibility changes
- A “time-barred” outcome can appear (or disappear) once elapsed time correctly reflects the intended timeline.
Scenario comparisons shift
- If the “as-of” timeline moves, amounts used in scenario logic (e.g., “current amount” vs. earlier comparisons) may change.
Elapsed time changes due to corrected parsing
- Fixing a date format issue (or identifying a mismatched date source) changes elapsed days/months and can push an analysis across the 3-year boundary.
Warning: If your spreadsheet uses inconsistent “as-of” dates across tabs, you can end up with two different elapsed-time answers for the same matter. That inconsistency can cascade into which scenario you choose—despite the underlying numeric inputs appearing correct at a glance.
Related step: verify the SOL anchor in your worksheet rules
Because this workflow uses the general/default New Hampshire SOL period under RSA 508:4, your spreadsheet rules should explicitly reflect:
- Period: 3 years
- Statutory anchor: RSA 508:4
- No special sub-rule assumed: since no claim-type-specific sub-rule was found for this template/workflow, the general rule is the baseline.
New Hampshire general civil SOL reference (as cited for the general rule):
https://www.thelaw.com/law/new-hampshire-statute-of-limitations-civil-actions.391/?utm_source=openai
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
