Why Damages Allocation results differ in South Carolina

4 min read

Published April 15, 2026 • By DocketMath Team

The top 5 reasons results differ

When you run DocketMath’s Damages Allocation calculator for South Carolina (US-SC), you may notice that “the same” dispute can produce noticeably different allocation outcomes across runs, scenarios, or workflows. Those differences usually trace back to how the calculator’s jurisdiction-aware rules interact with the data you feed it.

Here are the top 5 reasons results differ in South Carolina:

  1. Different statute-of-limitations windows change which damages are eligible
    South Carolina’s general limitations period is 3 years under S.C. Gen. Stat. § 15-1. If your dataset includes damages outside that window, DocketMath may exclude or down-rank them depending on how you model dates.

    Important: The provided jurisdiction data did not identify a claim-type-specific sub-rule, so this article treats the general/default 3-year period as the applicable rule for US-SC.

  2. Date field mismatches (event date vs. filing/notice date)
    Damages allocation is extremely sensitive to timing inputs. If one run uses an incident/event date while another uses a demand/filing/notice date, you can shift the “eligible” slice of damages by weeks or months—enough to change totals.

  3. Allocation methodology assumptions (how you split buckets)
    DocketMath groups damages into time-eligible and/or category-eligible buckets based on your inputs. If you allocate by pay periods, invoices, or calendar months, small differences in grouping or categorization can change the final allocation.

  4. Partial recoverability treatment in your input structure
    Even when the South Carolina SOL rule stays the same, your input structure can affect outputs. For example, if you split damages into principal, interest, and fees, but one subset has different date coverage (or a different way of recording the relevant date), the calculator’s allocation results can move.

  5. Missing or null dates force conservative behavior
    If a damages line item lacks a date (or uses a null/blank value), DocketMath may treat it differently than items with complete coverage. That can create an apparent discrepancy that looks “jurisdictional,” but is really driven by data quality.

Gentle reminder: This explanation is for troubleshooting output differences in a tool workflow, not legal advice.

How to isolate the variable

Use this diagnostic approach to identify which input is driving the change:

  • Step 1: Lock the jurisdiction settings

    • Confirm the run is using US-SC
    • Confirm the SOL rule is 3 years under S.C. Gen. Stat. § 15-1 (general/default)
  • Step 2: Run an “all-else-equal” comparison Create two runs that differ in only one area:

    • Run A: same damages list, same categories, same allocation assumptions
    • Run B: change only one date field (e.g., event date vs. claim/filing date)
  • Step 3: Watch which output terms change Compare (as your DocketMath view allows):

    • Total eligible damages
    • Total allocated damages
    • Any components that appear excluded due to the SOL window (if your interface surfaces that detail)
  • Step 4: Verify the date coverage math Pick one line item and validate it by hand:

    • Identify the damages line’s date field as used in the run
    • Apply the applicable 3-year window from S.C. Gen. Stat. § 15-1
    • Confirm whether that date falls inside the eligible period for the reference date your workflow uses (e.g., filing/demand date as modeled)

If you want a starting point, you can launch DocketMath directly here: damages allocation calculator.

Next steps

  1. Standardize your date columns
    Decide on one “truth” date for each damages line item—such as:

    • Incident/event date, or
    • Invoice/service date, or
    • Notice/filing date (as your chosen reference)
      Then keep it consistent across runs.
  2. Document your mapping
    Maintain a short mapping sheet showing:

    • What each date field means
    • How DocketMath is expected to use it in allocation logic
  3. Re-run with controlled scenarios
    Try controlled changes to pinpoint sensitivity:

    • Scenario 1: Shift all dates forward/back by 90 days
    • Scenario 2: Re-date only one bucket (e.g., interest)
    • Scenario 3: Remove items with missing dates to see whether they drive exclusions or conservative allocations
  4. Keep the SOL rule explicit in your workflow
    For US-SC (based on the jurisdiction data provided here), treat the SOL component as:

    • 3 years general period under S.C. Gen. Stat. § 15-1
    • No claim-type-specific sub-rule applied (because none was identified in the provided jurisdiction data)

Warning: Don’t assume every allocation difference is “legal.” In DocketMath workflows, many meaningful discrepancies come from timing inputs and how damages are bucketed.

Related reading