Why Closing Cost results differ in New Hampshire
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
If you’re using DocketMath’s Closing Cost calculator for New Hampshire (US-NH), you may see results that don’t match what you expected from another run, spreadsheet, or lender disclosure. In most cases, the differences come down to inputs and timing rules, not a “mystery math” problem.
Below are the top 5 reasons your Closing Cost results can diverge in New Hampshire.
**Different payment dates (timing affects totals) Closing cost computations can depend on when costs are applied relative to the deal timeline. For example, if one workflow assumes settlement on a specific date (e.g., “2026-04-15”) and another assumes a different date, proration windows and any interest/timing-based components can shift—changing totals even if the underlying fees are the same.
Loan terms entered differently Even small changes to loan assumptions can ripple through escrow-related estimates and fee allocations. Common mismatches include:
- Loan term length (e.g., 30 years vs. 15 years)
- Interest rate vs. other rate-like inputs (APR-like vs. interest rate)
- Amortization assumptions (if your workflow supports variations)
If two runs don’t match on these loan parameters, closing cost outputs may not reconcile.
- Taxes and insurance treatment not aligned New Hampshire results can differ when the inputs assume different tax/insurance bases, such as:
- Property tax rate or tax year
- Insurance estimate amount and coverage assumptions
- Whether totals are treated as annualized values that get prorated vs. directly entered as per-close amounts
If one run is effectively “annual then prorate” and another is “direct per-close,” the outputs will naturally diverge.
- Fees classified or applied differently Two runs can produce different totals even if the headline fee numbers look similar, because tools may treat fees differently:
- Paid at closing vs. paid after closing
- Up-front charges added once
- Amounts that get rolled into financed totals (or treated as separate line items)
The key is fee classification and application timing, not just the overall amount.
- Statute-of-limitations assumptions that affect “allowed recovery” logic Some analyses or output modules may include logic that depends on time horizons (for example, when estimating what is potentially recoverable within a window). For New Hampshire, the general/default statute of limitations for civil actions is 3 years under RSA 508:4.
Important clarity: No claim-type-specific sub-rule was found in the provided jurisdiction data. So the calculator should apply the general 3-year period as the default horizon. If a comparison workflow assumes a different horizon, results can differ even when closing inputs match.
Gentle note: This is not legal advice; it’s a practical reminder that time-window assumptions can change outputs.
How to isolate the variable
To pinpoint what’s driving the differences, use a diagnostic approach: freeze everything except one input at a time. The goal is to find the smallest change that produces a measurable output shift.
- Freeze the jurisdiction and tool settings so both runs use the same rule set.
- Compare one input at a time (dates, rates, amounts) and re-run after each change.
- Review the breakdown to see which segment or assumption drives the difference.
Step-by-step isolation method
Run once using the exact settlement/closing date. Re-run with only that date changed. Confirm: principal, interest rate, term length, and any extra payment/amortization assumptions. Use the same tax amount basis (annual vs. prorated) and the same effective rate/time basis if applicable. Confirm whether insurance is entered as annual coverage cost (then prorated) or as a monthly/per-close basis. Make sure each fee is categorized the same way across runs (for example, whether it’s treated as up-front vs. financed/escrowed). If your comparison includes any “allowed recovery” timing logic, confirm the tool is using RSA 508:4’s general 3-year default (since no claim-type-specific override was provided).
Quick “diff” table you can use
| Input category | What to compare | Typical symptom when mismatched |
|---|---|---|
| Dates | Settlement date / proration window | Totals shift even when fees match |
| Loan terms | Rate, term, amortization | Monthly-affecting items drift |
| Taxes | Annual rate vs prorated estimate | Escrow/tax line items disagree |
| Insurance | Annual vs monthly basis | Insurance line items disagree |
| Fees | Up-front vs financed classification | Closing-day total won’t reconcile |
| Time horizon | 3-year default vs other assumption | Output differs despite identical costs |
For a direct comparison run, you can use DocketMath Closing Cost here: /tools/closing-cost .
Next steps
After you identify the mismatching variable, you can make your results consistent:
- Re-run using a single source of truth
- Use the exact same settlement/closing date and proration method across comparisons.
- Normalize fee treatment
- Ensure each fee appears under the same category each time (up-front vs financed vs escrow-related).
- Cross-check NH limitations logic if recovery timing is involved
- Confirm the calculator uses RSA 508:4 and the general 3-year default (since no claim-type-specific period was provided in the jurisdiction data).
- Save the final “winning” input set
- Keep a copy of the exact inputs that produce the result you trust, so future runs don’t drift.
If you want, you can compare multiple scenarios—just keep the variables standardized and change only one thing per run.
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
