Spreadsheet checks before running deadlines in Delaware

What the checker catches

Run this scenario in DocketMath using the Deadline calculator.

Running a Delaware deadline off a spreadsheet is fast—but it’s also where subtle errors hide: wrong date fields, off-by-one day logic, and formula drift after copying rows. DocketMath’s deadline checker is built to help you sanity-check the inputs and the computed due dates before you commit them to a filing calendar.

Common spreadsheet issues it can help you catch:

• Malformed dates

  • Excel/Sheets cells that look like dates but are actually text (e.g., 03/04/2026 stored as "03/04/2026").
  • Mixed formats (MM/DD/YYYY vs DD/MM/YYYY) that shift outcomes because the checker may interpret or fail to interpret the value consistently.

• Incorrect start (trigger) date

  • Accidentally using a “served” date when your sheet should use an “event/trigger” date (or vice versa).
  • Referencing the wrong column—e.g., pulling a filing date instead of the trigger date.

• Off-by-one day deadline logic

  • Some spreadsheets treat “2 years” as “730 days,” which can drift around leap years.
  • Counting the day of the triggering event as day 0 vs day 1 can also create systematic one-day shifts.
  • Delaware’s general limitations period (below) is measured in years, so day-count approximations can break.

• Silent formula breakage

  • Copied formulas that reference the wrong row.
  • Renamed headers/columns that leave formulas pointing to missing fields, resulting in #REF!, blank outputs, or values that look “empty” rather than obviously wrong.

• **Wrong rule applied (important default/benchmark note)

  • Delaware has a general/default limitations rule, and a spreadsheet can accidentally apply a different (claim-type-specific) period if you built it that way.
  • In this workflow, use the general SOL only as your benchmark, because no claim-type-specific sub-rule was found in the information provided. The goal here is to validate spreadsheet mechanics against a safe baseline, not to select the correct limitations period for every scenario.

The benchmark rule used in this workflow (Delaware general SOL)

Delaware’s general/default statute of limitations period is 2 years. The general authority for this default rule is Title 11, § 205(b)(3) (Delaware Code).
Source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai

Quick “sanity-check” output you’re aiming for

After running the checker, your computed “deadline date” should be consistent with these practical checks:

• The deadline lands on a plausible calendar date (not NaN, blank, or an obviously shifted year).
• The computed due date changes correctly when you edit the trigger/event date.
• Leap-year crossings don’t produce weird results—especially around years like 2024/2028.

When to run it

Treat spreadsheet checks as a pre-flight step—run them at moments when errors are most likely to be introduced.

A good schedule:

• Before you publish or share a spreadsheet

  • If you’re sending a workbook to a team or uploading a CSV to another system, run the checker first.

• After any formula or column change

  • Renaming columns, changing header rows, inserting new columns, or updating formulas can break references silently.

• Whenever you bulk-edit dates

  • Updating 50+ case records in one go is exactly when formatting conversions or locale swaps can invalidate everything at once.

• Right after importing from another system

  • Exports often come in as text. A quick validation can prevent “date math” from failing invisibly.

Inputs to verify (and how they affect output)

DocketMath’s deadline workflow depends on core fields that your spreadsheet needs to provide consistently. In a typical spreadsheet setup, ensure these are clean:

• Trigger/event date

  • Changes the computed deadline by approximately 2 years (Delaware’s general/default SOL baseline).

• Date format

  • Determines whether the checker can interpret values as real dates (not just strings that “look like” dates).

• Row-level linkage

  • Ensures each case row computes its own deadline, rather than accidentally reusing one shared cell.

Practical checklist:

Gentle warning: Don’t “mask” errors by overriding outputs. If the checker flags inconsistent or invalid dates, fix the underlying date fields and references—overwriting a wrong input can create a second, harder-to-detect wrong answer.

Try the checker

You can validate your spreadsheet deadline math using DocketMath’s deadline tool at:

/tools/deadline

Then, for each row/case record, sanity-check these steps:

1. Set your trigger/event date

   • This anchor is what the checker uses for the Delaware general/default 2-year SOL baseline (Title 11, § 205(b)(3)).

2. Confirm the date format

   • If your spreadsheet stores dates as text, convert them or parse them so the checker reads them reliably.

3. Compare outputs across a few sample rows

   • Pick 3–5 representative rows:

     • One that crosses a leap year
     • One with a clearly recent trigger date
     • One with an older trigger date
   • If the computed deadlines look “off by a year” or “off by a day,” stop and correct your date logic before scaling up.

What you should expect when it’s working

If your spreadsheet is set up correctly for the general/default 2-year SOL baseline, you should see deadlines that:

• Shift consistently when you change the trigger date
• Land around 2 years later (not “730 days” approximations)
• Avoid blanks, error strings, or impossible dates

What to do if the checker flags issues

Use the checker as a diagnosis tool:

• If the trigger date is unparseable

  • Fix the date representation first (text vs numeric date).

• If the deadlines are consistently wrong by a whole interval

  • Re-check:

    • whether you used the correct trigger date column, and
    • whether your sheet is accidentally applying a different rule rather than the general baseline.

• If only some rows fail

  • Look for row-specific formula references and mixed date formatting within the same column.

Common pitfall: A spreadsheet can format dates correctly visually while still storing them as text. The checker often surfaces this because date math becomes inconsistent or unreliable.

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