Spreadsheet checks before running Closing Cost in Tennessee

What the checker catches

Before you run a Closing Cost calculation in Tennessee with DocketMath (jurisdiction US-TN), a “spreadsheet checks” pass helps you prevent common, high-impact spreadsheet issues—especially ones that distort the timing logic that sits alongside Tennessee’s general statute of limitations (SOL) rule.

The checklist below is what the checker is designed to catch, along with the Tennessee rule it anchors to.

1) Mis-set SOL timing assumptions (Tennessee default rule)

In DocketMath’s closing-cost workflow, parts of the calculation can depend on whether an event is treated as occurring “within” or “outside” a relevant limitation window.

For Tennessee, the provided jurisdiction data sets the General SOL Period to 1 year, tied to:

• Tennessee Code Annotated § 40-35-111(e)(2): General/default SOL period

Important: the briefing notes state that no claim-type-specific sub-rule was found in the provided jurisdiction data. That means the checker uses the general/default period as the governing window—1 year—unless you update the underlying model for a claim-type-specific analysis.

2) Date fields entered as text (or in inconsistent formats)

Spreadsheet bugs often come from date parsing. The checker looks for patterns that commonly break “within 1 year” logic:

• A date like 01/15/2026 entered as text won’t compare correctly to computed dates.
• Mixed formats (for example, 2026-01-15 next to 1/15/26) can lead to silent mis-sorting and incorrect “difference” calculations.
• “Start date after end date” patterns that indicate reversed inputs or copy/paste mistakes.

The checker flags:

• Non-date values in date columns
• Columns that look like dates but behave like text
• Start/end ordering issues that produce negative or nonsensical time windows

3) Off-by-one errors around “within 1 year”

A 1-year window is sensitive to how the spreadsheet calculates it. The checker focuses on consistency in date math, since these are typical failure modes:

• Using YEAR(end)-YEAR(start) (year subtraction ignores months/days)
• Including or excluding the boundary day inconsistently
• Relying on locale-dependent parsing that interprets the same date string differently

To keep results stable, the checker normalizes the approach so the timing determination doesn’t swing just because a user pasted dates from different systems.

4) Incorrect numeric inputs that change the closing-cost output

Even if your SOL/timing branch is correct, bad inputs can still skew totals. The checker validates common “looks numeric but isn’t” problems:

• Numeric columns for fees/costs/multipliers:

  • no unexpected blanks where numbers are required
  • no accidental text entries like "1,200" instead of 1200 (or currency symbols embedded in the value)
• Percent fields scale mismatches:

  • e.g., 8.5 vs 0.085
  • the checker looks for signs that a percent has been entered in the wrong scale
• Currency formatting issues:

  • stray symbols (like $) in numeric cells that cause the spreadsheet to treat them as text

5) Copy/paste mismatches across tabs and broken references

Operational issues often come from workbook structure:

• Broken references after renaming a tab or moving columns
• Formula cells that no longer line up with the expected column headings
• Duplicate rows that appear to be recalculated twice after copying/pasting sections

The checker flags broken links and mismatches so your Closing Cost output reflects the intended row/record and inputs—not a shifted neighborhood of cells.

When to run it

Run DocketMath spreadsheet checks before you compute Closing Cost in Tennessee (not after), because correcting inconsistencies post-calculation is slower and can produce a workbook that looks “mostly right” while the timing logic is wrong.

Use this timing checklist:

In TN workflows tied to Tenn. Code Ann. § 40-35-111(e)(2), the “1 year” general/default timing window is central. That makes input correctness—especially date parsing—non-negotiable.

Warning (gentle): If you correct totals after running without checks, you can end up with internally inconsistent outputs (right currency numbers paired with wrong timeliness determinations). The checker is meant to prevent that mismatch.

Try the checker

To try this workflow with DocketMath:

1. Open the tool: ** /tools/closing-cost
2. Confirm the jurisdiction context is US-TN.
3. Upload or review your spreadsheet inputs.
4. Run the spreadsheet checker step before the main Closing Cost calculation.

Focus the checker review on:

• Date columns: verify they parse as real dates (not text).
• The “within 1 year” logic: confirm it aligns with the general/default 1-year SOL from Tenn. Code Ann. § 40-35-111(e)(2) (per the provided rule set).
• Numeric fields: validate formatting (no text currency, no percent scale mismatch, no hidden blanks).

Input → Output: how changes affect results

A practical way to think about the checker is: it improves the correctness of the inputs that drive the timing branch and the arithmetic totals. Here’s what typically changes when a checker finds issues:

After the checker passes, proceed to run the Closing Cost calculation and review outputs that may depend on timing determinations tied to the 1-year general/default SOL.

Gentle disclaimer: This is a spreadsheet-quality workflow using the provided general/default SOL period. It’s not legal advice and may not cover a claim-type-specific limitations analysis if one applies to your situation.

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