Spreadsheet checks before running statute of limitations in North Carolina
6 min read
Published April 8, 2026 • By DocketMath Team
What the checker catches
Before you run a statute of limitations (SOL) calculation in North Carolina, your spreadsheet is effectively doing two jobs at once: (1) capturing the right dates, and (2) transforming those dates into a legally meaningful timeline. DocketMath’s spreadsheet checker helps you verify that your date logic is internally consistent before you treat the output as a definitive legal position.
Below are the most common spreadsheet issues the checker is designed to catch when you’re running SOL periods—including North Carolina’s general/default 3-year period.
Date integrity problems
- Blank or malformed dates: Inputs like
01/5/2024vs1/5/24can cause a date to be stored as text, which may break or subtly change formula behavior. - Impossible sequences: A filing date earlier than the event date (or a tolling start date after a tolling end date) often indicates reversed inputs, mis-labeled columns, or copy/paste errors.
- Time-of-day artifacts: If your sheet stores timestamps, you can get off-by-one-day effects when your formulas assume “date only.”
- Timezone conversion surprises: Imported dates (especially from CSV exports or other systems) can shift the effective date if the spreadsheet interprets timezone or formats differently.
Calculation logic problems
- Wrong SOL period wired in: Your sheet might still be using an outdated period (e.g., 2 years or 4 years) or a value left over from another jurisdiction/template.
- “Anniversary” math mistakes: Date functions and rounding choices (for example, how you add years, subtract dates, or convert with
DATEDIF) can shift an expiration date. - Unit mismatches: Mixing days, months, and years can produce inconsistent results. For the general/default rule, you want a consistent approach tied to 3 years, not a blended approximation.
- Sign errors: Subtracting dates in the wrong order can make elapsed time negative or unexpectedly small—often flipping “expired vs. not expired” logic.
Input/assumption mismatches (the “default rule” guardrail)
DocketMath’s checker also helps you confirm your spreadsheet is using the intended baseline—especially important when your analysis depends on an assumption that may not be independently verified in the sheet.
Use the following North Carolina framing clearly in your workflow:
- General/default SOL period: 3 years.
- General statute / SAFE Child Act reference: North Carolina guidance (including the material referenced in the SAFE Child Act context) supports a 3-year general/default approach for SOL considerations in sexual assault contexts, as described in supporting victim-survivor materials.
- No claim-type-specific sub-rule found: If your sheet does not include a separately verified claim-type-specific override, treat your calculation as using the general/default 3-year period.
Gentle disclaimer: This is spreadsheet validation guidance, not legal advice. Use the checker to validate data and math, then verify any law-specific overlays in your own legal workflow.
When to run it
Run DocketMath’s spreadsheet checks before you run the SOL calculator, and again after you update your inputs. A practical sequence is:
Run the checker before importing a spreadsheet into the Statute Of Limitations workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
Recommended workflow (spreadsheet edition)
- Freeze the input schema
- Confirm your columns for: event/trigger date, any discovery/notice date (if you track it), tolling start/end dates (if you track them), and filing date.
- Run spreadsheet checks
- Validate date formats and sequencing.
- Confirm the SOL period parameter in your calculator layer is set to the North Carolina general/default: 3 years.
- Run the statute-of-limitations calculation
- Use the calculator’s outputs (e.g., expiration date and elapsed time) as the next step—after the checker passes.
- Re-check after you edit
- Any change to critical date inputs (especially event date or filing date) should trigger another checker run.
“Update triggers” that should force a re-check
- You change any date cell on a row.
- You copy/paste dates from another system or export.
- You update a formula that references the SOL period (e.g., changing a constant like
365*3). - You switch ranges/tabs (common cause of misalignment).
Quick per-batch checklist:
Try the checker
Use DocketMath to sanity-check your spreadsheet inputs and calculations before running the statute-of-limitations step. Start here:
- Primary CTA: /tools/statute-of-limitations
Then mirror the workflow inside your spreadsheet.
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
What to enter (and how outputs should change)
Assuming your sheet has standard columns, the checker should treat these as critical inputs:
| Spreadsheet input | Checker goal | Output impact if wrong |
|---|---|---|
| Event/trigger date | Confirm valid date + sensible ordering | Expiration date shifts forward/backward; elapsed time becomes inaccurate |
| Filing date | Validate it parses as a date and is positioned correctly vs event | “Expired vs not expired” can flip |
| SOL period parameter | Confirm 3-year default is applied | Expiration date moves by a full year(s) if mismatched |
| Tolling start/end (if tracked) | Validate window logic | Expiration date may extend; invalid windows may shorten or break formulas |
A practical example of detecting a mismatch
If your expiration date is coming out as 2022-03-01 for an event in 2023, that’s a red flag. The checker commonly flags one or more of these causes:
- the event date cell is being treated as text,
- the formula is referencing the wrong column,
- the date order is reversed in subtraction, or
- the SOL period parameter isn’t actually set to 3 years.
DocketMath tip: validate the assumption layer
Because the North Carolina general/default period you’re using is 3 years, your spreadsheet shouldn’t silently apply a different duration. If your workbook uses a configurable SOL cell (for example, SOL_YEARS), ensure it’s set to 3 for general/default runs.
If you later add claim-type-specific logic, treat that as an explicit change: the checker can help confirm whether your sheet is still following the intended baseline, but it won’t replace the need for claim-specific legal verification.
Pitfall to watch: if your sheet converts “3 years” into a fixed day count (e.g.,
3 * 365), leap years can create small drifts. The checker won’t rewrite your legal model, but it can help you spot whether your dates behave inconsistently.
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
