Spreadsheet checks before running Closing Cost in Illinois

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

Before you run Closing Cost in DocketMath for an Illinois transaction, a spreadsheet “pre-flight” can prevent the most common data issues that distort output. This spreadsheet-checker focuses on errors that typically affect any closing-cost calculation workflow: the checker validates your assumptions against jurisdiction-aware rules for Illinois, including statute of limitations (SOL) timing.

Illinois SOL rule your spreadsheet should follow (default/general)

Illinois’s general SOL period for civil actions is 5 years under 720 ILCS 5/3-6. For this checker, no claim-type-specific sub-rule was identified, so the calculator should treat the SOL as the general rule rather than customizing for specific claim labels.

Source: https://ilga.gov/ftp/Public%20Acts/101/101-0130.htm?utm_source=openai

Note: The SOL timing here is the default/general rule. If your workflow involves a specific claim category with a different limitations period, confirm whether another Illinois provision applies before relying on calculator results.

The checker catches issues in three buckets

Date integrity problems
- Missing dates in key columns (e.g., filing date, event date, or “start of clock” date)
- Dates entered as text (a common spreadsheet issue)
- Inconsistent formats (e.g., 04/05/2024 vs 2024-04-05)
- “Start date after end date” anomalies
SOL logic mismatches
- Spreadsheets that subtract dates incorrectly (off-by-one-day errors)
- Rows where the calculated “age of claim” exceeds 5 years but the spreadsheet still treats the matter as timely
- Workflows that assume a different SOL than Illinois 720 ILCS 5/3-6
Column mapping and unit errors
- Using the wrong column for “incident date” vs “notice date” (or other similarly named fields)
- Mixing currency formats (e.g., “$12,500” strings instead of numeric cells)
- Rounding early (rounding line items before totals and then again on totals)

Quick diagnostic table (what to verify)

Spreadsheet element	What the checker looks for	Typical consequence
Event/start date cell	Non-empty, valid date type	SOL miscalculated
End/filing date cell	Non-empty, valid date type	Timeliness flips
Date difference formula	Correct ordering and units	Off-by-one or negative age
Mapping to DocketMath Closing Cost inputs	Correct column mapping	Wrong inputs → wrong outputs
Currency numeric cells	Numeric-only values	Totals that don’t match

When to run it

Run the Illinois spreadsheet checker right before you calculate Closing Cost in DocketMath, and also after specific kinds of edits.

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) Before the first calculation run

Use it immediately after you:

export or paste data into your spreadsheet, and
define or populate the date columns that will drive any SOL-related logic in your workflow.

This timing catches structural issues (missing/invalid dates, malformed currency, broken formulas) before the calculator produces outputs you later have to unwind.

2) After any data edits that touch dates or amounts

Re-run the checker after:

correcting a date field,
changing the “start of clock” logic,
updating line items (fees, credits, or payments),
merging data from another system.

Most spreadsheet bugs enter through edits. A quick re-check prevents inconsistent row-level behavior.

How to think about the Illinois timing logic in practice

Because this checker applies Illinois’s general/default SOL period of 5 years under 720 ILCS 5/3-6, it evaluates whether a row’s relevant dates fall within that 5-year window (using your spreadsheet’s start/end mapping).

If a row is outside 5 years, your spreadsheet should reflect that outcome consistently rather than allowing downstream calculations to proceed as if the matter were within limitations.

Try the checker

You can test the workflow end-to-end by starting with the Closing Cost calculator in DocketMath and using this checker approach to validate inputs first.

Start the tool: **Closing Cost in DocketMath

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

Suggested input preparation (Illinois-aware)

Before you click calculate, confirm the following in your spreadsheet:

What output changes when dates are wrong?

A practical example of why this matters:

If your start date accidentally shifts by 1–2 years (due to format confusion like MM/DD vs DD/MM), your computed “age” of the claim can cross the 5-year boundary under 720 ILCS 5/3-6.
That can cause a spreadsheet to label a row as “timely” when it should be outside the general limitations window—or vice versa.
Once that happens, any downstream step (including how you structure closing-cost scenarios) can become internally inconsistent.

Warning: This is a data-quality workflow aid, not legal advice. If you’re unsure how a specific claim category affects limitations, get guidance from a qualified professional before relying on results.

Run a fast “spot check” before bulk calculation

After the checker flags issues, use this minimal approach:

Pick 5 rows: earliest date, latest date, and three around the 5-year boundary.
Manually confirm the computed date difference using the same date cells the checker uses.
Re-run the checker after corrections, then run the calculator once.

This reduces wasted time and prevents bulk recalculation based on faulty mappings.

Jurisdiction confirmation (US-IL)

DocketMath’s jurisdiction-aware rules for this workflow should be set to Illinois (US-IL) so the 5-year general SOL under 720 ILCS 5/3-6 is applied as the default/general rule.