What the checker catches

When people run a Canadian statute of limitations calculation inside a spreadsheet, the math is often fine—until a single spreadsheet issue changes the result. DocketMath’s statute-of-limitations checker is designed to catch the boring but high-impact problems that quietly distort deadlines, including:

1) Date parsing and format drift

Common failure modes:

• Dates stored as text (e.g., "2026-01-05" imported as a string)
• Ambiguous dates (e.g., 01/02/2026 interpreted as January 2 vs. February 1)
• Mixed formats across rows

Symptoms in outputs

• Deadlines shift by months (or become blank)
• “Calculated” days show as 0 or #VALUE!

2) Time zone / time-of-day spillover

If you store timestamps (e.g., 2026-01-05 23:30) and treat them like whole dates, the effective start date can shift depending on how the system floors/rounds the value.

Symptoms in outputs

• Off-by-one-day errors in later comparisons

3) Off-by-one logic around “calendar days”

A typical limitations computation uses calendar years (often expressed as “after a certain event”) and then derives the deadline date. If your spreadsheet uses a day-count approach (or rounds differently), the final date can differ.

Symptoms in outputs

• Deadlines that consistently run late or early by a day or two across many rows

4) Wrong “start event” column wired into the formula

Spreadsheets often have multiple candidate columns:

• incident date
• notice date
• discovery date
• publication date
• filing date

A single reference error—pointing the calculator at “notice date” instead of “discovery date”—is enough to invalidate the entire table.

Symptoms in outputs

• Deadlines systematically earlier/later than expected

5) Unit errors: years vs. days

For limitations rules expressed in years, switching to a days-based approximation (e.g., 365 × years) can break around leap years.

Symptoms in outputs

• Patterns around leap years (notably when spanning February 29)

6) Blank/null handling mistakes

If some rows have missing values (e.g., blank discovery date), spreadsheet logic can:

• treat blank as 0
• default to a base date
• propagate errors to downstream cells

Symptoms in outputs

• “Valid” looking deadlines on rows with incomplete inputs

Pitfall (and why a checker matters): The most dangerous spreadsheet bug is one that doesn’t produce an error—just a plausible wrong date. The checker helps you surface these silent failures before you rely on the output.

7) Sorting/filtering that breaks row-level alignment

If you sort some columns but not all, date inputs and outcomes no longer correspond row-by-row.

Symptoms in outputs

• Identical deadlines applied to different records
• Outputs that don’t “match” the inputs you see on the same row

When to run it

Use the checker at the moment you’re about to trust the spreadsheet, not after you’ve exported or shared results.

Recommended checkpoints (practical workflow)

• Before you run the statute-of-limitations calculator
  Validate that date columns are real dates, not text, and that each record has required start-event inputs.
• Immediately after formula refactors
  If you copy/paste formulas, rename columns, or change table structure, re-run the checker.
• After you import new data batches
  Data imports frequently change date formats. Run the checker right after import.
• Before you produce any “final” deadline list
  Especially when deadlines feed reporting, dashboards, or client-facing summaries.

A simple “green check” approach

If your table includes:

• a Start date column
• an Event type or mapping to which start date applies
• a computed Limitations deadline column

…then the checker should confirm:

• start dates are parseable
• outputs are consistent (no systematic drift)
• blanks produce expected empty/flagged results, not fabricated deadlines

Gentle disclaimer: DocketMath’s checker is a spreadsheet QA step (“pre-flight checks”). It doesn’t replace reviewing the underlying legal rule you’re applying.

Try the checker

You can test drive the workflow here:

• Primary CTA: DocketMath – statute-of-limitations

If you want to verify assumptions about your spreadsheet math, run a quick pass with /tools/statute-of-limitations before you lock in dates.

How to structure your sheet for best results

If you’re building a checker-friendly version of your sheet, aim for the following input structure (names can vary, but the logic should be consistent):

Spreadsheet inputs to standardize

Use one row per record. For each record:

• start_date (the event date you’re using to begin the limitations period)
• start_event_type (optional but helpful—useful when multiple event columns exist)
• years_to_add (or your derived limitations period in years, if you’re parameterizing)
• computed_deadline (the output date you’ll compare against)

What outputs should change when issues are fixed

When you correct the issues the checker targets, you should see changes like:

• ✅ Text dates become real date values → deadlines populate instead of erroring
• ✅ Correct start column is wired → deadlines move to align with the correct event row
• ✅ Leap-year safe logic → deadlines remain stable across Feb 29 spans
• ✅ Blank handling is fixed → missing inputs result in blanks/flags instead of misleading deadlines

Quick spot-check table (recommended)

Before running the full sheet, consider a small test set in your workbook:

Checklist before you run

Use these checkboxes while preparing:

Related reading

• Browse the blog

What the checker catches

• Date ordering problems (end date before start date).
• Rates entered as whole numbers instead of percentages.
• Missing caps or discounts in the spreadsheet.
• Inconsistent rounding or day-count conventions.

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

When to run it

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

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Try the checker

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

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

Related reading

• Choosing the right statute of limitations tool for Vermont — How to choose the right calculator
• Statute of limitations in Singapore: how to estimate the deadline — Full how-to guide with jurisdiction-specific rules
• Choosing the right statute of limitations tool for Connecticut — How to choose the right calculator