Spreadsheet checks before running Closing Cost in Maryland

What the checker catches

Before you run DocketMath’s Closing Cost calculator in Maryland (US-MD), use a spreadsheet pre-check to catch the issues that most often distort results—especially when timelines and filings are involved.

In Maryland, the default (“general”) statute of limitations (SOL) period is 3 years for many civil claims. The governing rule is:

• Md. Code, Cts. & Jud. Proc. § 5-106 (general/default SOL): 3 years
  Source: https://codes.findlaw.com/md/courts-and-judicial-proceedings/md-code-cts-and-jud-pro-sect-5-106/?utm_source=openai

Important: Your data did not identify any claim-type-specific SOL sub-rule, so you should treat 3 years as the general period and avoid adding specialized timing branches unless your spreadsheet is explicitly built for those special modules and is supported by the correct statute.

A practical spreadsheet checker for Closing Cost workflows should validate the assumptions that commonly feed into your timeline and expense calculations. In practice, it should catch:

• Missing or mis-typed dates

  • Examples of what to check:

    • Closing date is blank
    • Contract/signing date entered as text (e.g., 04/12/2026 stored as a string instead of a true date)
• Wrong “start date” logic for your spreadsheet

  • Your DocketMath run might be correct, but the spreadsheet could be using the wrong baseline date for any timing-based adjustments.
• SOL window calculation errors

  • If your spreadsheet derives “time since event” (for example: event date → filing date), verify it aligns to 3 years under Md. Code, Cts. & Jud. Proc. § 5-106 for the general/default period.
• Off-by-one day or time zone drift

  • A 1–2 day difference can flip a “within SOL / outside SOL” status when strict day counts are used.
• Spreadsheet unit mismatches

  • Example: interest rate entered as 6 instead of 0.06
  • Example: fees entered in cents vs. dollars
• Accidental overwrites

  • Copy/paste errors happen. A good checker should flag values that are unusually large/small or inconsistent with other fields.

Pitfall to watch: A Closing Cost number can look “right” while the downstream timeline logic is wrong. If the spreadsheet uses the wrong SOL baseline (or the wrong date field), the output may be mathematically consistent—but it may conflict with the 3-year general SOL referenced in Md. Code, Cts. & Jud. Proc. § 5-106.

Quick checklist (spreadsheet-level)

Use these checks as columns or validation rules:

When to run it

Run the spreadsheet checker twice: once before any modeling inputs are finalized, and again immediately before you commit to a Closing Cost calculation using /tools/closing-cost.

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.

Timing for the checker

• First run (intake stage):

  • As soon as you have the core facts (dates, loan amount, fee items).
  • Goal: prevent garbage-in/garbage-out.
• Second run (pre-calculation stage):

  • Just before you run DocketMath → Closing Cost.
  • Goal: confirm nothing changed silently after validation.

Jurisdiction-aware logic for Maryland (US-MD)

For Maryland, your checker should apply the general/default SOL of 3 years under Md. Code, Cts. & Jud. Proc. § 5-106.

Because no claim-type-specific sub-rule was identified in your inputs, your spreadsheet should not branch into a different SOL rule by default. Staying conservative and consistent with 3 years as the baseline helps keep timing flags aligned to § 5-106.

How outputs should change when the checker finds issues

If the checker is well-designed, it should control the workflow—not just warn:

• If a date is missing → block the /tools/closing-cost run (or mark outputs as “invalid inputs”)
• If the SOL duration logic doesn’t match the 3-year general window → flag the record and show the specific field that caused the mismatch
• If rate formatting looks off (e.g., 6 instead of 0.06) → either:

  • auto-convert only if your spreadsheet has safe unit rules, or
  • require manual review if units are ambiguous

A “gates” approach works well:

• ✅ Pass → allow /tools/closing-cost
• ⚠️ Soft warning (e.g., unusual fee magnitude) → allow run, but label results for review
• ❌ Hard failure (e.g., invalid date or missing loan amount) → prevent run until corrected

Try the checker

If you’re using DocketMath, here’s a practical workflow:

1. Validate inputs in your spreadsheet

   • Confirm all dates parse correctly
   • Confirm amounts/rates are in the expected units
   • Confirm the timeline math uses the 3-year general SOL tied to Md. Code, Cts. & Jud. Proc. § 5-106
2. Run the Closing Cost calculator

   • Use the same validated fields you just checked: ** /tools/closing-cost
3. Reconcile anomalies

   • If the DocketMath output is unusually high/low, treat it as a signal to re-check numeric fields first, then dates.

If you want to keep it simple, start by running the closing-cost tool after your spreadsheet passes a minimal set of validations:

Gentle note: This is a workflow check, not legal advice. SOL and timing outcomes can be fact-specific, so if your case involves unusual procedural history, consider verifying assumptions beyond spreadsheet flags.

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