Spreadsheet checks before running Closing Cost in Kansas

5 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Closing Cost calculator.

Before you run a Kansas Closing Cost calculation in DocketMath, run a quick spreadsheet hygiene pass. The goal isn’t to validate your math—it’s to catch common data issues that can make downstream closing-cost figures wrong, even when the calculator is working correctly.

Kansas timing can be especially sensitive because this workflow uses a general/default statute of limitations (SOL) baseline, not a claim-type-specific rule you may have assumed. In other words, for this checker you should treat the general/default SOL as the rule of thumb, unless you separately verify the correct category.

Kansas SOL baseline (default for this checker):

General SOL period: 0.5 years
General statute: K.S.A. § 21-6701
Source: https://www.kslegislature.gov/li/s/statute/021_000_0000_chapter/021_067_0001_section/021_067_0001_k.pdf?utm_source=openai
Important note: No claim-type-specific sub-rule was found for this workflow. The 0.5-year general/default SOL is the baseline to use in this checker. If your situation involves a different specialized claim category, you’ll need a separate legal review to confirm whether a different SOL applies.

Here’s what the spreadsheet checker should catch before closing-cost math:

Date field issues
- Missing “event date” (for example: filing date, demand date, or whatever trigger date your sheet uses)
- Dates stored as text (e.g., 04/01/2026 saved like "04/01/2026"), which can break date math
- Format inconsistencies across columns (e.g., mixing US-style MM/DD/YYYY with ISO YYYY-MM-DD)
**SOL computation errors (baseline mismatch)
- Using a “years” input that conflicts with the Kansas default 0.5 years
- Off-by-one mistakes where a user expects a calendar interval (like “6 months”) but the sheet conversion doesn’t match the intended baseline
  
  In a spreadsheet, “0.5 years” may not equal “exactly 180 days,” especially if day-count conventions differ
Jurisdiction tagging mistakes
- Forgetting to set the configuration to **Kansas (US-KS)
- Pulling in cached or copied rule settings from a different state tab/template
Unit and rate mismatches
- Percentages entered as whole numbers when formulas expect decimals (e.g., 3 instead of 0.03)
- Fees entered in the wrong currency unit (e.g., dollars vs cents), which can cause totals to be wrong by large factors
- Duplicate line items from copied ranges
Rounding and sign problems
- Rounding too early (rounding line items before summing)
- Negative numbers for amounts that should be positive (or vice versa), especially where credits/offsets are represented

To keep outputs stable, set up your sheet so every number you send into DocketMath has a consistent meaning and unit (dates as true date values, rates in the expected format, money in a single unit convention).

Quick data audit checklist (spreadsheet-side)

When to run it

Run the Spreadsheet checks step in two moments: right before you calculate in DocketMath and right after you edit inputs.

Run the checker before importing a spreadsheet into the Closing Cost workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) Right before running Closing Cost in DocketMath

Use it as a “pre-flight” check whenever you:

Paste borrower/transaction data into the sheet
Change a date or event trigger
Switch tabs or use a different template file
Edit percentage rates, fee schedules, or rate tables

2) Immediately after you change inputs

If you adjust any of the following, rerun the checker:

Any date used for timing logic (even if your closing-cost figure doesn’t appear to depend on it directly)
Any fee/cost component feeding totals
Any jurisdiction selection (Kansas vs another state)

Why the Kansas 0.5-year SOL baseline matters here: many closing-cost workflows get bundled into broader eligibility/timing logic. If your sheet uses the wrong SOL baseline, you may end up with incorrect downstream assumptions—even if the closing-cost computation itself looks plausible.

Heads up / gentle disclaimer: Spreadsheet formulas can look “right” while silently misinterpreting dates or units. These issues often won’t throw errors; they just produce incorrect outputs. The checker is designed to reduce that risk.

Try the checker

You can use DocketMath to run the closing-cost workflow with jurisdiction-aware rules for Kansas (US-KS), but don’t skip the spreadsheet checks step.

Practical path:

Open your worksheet and verify required fields:
- Jurisdiction = US-KS
- Dates are true date values
- Percentages match the expected format (decimal vs whole)
- Currency units are consistent
Confirm your timing baseline uses the Kansas general/default SOL:
- K.S.A. § 21-6701
- 0.5 years as the baseline (general/default)
- Don’t assume a claim-type-specific exception rule unless you’ve verified the correct category
Run the Closing Cost calculation in DocketMath only after checks pass.

Start here: /tools/closing-cost

If you want to validate the workflow end-to-end, run the tool and compare your sheet’s intermediate values to what DocketMath expects. This is where you typically spot:

date parsing issues,
inconsistent units,
percentage format problems,
and SOL baseline mismatches.