Spreadsheet checks before running deadlines in Australia

What the checker catches

Run this scenario in DocketMath using the Deadline calculator.

Before you “run deadlines” off a spreadsheet, you want confidence that the math and assumptions inside the sheet can’t silently sabotage you. DocketMath’s spreadsheet checks are built for that sanity-check moment—spotting the kinds of errors that cause wrong dates, wrong counts, or wrong business-day logic.

Common issues the checker is designed to catch:

• Hidden off-by-one day errors

  • Example: treating an “inclusive” instruction (count including day of event) as “exclusive” (exclude day of event), or vice versa.
  • These mistakes often show up only after a few date operations.

• Wrong date parsing or date formats

  • Excel/Sheets sometimes store dates as numbers. If one column is text (e.g., 01/02/2026), the checker can flag rows where the date is not actually a date value.
  • This prevents downstream calculations from producing plausible-but-wrong results.

• Mixed time-zone / datetime truncation problems

  • If your sheet stores timestamps, truncation to a date can shift the outcome—especially where a deadline algorithm treats “end of day” differently.
  • The checker checks for inconsistent handling between “event date” and “deadline date”.

• Business-day logic mismatches

  • Australian deadlines often depend on “business days” (for example, excluding weekends, and sometimes public holidays depending on your business rules).
  • A spreadsheet might exclude only Saturdays/Sundays, while your workflow expects holiday exclusions too. The checker highlights whether the logic is consistent with your settings.

• Inconsistent holiday assumptions

  • When holidays are pulled from a table or built-in calendar, mismatches can occur (different state calendars, missing substitute days, or stale datasets).
  • The checker looks for patterns that suggest holiday calendars aren’t applied uniformly.

• Copy/paste and range drift

  • In deadline pipelines, one formula might be correct in row 2 but copied incorrectly into row 57.
  • The checker scans for “formula shape” problems—rows whose calculations differ from the expected structure.

• **Unit errors (days vs weeks vs months)

  • Some sheets mix “N days”, “N weeks”, and “N months” logic in the same column.
  • The checker can flag fields where the unit used to compute the date doesn’t align with how the output column is labeled.

• Missing prerequisites

  • Deadlines often require upstream inputs: a service date, a filing date, or a starting event date.
  • If those cells are blank (or filtered out), spreadsheets sometimes return blank outputs or default values. The checker highlights incomplete rows so you don’t accidentally “approve” missing deadlines.

To make these checks useful, define two things in your sheet before you run the checker:

• The starting event date field (the date you count from)
• Your deadline rule inputs (e.g., “X business days” or “X calendar days”, plus any holiday handling)

Then run the checker and review the flagged rows.

When to run it

Treat deadline spreadsheet checks as a pre-flight step rather than an after-the-fact audit. In practice, the best time to run DocketMath’s checks depends on how often the sheet changes and how many people touch it.

Use this cadence:

• Before first use

  • Run the checker the moment you create or receive the spreadsheet template.
  • This catches formula drift and date parsing issues early.

• After any structural change

  • If you add columns, rename headers, switch from one date source to another, or update the holiday table, re-run the checker immediately.
  • Even small edits (like changing one column from text to date) can have cascading impacts.

• Every time you update date ranges

  • If your sheet processes multiple cases or periods, run checks before publishing or acting on results.
  • A small subset of rows can be affected by invalid inputs (e.g., one case missing a service date).

• After bulk copy/paste operations

  • Common workflow: copy a block of formulas, then paste to a new case range.
  • Run the checker after the paste to confirm the formula references are still correct.

If you’re mapping “event date → deadline date”, the checker’s output is most actionable when it includes:

• Which rows are affected
• What rule or input caused the inconsistency
• Whether the spreadsheet’s date parsing/logic differs from the expected structure

Gentle note: these checks help you catch spreadsheet problems; they’re not a substitute for reviewing the underlying deadline rule you’re applying.

Try the checker

You can try DocketMath’s deadline calculator and use it as a companion to your spreadsheet workflow. Start with the same date values your sheet uses, then compare results.

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

1) Identify the inputs you’ll test

Pick a small sample—ideally 5–10 rows that represent real-world variance, such as:

• Events on a weekend vs a weekday
• Events near the end of a month
• Cases with different holiday calendar coverage (if you track it)
• Rows where your sheet uses datetime stamps (not just dates)

2) Run the tool with the same parameters

Use DocketMath to compute the deadline for those cases, then compare:

• Does the deadline date match your spreadsheet output?
• Are differences consistent (e.g., always 1 day) or random?

  • Consistent differences usually indicate an off-by-one rule.
  • Random differences often indicate parsing or missing-input problems.

3) Use the checker to isolate the spreadsheet fault

When the checker flags rows, focus on the input quality first:

• Are event dates true date values (not text)?
• Are blank cells present in any prerequisite column?
• Do formulas reference the correct row fields?
• Is business-day logic consistent across all rows?

4) Interpret output changes

As a sanity check, observe how changes to one input affect outputs:

• Change the event date by +1 day

  • If the rule is “X calendar days”, the deadline should shift predictably by +1 day.
  • If the rule is “X business days”, the shift may vary if the new date lands near weekends/holidays.

• Change only the unit

  • A mismatch between “days” and “business days” should produce large differences, not small ones.

• Blank vs populated inputs

  • A deadline should not be silently produced when the starting event date is missing.

When you’re ready, run the checker here: /tools/deadline

Related reading

• Why deadlines results differ in Canada — Troubleshooting when results differ
• Worked example: deadlines in New York — Worked example with real statute citations
• Deadlines reference snapshot for New Hampshire — Rule summary with authoritative citations