Spreadsheet checks before running Closing Cost in North Carolina

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Running a closing-cost calculation in North Carolina is faster (and more reliable) when you sanity-check your inputs first. The DocketMath Spreadsheet Checker is built to catch common “spreadsheet gotchas” that can make a closing-cost result wrong—before you run DocketMath’s Closing Cost calculator.

For North Carolina (US-NC), the checker typically flags problems in these areas:

  • Date logic problems

    • Missing settlement/closing date (or the field is left blank)
    • Dates entered in inconsistent formats (for example, MM/DD/YYYY in one tab and YYYY-MM-DD in another)
    • Using the wrong date field for the “start” vs “end” of a timeline (a classic cause of subtle proration/timing errors)
  • Jurisdiction mismatches

    • The spreadsheet is set to the wrong jurisdiction (for example, accidentally leaving it on a different state)
    • Inputs that assume North Carolina rules (taxes, timing logic, or eligibility-style date windows) while the sheet configuration corresponds to another jurisdiction
  • Numerical integrity issues

    • Interest rate entered as a whole number instead of a percent/decimal convention (e.g., 5 vs 0.05)
    • Fees entered as text (e.g., "$2,500") instead of true numbers
    • Rounding inconsistencies across tabs (one tab rounding early while another carries more precision)
  • Math dependencies

    • A downstream formula pointing to the wrong cell range
    • One tab updated while the “summary” tab still references older values
    • Copy/paste changes that break formulas or references without obvious visual errors
  • Compliance-adjacent checks tied to timing

    • If your spreadsheet includes timeline-related fields, the checker can highlight dates that appear outside the relevant timing window so you don’t attach amounts to an event that’s too old for the default rules used by this checker set.

A key North Carolina timing concept the checker uses (per the jurisdiction-aware rules in this workflow) is the general statute of limitations (SOL) period: 3 years. This is the default/general period. No claim-type-specific sub-rule was found for this rule set.

So, when your workbook includes an event date (or requires you to confirm the age of an event), the checker can flag entries that appear older than the 3-year general SOL period.

Gentle reminder (not legal advice): This timing check is meant to help you avoid spreadsheet timing mismatches. It doesn’t replace professional legal review, and it uses the general/default 3-year period described above.

When to run it

Use the checker in two moments: before you calculate and whenever you change inputs.

Best practice: run spreadsheet checks before you press “calculate,” then rerun them any time you modify fields that feed totals.

Use this checklist:

  • Confirm jurisdiction is set to US-NC

  • Verify closing/settlement date fields are populated

  • Ensure date formats are consistent across tabs

  • Confirm numeric fields are entered as numbers, not currency strings (for example, 2500 instead of "$2,500")

  • Loan amount

  • Interest rate

  • Fees and credits

  • Any date used for eligibility, proration windows, or timing assumptions

  • Re-run checks after copy/paste between tabs

  • Verify the summary tab formulas still reference the intended cells/ranges

How the North Carolina timing rule affects checks

If your spreadsheet includes dates tied to eligibility or timing, the checker applies the general 3-year SOL period as the default timing window. Practically, this helps you avoid scenarios where a workbook quietly includes outdated event dates—especially when those dates influence prorations or other timing-dependent logic.

Also note that North Carolina’s SAFE Child Act is frequently referenced in connection with supporting victims and survivors of sexual assault. In this checker workflow, the limitations timing rule is still treated as general SOL, not a claim-type-specific sub-rule.

For context on the SAFE Child Act and support resources, see:

Warning (spreadsheet reality check): A spreadsheet can “calculate fine” while still being wrong if inputs are stale, misdated, or stored as text. The checker is designed to fail fast on those issues so you don’t build results on fragile assumptions.

Try the checker

You can test the North Carolina spreadsheet checks right away using DocketMath’s closing-cost workflow.

Primary CTA: Run Closing Cost in DocketMath

Before you run anything, make sure your spreadsheet has the expected inputs ready:

  • Jurisdiction setting
    • Must be **North Carolina (US-NC)
  • Closing/settlement date
    • Must be present and consistently formatted
  • Loan and fee inputs
    • Loan amount, fees, and credits should be numeric values
  • Any timeline-related date fields
    • If your sheet includes an “event date,” the checker uses the general 3-year SOL period as a default timing rule (no claim-type-specific sub-rule was found in this rule set)

See how inputs change the checker’s output

Here’s a quick experiment: make one improvement at a time and re-run the checks. This is the fastest way to understand what the checker is protecting you from.

Change you make in the spreadsheetWhat the checker is likely to flagLikely impact on closing-cost output
Enter interest rate as 5 instead of 0.05Rate magnitude/percent formatting anomalyTotals may be dramatically too high or too low
Provide dates in mixed formatsDate parsing inconsistencyProration/timing-dependent math may shift
Leave jurisdiction on a different stateJurisdiction mismatchLogic/timing assumptions may not match NC
Store currency fields as textNumeric type mismatchTotals may become zero, missing, or concatenate incorrectly

Once the checks pass, run the Closing Cost calculation in DocketMath and compare your summary totals to your earlier run. If the checker found issues, you should see totals stabilize and formula behavior become more predictable.

Related reading