Spreadsheet checks before running Damages Allocation in South Carolina

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a damages allocation calculator with a clean spreadsheet is one of the fastest ways to avoid downstream mistakes—especially when South Carolina deadlines can bar a claim outright.

Before you start allocation math in DocketMath (calculator: damages-allocation, accessible via /tools/damages-allocation), use the spreadsheet checker to verify the parts that most commonly break allocation outputs. For South Carolina, the checker should focus on timing logic tied to the statute of limitations (SOL) because recoverability often turns on whether the claim falls within the applicable time window.

Key items the checker should catch:

• Missing or inconsistent date fields

  • Examples: incident_date, filing_date, last_possible_date
  • If any are blank (or stored in a mismatched format), DocketMath can’t reliably determine whether the claim is within the default 3-year period.

• “Front-loaded” data errors that distort allocation inputs

  • Negative amounts (when not intended), duplicated line items, or category totals that don’t reconcile to the sum of their lines.
  • Column mix-ups, such as treating costs as damages, or swapping prejudgment vs. post-judgment columns (which can change how amounts are allocated).

• **SOL exposure based on the default South Carolina period (general rule)

  • South Carolina’s general SOL period is 3 years under GS 15-1.
  • No claim-type-specific sub-rule was found for this checker write-up, so this workflow uses the general/default period as the baseline.
  • The checker’s role is to confirm you’re using the correct baseline timing framework—not to invent specialized limitations rules.

Practical note: This content uses South Carolina’s general/default 3-year SOL for timing checks because GS 15-1 is the provided controlling statute and no claim-specific limitation rule was identified here. If your situation involves a different, claim-specific limitations rule, you’ll want additional jurisdiction-specific review outside this calculator workflow.

A simple way to think about it:

• The calculator allocates damages across categories.
• The checker ensures the spreadsheet inputs (including SOL timing assumptions) are coherent enough for those allocations to be meaningful.

Even a spreadsheet that “looks right” can produce misleading outputs if the underlying timing inputs are wrong.

When to run it

Run the spreadsheet checker before you run the Damages Allocation calculation in DocketMath. In practical terms, place it at the earliest point where your spreadsheet has:

• all relevant date inputs populated, and
• all damages lines finalized at least to category totals (even if you’ll refine later).

Recommended workflow:

1. Compile and standardize dates

   • Confirm the sheet uses a consistent format (for example, YYYY-MM-DD).
   • Make sure the filing_date you enter matches the date you intend to compare against for your internal timing assumptions.

2. Validate numeric integrity

   • Check that each damages line item is positive (unless your model explicitly uses credits).
   • Confirm every line item is included in the correct subtotal and is not duplicated across categories.

3. Run the SOL timing check using the default South Carolina rule

   • General SOL: 3 years
   • Statute: GS 15-1
   • Source: https://www.ncleg.gov/EnactedLegislation/Statutes/HTML/BySection/Chapter_15/GS_15-1.html
   • Also remember: this checker write-up uses the general/default 3-year period because no claim-type-specific rule was identified.

4. Only then run /tools/damages-allocation

Why ordering matters: the allocation calculator’s category breakdowns and derived totals are downstream of timing decisions and spreadsheet structure. If the timing check fails, your results may be mathematically consistent but strategically unreliable for timing-dependent questions.

Try the checker

You can test the workflow quickly by focusing on the two most common failure points: date logic and reconciliation totals.

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

1) Timing inputs to confirm

Use these (or equivalent) fields consistently across your sheet:

• incident_date (or another event/accrual-related date)
• filing_date (the date you’re comparing against)
• any “last relevant date” your model uses to represent accrual timing

Then apply South Carolina’s baseline:

• General SOL: 3 years
• Under GS 15-1
• This checker uses the general/default period (not a claim-specific alternative).

2) Allocation inputs to reconcile

For each damages category, confirm:

• Category subtotal = sum of its line items
• Grand total = sum of all categories
• No line item appears twice

A reconciliation checklist you can mirror in your sheet:

3) How outputs change in DocketMath

After a successful checker pass, running /tools/damages-allocation should produce:

• Timing-sensitive coherence

  • If the default 3-year baseline isn’t met (based on your inputs), the tool’s timing assumptions should reflect that in your modeled outputs (for example, reducing or flagging recoverability depending on how your worksheet is set up).
• Cleaner allocation distribution

  • With reconciliation errors removed, category shares and totals should stabilize—so you don’t see “mystery” differences between subtotals and grand totals.

Pitfall to watch: even if your dates “look right,” the checker should catch formatting issues (for example, dates stored as text like "04/15/2024") and mismatched formats across columns. Those problems can cause incorrect SOL comparisons.

To try it now, go directly to:

• Primary CTA: /tools/damages-allocation

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