Spreadsheet checks before running Damages Allocation in North Carolina

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run DocketMath’s Damages Allocation calculator for a matter in North Carolina (US-NC), run a quick spreadsheet check to align your inputs with the calculator’s jurisdiction-aware rules. This is not about deciding liability—it’s about preventing avoidable calculation errors that can quietly skew allocation tables.

This North Carolina–focused spreadsheet checker is designed to catch common problems tied to the workflow’s default statute of limitations (SOL) structure.

Key items the checker reviews

• **Date hygiene (critical for SOL gating)

  • Confirm the event/incidence date (often the injury/incident date) is present and in a compatible format.
  • Verify any filing date (or equivalent reference date you use for timing) is present.
  • Check for impossible or reversed sequences—for example, a filing/reference date that appears earlier than the event date.
  • Practical tip: if your spreadsheet sometimes uses mixed formats (e.g., “01/03/2024” in one place and “2024-01-03” in another), normalize to a consistent format before running.

• “General SOL period = 3 years” applied as the default

  • The checker expects your sheet to reflect that the baseline SOL assumption is 3 years.
  • If your spreadsheet indicates an alternate limitation period (for example, via a claim-type selection), the checker flags the inconsistency when it cannot confirm a corresponding claim-type-specific sub-rule for this workflow.
  • Important: no claim-type-specific sub-rule was found in the checker workflow documentation for this situation. As a result, the checker treats the 3-year general period as the default unless your inputs consistently reflect a different approach you’re prepared to validate outside this tool.

• **SAFE Child Act notice/labels (consistency checks)

  • If your sheet includes a “SAFE Child Act” label (or a field referencing it), the checker verifies that the label isn’t being used to implicitly swap assumptions without consistent supporting inputs.
  • In practice, this means:

    • the sheet should not rely on hidden logic like naming conventions alone, and
    • any “special treatment” intent should be reflected clearly in the fields that drive the checker’s logic.
  • Gentle reminder: a label in a spreadsheet is not the same as a documented rule in the workflow. The checker is looking for input consistency, not just text.

• **Allocation integrity (the calculator can only allocate what your sheet represents accurately)

  • Reconciliation checks: component damages should sum to the “grand total” (or the total field your table uses).
  • Negative amounts: negatives are not automatically “wrong” if your workflow uses them intentionally for credits/offsets, but the checker treats unexpected negatives as a potential anomaly worth reviewing.
  • Unit mismatches: for example, amounts entered as “monthly” values in an “annual” column (or vice versa) can create totals that look plausible while being incorrect.

• Data completeness checks

  • Missing required values in key input cells.
  • Non-numeric entries in numeric columns (a common issue when currency symbols, commas, or text appear where numbers are expected).
  • Practical tip: currency values like “$12,500.00” sometimes paste in as text—convert them to numeric values before running the checker.

Scope note / disclaimer

The checker’s SOL logic is intentionally conservative. If your spreadsheet suggests a non-default limitation period but doesn’t provide consistent inputs to support that approach, the checker will highlight it so you can decide whether your sheet needs restructuring before running allocation.

When to run it

Run the checker before you launch Damages Allocation in DocketMath, and then again after any changes that affect:

• time periods (dates and timing logic), and/or
• dollar totals (component damages that roll into the allocation table).

Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Practical timing recommendations

• Right after data entry

  • When incident/event dates and filing/reference dates are filled in.
• After any spreadsheet edits to damages components

  • For example, after updating medical expenses, lost wages, or other categories that feed into totals.
• Before exporting or sharing results

  • If your outputs will be used in a deck, a report, or a filing workflow, catching reconciliation and formatting issues early saves time later.

A quick preflight checklist

• Confirm incident/event date formatting (for example, YYYY-MM-DD is typically the safest approach).
• Confirm filing/reference date formatting.
• Confirm the sheet’s SOL basis field aligns with the checker’s default assumption (3 years general SOL).
• Reconcile each damages component sum to the stated total.
• Then run the allocation via DocketMath.

If you want the workflow anchored to the calculator experience, start from /tools/damages-allocation and run the checker step immediately.

Try the checker

You can use DocketMath to validate your spreadsheet inputs for North Carolina (US-NC) Damages Allocation. Start at the tool, run the spreadsheet checks first, then address anything flagged.

1. Open /tools/damages-allocation
2. Load your spreadsheet (or paste the relevant table)
3. Review the North Carolina spreadsheet checks tied to the workflow’s default SOL structure:

   • General SOL period: 3 years
   • No claim-type-specific sub-rule found for altering that baseline within this workflow, so the checker treats 3 years as the default unless your inputs consistently reflect otherwise
4. Fix flagged items directly in your sheet:

   • resolve date sequencing issues
   • correct non-numeric cells
   • reconcile totals
   • ensure “SAFE Child Act” labeling doesn’t conflict with the default 3-year general SOL assumption through inconsistent inputs

How inputs change the outputs (what to watch)

The checker affects allocation results in two main ways:

• SOL gating / time-window calculations

  • If dates are missing, reversed, or formatted inconsistently, the time window used for modeling can change—potentially shrinking or enlarging the allocation basis.
• Component integrity

  • If component sums don’t reconcile to totals, the allocation may be driven by incorrect intermediate values.

Symptom → likely spreadsheet issue

Law framing the default assumption (North Carolina)

For this North Carolina workflow, the checker uses the general SOL period of 3 years as the baseline. The workflow does not identify a claim-type-specific limitation sub-rule for altering that baseline within the checker itself.

For publicly available context related to support for sexual assault survivors and related information, see the North Carolina Department of Justice:

• https://www.ncdoj.gov/public-protection/supporting-victims-and-survivors-of-sexual-assault/

Gentle caution: don’t rely on labels alone (e.g., “SAFE Child Act”) to change SOL assumptions inside a spreadsheet. If special treatment is intended, make sure your sheet inputs consistently reflect it—otherwise the checker will treat the 3-year general SOL as the default approach.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules