Spreadsheet checks before running statute of limitations in Singapore

What the checker catches

When you calculate a statute of limitations (or any limitation window) in a spreadsheet, the biggest risks are rarely “math”—they’re structure errors: wrong dates, wrong time units, incorrect offsets, silent blank fields, and mismatched assumptions. DocketMath’s statute-of-limitations spreadsheet checker is designed to flag these failure modes before you trust outputs.

Use it as a pre-flight checklist for Singapore-related limitation calculations. The goal is to catch issues that would otherwise produce confidently wrong “deadline” dates.

Here’s what to look for—common spreadsheet issues the checker can help you validate:

• Date coercion problems

  • Date fields stored as text (e.g., 01/02/2024 read as a string).
  • Mixed formats across rows (US-style vs day-month-year).
  • Hidden time components (e.g., timestamps) that shift end-of-day logic.
• Off-by-one logic errors

  • Using DATEDIFF() (or equivalent) without confirming whether the intended rule includes or excludes the start date.
  • Adding “N days” where your rule expects “N years” (or vice versa).
• Unit mismatches

  • Converting between days, months, and years inconsistently.
  • Applying leap-year behavior incorrectly when converting “years” to “days.”
• Blank or null propagation

  • A single missing “cause/start” date causing the computed deadline to become blank—or, worse, falling back to a default/previous value.
• Wrong column mapping

  • Accidentally pointing the checker (or your formulas) to the wrong “event” date column (e.g., using filing date instead of accrual/cause date).
  • Swapping “start” and “end” inputs in helper columns.
• Duplicate record rows

  • The same case/reference repeated, creating false consistency (multiple deadlines that look plausible but are based on duplicated inputs).
• Unexpected future/past values

  • Deadlines earlier than the cause/start date.
  • Deadlines far outside a plausible window for the scenario you’re modeling (often caused by unit errors or mis-parsed dates).

A practical way to use this: treat checker outputs as sanity constraints rather than final legal conclusions. Verify spreadsheet integrity first, then review the legal rule layer separately.

When to run it

Run the checker before you publish, export, or act on computed deadlines. You’ll get the most value by placing it at specific points in your workflow:

• Before the first calculation run

  • After you import case data (CSV export, copy/paste, or other feed into Excel/Sheets).
  • Immediately after you define date columns and map them to the calculator inputs.
• After any change to formulas

  • Example triggers:

    • Updating the “start” (event/cause/accrual) date definition.
    • Changing the offset logic (days vs years).
    • Altering helper columns used to compute the limitation window.
• Before generating deliverables

  • Before creating a case-status dashboard.
  • Before sending spreadsheets for review, litigation hold, or internal sign-off.
• After batch edits

  • When you normalize dates (e.g., convert all dd/mm/yyyy values to a canonical format).
  • After removing rows or merging datasets.

To make it operational, set a simple team rule:

• ✅ Run DocketMath’s statute-of-limitations checker
• ✅ Right after each data load or formula revision
• ✅ Again before exporting to PDF/Excel or sharing externally

Input discipline matters: if you want the checker to be meaningful, ensure your spreadsheet has a clear set of columns for:

• the start/event date used in the limitation calculation,
• the computed deadline date (or output field),
• and any secondary dates that shift the window (if your model uses them).

Try the checker

If you’re ready to validate your spreadsheet logic quickly, use the DocketMath tool:

• Primary CTA: /tools/statute-of-limitations

Before you paste or compute, do a quick checklist so the checker has what it needs:

Spreadsheet setup checklist (Singapore-focused workflow)

• Ensure your start/event date column contains real date values, not text.

  • Example: does your model use “event occurred,” “cause accrued,” or “first notice”?
  • Keep that definition consistent across rows.
  • Ensure each case has a populated start/event date.
  • Confirm the checker points to the correct column for the start/event date.
  • Decide what “deadline” means in your spreadsheet:

    • last permissible day,
    • end-of-day timestamp, or
    • a computed boundary date.

Output patterns to review

After running the checker, look for these outcome categories:

Finally, once your spreadsheet passes the sanity checks, you can proceed with deadline reporting—while still treating the calculation layer as a data-quality step, not a substitute for rule interpretation.

Related reading

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