Spreadsheet checks before running statute of limitations in Australia

What the checker catches

Run this scenario in DocketMath using the Statute Of Limitations calculator.

Running statute of limitations logic from a spreadsheet is where small data issues create big timeline mistakes. DocketMath’s statute-of-limitations tool helps you sanity-check the inputs before you trust the output.

A solid spreadsheet check typically catches problems in four areas:

1. Date integrity

   • Invalid dates (e.g., “31/11/2022”)
   • Mixed formats (e.g., DD/MM/YYYY stored as text in one column, parsed as dates in another)
   • Time components accidentally included (e.g., 2023-04-01 00:00:00 vs 2023-04-01)—usually harmless, but it can break “day-level” logic

2. **Field alignment (the #1 spreadsheet error)

   • Claim date in the wrong column
   • Service date vs event date swapped
   • Limitation trigger date calculated from the wrong source column
   • Off-by-one shifting caused by formulas referencing the wrong row range

3. Assumption gaps

   • Missing columns for the trigger concept your workflow uses (for many Australian limitation calculations, the relevant “starting point” depends on the facts you model—your spreadsheet must represent that explicitly)
   • Default values hard-coded in formulas (e.g., assuming a start date when a “discovery” date is blank)
   • Hidden IFERROR() / empty-string outputs that mask bad rows

4. Output plausibility

   • Expiry date earlier than the event/claim date (a classic sign the inputs are reversed or the formula is using the wrong sign)
   • Expiry date far in the future for a claim type you know should be near-term
   • “Blank” outputs where you expected a date—often caused by conditional logic that stops the calculation when one intermediate column is missing

To make this actionable, treat your spreadsheet as two layers:

• Raw facts layer: event date, notice date, service date, discovery date (whatever your process captures)
• Computed timeline layer: trigger date, limitation expiry date, and any “days remaining” you track

The checker validates the transition between those layers—especially that the computed trigger date is derived from the correct raw field, and that the expiry date moves as expected when the trigger inputs change.

When to run it

Use DocketMath as a pre-flight check at the moment you’re about to rely on the spreadsheet for deadline work—not weeks later after mistakes have compounded.

Here are high-confidence “run it now” points:

• Before the first batch calculation

  • Run the checker after you import data or paste columns.
  • Confirm that all date fields are actually date-typed, not text.

• After any formula change

  • If you update a formula (for example, the trigger date logic), rerun the checker on a small sample immediately.
  • Don’t assume old validations still apply—date parsing and conditional logic can shift silently.

• After data merges

  • When you join rows from multiple sources, check for:

    • duplicates
    • mismatched timezones
    • missing date columns in certain subsets

• Before exporting a “ready to use” report

  • If your report is shared internally, run the checker on the final report-driving sheet (not just a draft tab).

A good workflow is to run the checker in two passes:

1. **Structural pass (fast)

   • Identify malformed dates
   • Identify columns with blanks where you expect dates
   • Identify inverted or inconsistent date ranges

2. **Reasonableness pass (focused)

   • Pick 10–20 representative records:

     • earliest dates
     • latest dates
     • records with discovery/notice dates filled
     • records with discovery/notice dates blank
   • Compare spreadsheet outputs with the tool’s calculations

Checklist you can apply each run:

Try the checker

Start with a single-record sanity test before you move to bulk rows.

1. Open DocketMath’s statute of limitations workflow here:
   /tools/statute-of-limitations

2. Choose a test case designed to stress the most common failure modes:

   • A record where the event date and notice/discovery dates are close (e.g., within 14–30 days)
   • A record where notice/discovery is much later than the event date (to validate your trigger logic)
   • A record that has a missing discovery/notice field (to validate your defaults and conditions)

3. Mirror the same inputs used in your spreadsheet:

   • If your spreadsheet uses “event date” as day 0, ensure the tool’s event/trigger inputs match that meaning.
   • If your spreadsheet uses “trigger date” directly, ensure the tool setup reflects the same trigger concept.

4. Validate outputs using relative checks, not only absolute dates:

   • Does the expiry date move forward when the trigger date moves forward?
   • If you increase the “days to expiry” input (or change an anchor date), does the model respond in the expected direction?

5. Only after the single-record checks pass should you run a batch validation:

   • Export a small batch (e.g., 20 rows) and rerun the checker after each spreadsheet modification.

If you’re building this into a repeatable process, add an “audit trail” inside your spreadsheet:

• Store raw input dates in dedicated columns
• Store computed trigger dates in separate columns
• Store the final expiry date in the final column
• Avoid embedding trigger logic directly inside the expiry-date formula without an intermediate column you can inspect

For quick cross-checking, you can also add helper columns:

• days_between_event_and_trigger
• days_between_trigger_and_expiry
• is_expiry_before_trigger (boolean)
• has_missing_required_dates (boolean)

Then verify:

When you find a mismatch, treat it as a data mapping problem first:

• Did the spreadsheet label “claim date” actually mean “service date”?
• Did the import swap day/month order?
• Did a formula reference shift when rows were added?

Once those are corrected, rerun the tool on the same test cases. If you want the tool to be the last gate before deadlines, structure your workflow as: compute in spreadsheet → check with DocketMath → export/report/act.

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