Spreadsheet checks before running Closing Cost in South Dakota

What the checker catches

Run this scenario in DocketMath using the Closing Cost calculator.

Running a Closing Cost calculation in South Dakota without first checking your spreadsheet inputs is a common way to generate “confidently wrong” numbers. DocketMath’s closing-cost tool can help with the calculation, but this spreadsheet checker focuses on the issues that most often break results before the calculator runs—especially issues tied to South Dakota’s deadlines.

Below are the checks the tool performs (using South Dakota US-SD jurisdiction-aware rules).

1) Missing or mismatched date fields

Closing Cost workflows often rely on multiple date cells (for example: an event date, a filing date, and/or a service date). The checker verifies that:

• Date fields are present (not blank)
• Each date is parseable (not stored as text like 03/15/2026 (est.))
• The “start” date is earlier than the “end” date
• The date format is consistent across sheets (this frequently breaks after copy/paste)

Why this matters: SOL-based logic (and any downstream “within window”/“outside window” determination) can silently fail when dates are stored as text or when one date column lags behind the other.

2) SOL window logic tied to South Dakota’s general rule (default)

For South Dakota, this checker uses the general/default SOL period of 3 years, governed by:

• SDCL 22-14-1 (general SOL period) — 3 years

Important clarification: your brief notes that no claim-type-specific sub-rule was found. That means this checker should treat SDCL 22-14-1 as the general/default period, not a specialized one.

So the checker flags scenarios like:

• A “start date” more than 3 years before the relevant “end date”
• Spreadsheet formulas that accidentally treat years as months (or vice versa)
• Off-by-one effects caused by rounding (for example, using a “rounded year difference” instead of a true date subtraction)

3) Arithmetic and reference errors that distort totals

Even if dates are perfect, Closing Cost totals can still go wrong due to typical spreadsheet mistakes:

• Percent values entered as whole numbers instead of decimals
  (example: 3 instead of 0.03)
• Taxes or fees entered in the wrong unit (for example: dollars vs. cents)
• Cells referencing the wrong column (or the wrong jurisdiction tab)
• Mixed rounding—rounding intermediate lines but not final totals (or the reverse)

The checker performs structural validation to catch these patterns—especially around fee/charge lines that may be reused repeatedly in your closing-cost sheet.

4) Jurisdiction mismatches (South Dakota vs. another state)

Workbooks sometimes include multiple states’ assumptions. It’s easy to accidentally keep a South Dakota run (US-SD) but point parts of the spreadsheet to another jurisdiction’s settings.

This checker confirms the workbook is using:

• South Dakota jurisdiction code: US-SD
• The 3-year default SOL approach from SDCL 22-14-1 (general SOL)

This helps prevent “it ran, but it shouldn’t have” situations caused by reused templates.

When to run it

Run the checker early—before you trust any Closing Cost outputs. In an SD workflow, a practical pattern is to use it whenever you do anything that could affect SOL logic or the inputs behind totals.

Good times to run:

• Before the first calculation

  • After importing data or copy/pasting from another sheet
• After changing any date inputs

  • Example: you update the “event date” or “filing date”
• Before exporting results

  • Especially after you hide columns, restructure tabs, or move summary sections
• Whenever you reuse the template

  • Duplicating a sheet often drifts date formats and references without obvious symptoms

Rule of thumb:

• If you changed anything that feeds the SOL determination logic, re-run the checker.
• If you changed only fee/tax amounts, still run it once—reference mistakes often travel with template edits.

Try the checker

Use the US-SD (South Dakota) setup, then confirm the pre-flight checklist below before you run DocketMath’s closing-cost calculator.

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

Step-by-step spreadsheet inputs (what to confirm)

Before checking, make sure your sheet aligns with these expectations:

What changes when the checker passes vs. fails

When the checker passes, you should expect:

• Date-based feasibility checks consistent with the 3-year default SOL under SDCL 22-14-1
• Stable totals that aren’t distorted by percent/unit/reference issues
• Fewer “mystery mismatches” where summary totals don’t match line-item sums

When the checker flags something, the most common outcomes are:

• A SOL-related determination flips after date corrections (within window vs. outside window)
• Totals shift after percent/unit or rounding fixes
• A validation error points you to a broken reference (for example, a column shift)

If you want to run the tool right now, start here: /tools/closing-cost

Gentle disclaimer: this checker is designed to validate spreadsheet structure and inputs. It’s not legal advice, and it may not reflect claim-specific rules if a specialized SOL applies outside the general/default approach used here.

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