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.

  1. **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.

  2. 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.

  1. 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.

  1. 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.

  1. 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 categoryWhat to compareTypical symptom when mismatched
DatesSettlement date / proration windowTotals shift even when fees match
Loan termsRate, term, amortizationMonthly-affecting items drift
TaxesAnnual rate vs prorated estimateEscrow/tax line items disagree
InsuranceAnnual vs monthly basisInsurance line items disagree
FeesUp-front vs financed classificationClosing-day total won’t reconcile
Time horizon3-year default vs other assumptionOutput 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:

  1. Re-run using a single source of truth
  • Use the exact same settlement/closing date and proration method across comparisons.
  1. Normalize fee treatment
  • Ensure each fee appears under the same category each time (up-front vs financed vs escrow-related).
  1. 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).
  1. 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