Spreadsheet checks before running Closing Cost in West Virginia

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Before you run Closing Cost in West Virginia with DocketMath, a common failure mode is letting a spreadsheet “look right” while it’s legally misaligned. The Spreadsheet checker for US-WV focuses on preventing that mismatch by validating whether your inputs and timing assumptions are consistent with West Virginia’s general limitations period for the time-based parts of the workflow.

The jurisdiction rule the checker uses (West Virginia)

For this checker, the baseline limitation period is:

The checker uses the general/default period because no claim-type-specific sub-rule was found in the provided jurisdiction notes. In other words, the checker treats 1 year as the default limit across the spreadsheet workflow unless you explicitly adjust your dataset to account for a different rule.

Note: This checker is built around the general period under W. Va. Code §61-11-9 for the time-based parts of the workflow. If your scenario involves a different limitations framework, you should reflect that in your data before relying on the calculator output. This is a tooling aid, not legal advice.

Spreadsheet issues it can flag

When you run DocketMath → Spreadsheet checker → closing-cost for US-WV, it typically catches problems in three buckets:

  • Timing fields

    • Missing dates (e.g., “accrual,” “filing,” “event date”)
    • Dates in the wrong format (text vs. a true spreadsheet date)
    • Dates that produce negative or impossible durations (for example, an “event date” that ends up after the “filing date”)
  • Jurisdiction routing

    • Wrong jurisdiction code (for example, using a non-WV dataset)
    • Mixed-state rows inside a single run (this happens often when copying from multi-jurisdiction spreadsheets)
  • Input consistency

    • Blank fields feeding the closing-cost calculator
    • Totals that don’t reconcile (for example, line items that imply a total different from the sheet’s provided “total” field)

A quick way to think about it: even if the math in your sheet is correct, if the spreadsheet can’t reliably answer which date controls the default 1-year window under W. Va. Code §61-11-9, the Closing Cost outputs may be mathematically consistent but not grounded in your intended timeline.

What output looks like

After the Spreadsheet checker runs, your worksheet usually ends up in one of two states:

  • A clean/ready status if all required inputs are present and parseable
  • Otherwise, row-level warnings (so you can correct only the problematic records) and a run-block if the dataset is too unreliable to calculate confidently

When to run it

Run the spreadsheet checker before you start any Closing Cost calculations—and then run it again after edits that could affect dates or amounts. In practice, the timing matters because the 1-year general period under W. Va. Code §61-11-9 is sensitive to what the sheet thinks the relevant dates are.

Run it at these points

  • Immediately after importing or pasting data

    • Especially if you copied from PDFs, emails, or OCR exports where dates often land as text
  • Before you set or change “event” and “filing” dates

    • These fields drive whether your record aligns with the 1-year general SOL period from W. Va. Code §61-11-9
  • After deduping or filtering

    • Removing rows can break totals or leave blanks in fields that the calculator expects
  • Before exporting results for review

    • Catch issues while fixes are still easy, rather than after you’ve shared a “final” dataset

How the output changes with inputs

Because the checker is jurisdiction-aware for US-WV, your results can change depending on:

  • Date completeness and validity

    • If a key date field is blank or invalid, the checker can’t confidently determine whether the record fits within the default 1-year window tied to W. Va. Code §61-11-9
  • Consistency across rows

    • Mixed-jurisdiction rows can cause the wrong limitations logic to be applied downstream (or create uncertainty the checker can’t resolve)

If you’re running a “what if” (for example, shifting an event date by 10 days), rerun the checker after the edit—then rerun Closing Cost only once the checker reports readiness.

Warning: A spreadsheet can show a “reasonable” timeline while actually using the wrong date column (for example, using a “signed date” field when you intended “event date”). Date validation in the checker helps surface this earlier.

Try the checker

You can test this workflow directly in DocketMath using the jurisdiction-aware US-WV setup.

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

Capture the source for each input so another team member can verify the same result quickly.

Recommended test flow (quick)

  • Step 1: Open DocketMath and go to Closing Cost
  • Step 2: Run the Spreadsheet checker using calculator: closing-cost
  • Step 3: Confirm the checker is targeting **Jurisdiction: West Virginia (US-WV)
  • Step 4: Fix any flagged rows, focusing first on date parsing and missing fields
  • Step 5: Run Closing Cost only after the checker indicates your spreadsheet is ready

What to verify in your sheet before running

Use this checklist so the checker can operate cleanly:

When you’re ready to start, use the primary CTA to open Closing Cost:

Related reading