Spreadsheet checks before running deadlines in North Carolina

What the checker catches

Spreadsheet-driven deadlines are where small math errors turn into real-world consequences. DocketMath helps you sanity-check the computations before you rely on them to schedule tasks, send notices, or file anything—especially in North Carolina.

This walkthrough focuses on general (default) deadline sanity checks using North Carolina’s 3-year general statute of limitations (SOL) baseline. The SAFE Child Act is referenced in North Carolina materials related to sexual-assault victims and survivors, but no claim-type-specific sub-rule was found in the provided materials. So, for this article, treat the 3-year general period as the default for spreadsheet checks.

Use DocketMath’s checklist to catch issues like:

• Wrong baseline period applied

  • Example failure: the sheet assumes 4 years (or 2 years) instead of the 3-year general baseline.
• Off-by-one day and time-of-day bugs

  • Example failure: “+ 365 days” is used instead of a date-add method that respects leap years and date boundaries.
• Timezone/UTC conversion mistakes

  • Example failure: an export/import converts a local date into a UTC timestamp, shifting the displayed date.
• Bad “event date” selection

  • Example failure: the sheet uses “intake date” when your deadline logic requires the correct starting point (your “event/trigger date” column).
• Mixed formats causing silent parsing errors

  • Example failure: one column is MM/DD/YYYY, another is stored as text; sorting and add-days create nonsense or blanks.
• Weekend/holiday shifting done incorrectly

  • Example failure: deadlines are rolled to Monday inconsistently (or rolled twice).
• Copied formulas referencing the wrong row

  • Example failure: absolute/relative references (e.g., $B$2 vs B2) cause the same deadline to appear for multiple rows.

A practical way to structure this in your spreadsheet is to separate inputs from outputs:

If your sheet mixes parameters and case inputs, the checker should push you to isolate them—this is where many errors disappear.

When to run it

Run DocketMath’s spreadsheet checker before you use computed deadlines in operational workflows. In a North Carolina deadline pipeline, the safest checkpoints are:

• Immediately after you build or modify the sheet

  • Especially after changing:

    • the date-add formula,
    • the baseline SOL years,
    • any “roll forward” logic for weekends/holidays.
• After importing data

  • CSV imports and bulk copy/paste are prime times for:

    • text-to-date parsing failures,
    • format drift across rows.
• Each time you run the “deadline” calculation output in bulk

  • Validate a sample first, then sweep-check.
• Before exporting to another tool or sending to stakeholders

  • A final check helps prevent mismatches between “what you computed” and “what someone else sees after import/export.”

A good workflow is: compute → sample-check → full-check → lock the file. Concretely:

1. Verify 5 representative rows, such as:

   • one across a leap-year boundary,
   • one near end-of-month (e.g., Jan 31),
   • one with a future date,
   • one close to “today,”
   • one with missing/blank event dates to ensure safe behavior.
2. Then run a full validation pass inside DocketMath to confirm:

   • baseline periods,
   • date-add method,
   • consistent event-date usage.

Because the default general SOL period is 3 years for the purposes of this article, your checker should flag rows where the computed deadline is not consistent with “event date + 3 years”, adjusted according to your spreadsheet’s chosen date-handling conventions.

Also, SAFE Child Act context is included in the provided North Carolina materials, but the dataset you provided does not include claim-type-specific rules for this article. Treat that reference as context—not as a personalized rule engine. Your checker’s job here is to confirm you’re not accidentally applying the wrong baseline or miscomputing the date arithmetic.

Try the checker

You can use DocketMath’s deadline tool to sanity-check the date logic powering your spreadsheet deadlines.

Primary CTA: DocketMath — Deadline

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

What to prepare (inputs)

Before you run the checker, gather the fields your spreadsheet uses (even if the column names differ):

• Event date / trigger date: the date your deadline clock starts from
• Baseline period (years): set to 3 for the general default approach used here
• (Optional) Notes about adjustments your spreadsheet applies:

  • weekend/holiday roll rules,
  • whether you treat the deadline as end-of-day vs start-of-day.

How to interpret “before vs after” changes when you fix common errors

These are the patterns you’d expect to see:

• If your spreadsheet uses the wrong baseline:

  • Output deadlines shift by roughly ±1 year (or more) across rows.
• If leap years aren’t handled:

  • Deadlines drift by 1 day after a leap-year boundary.
• If dates are stored as text:

  • Output may become blank, #VALUE!, or an obviously incorrect date.
• If weekend/holiday shifting is inconsistent:

  • Some deadlines change while others don’t, creating an uneven pattern.

Quick self-audit checklist (works with most spreadsheets)

Before relying on computed deadlines, confirm:

One-minute interpretation rule

• If you see systemic shifts (same direction across most rows): likely baseline period or core formula logic.
• If shifts are sporadic: likely parsing/formatting issues or row-reference mistakes.

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