Common Damages Allocation mistakes in South Carolina

The top mistakes

Run this scenario in DocketMath using the Damages Allocation calculator.

Damages allocation is where many South Carolina cases lose time, credibility, and sometimes settlement leverage—especially when the numbers are correct but the structure of the damages math is wrong. Using DocketMath’s damages-allocation calculator, here are the most common allocation mistakes we see in South Carolina (US-SC).

1) Putting dollar amounts in the wrong “bucket”

A frequent error is allocating amounts into the wrong category—for example, combining:

• medical expenses with wage-loss totals, or
• future damages with past damages, or
• compensatory items with requested statutory items (when your model treats them separately).

Why it fails: Damages allocation depends on the type of harm and timing. Even if the overall number looks “big enough,” mixing buckets breaks the logic behind your calculator inputs and your presentation.

DocketMath impact: Your damages-allocation outputs change whenever the same dollars are entered into different fields. Re-check that each input lands in the correct category before relying on the summary.

2) Using the wrong start date for measuring damages (timing drift)

South Carolina’s general statute of limitations (SOL) helps frame when claims become time-barred.

• General SOL Period: 3 years
• General Statute: S.C. Code § 15-1 (general/default period)

Common error: Measuring damages from an incorrect “clock start,” such as:

• the date of the incident when your accrual theory ties to a later discovery/occurrence date, or
• the date you billed medical services rather than the date harm was incurred.

DocketMath impact: If your DocketMath workflow is being used to support damages windows (past vs. future, or pre- vs. post-filing), the wrong measurement date can overstate the past-damages portion.

3) Double-counting because inputs aren’t isolated

Even careful teams make arithmetic mistakes when:

• they reuse the same expense line in more than one category, or
• they manually add totals and also let DocketMath aggregate them again, or
• they switch from one measurement basis to another (e.g., net vs. gross) without updating every dependent input.

Practical example

• You enter $20,000 in medical.
• You also enter $20,000 again in a “total damages” or “prepaid/offset” type field.
• DocketMath sums all inputs, producing an inflated “total.”

4) Switching “bases” (gross vs. net, billed vs. paid) without documenting offsets

Another common allocation issue is failing to reconcile:

• insurance payments vs. total billed medical,
• reimbursements, subrogation, or partial coverage, and
• collateral source handling (how you present it in the damages narrative).

Practical symptom: Your allocation is internally inconsistent—e.g., the medical category reflects full billed charges, while later exhibits reflect patient-responsibility or capped amounts.

DocketMath impact: If your inputs reflect different “bases” across categories (some gross, some net), the output total won’t reconcile cleanly. DocketMath is accurate with what you enter—it can’t correct category-basis mismatches for you.

5) Blending future and past splits (especially for ongoing benefits)

Many damages models treat:

• past damages (already incurred) differently from
• future damages (to be incurred)

Common error: Placing future items into the past column (or vice versa), then applying one time horizon or assumption set to both.

DocketMath impact: If the calculator uses different time windows for allocations, the future portion will change when you move an item between columns. Small categorization errors can materially shift the overall total.

6) Applying one multiplier across categories that need different alignment

Teams sometimes apply the same multiplier or rate logic across categories that actually require different treatment frequencies, durations, or coverage periods.

DocketMath impact: Multipliers are sensitive to:

• assumed period length,
• selected start/end dates, and
• which bucket the multiplier attaches to.

If the multiplier is attached to the wrong bucket, you may end up with a result that looks precise—but doesn’t match the facts you’re modeling.

How to avoid them

Use DocketMath’s damages-allocation tool as a repeatable workflow, not just a one-off calculator. Below is a checklist aligned to where allocation mistakes typically happen.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Pre-define your buckets (before entering any numbers)

Create a quick “evidence → bucket” mapping. For each bucket, confirm the evidence basis:

Step 2: Anchor timing using South Carolina’s general SOL default (and state your assumption)

When your damages narrative depends on a timeliness window, start with the general/default SOL:

• S.C. Code § 15-1: 3 years

Because no claim-type-specific sub-rule was identified in the provided materials, don’t assume a different period for specialized claim types. Instead, document why the general period applies for your timeliness framing.

DocketMath output check (sensitivity):

• If the tool allows date-driven allocation, compare totals when you adjust start/end dates by a small increment (for example, 30–90 days). If totals swing widely, confirm your date selection and accrual theory.

Step 3: Verify each input has a “basis,” then keep bases consistent

Before finalizing inputs, pick one measurement basis per category and stick with it:

• medical = billed or net (choose one basis and apply it consistently)
• wage-loss = gross or net (choose one basis)
• reimbursements/credits = same basis rule as medical

Key idea: Worksheets can look right while silently mixing bases. DocketMath totals what you enter, so input discipline is doing the real work here.

Step 4: Run a double-count audit (fast reconciliation)

Use a simple pass/fail routine:

Step 5: Use sensitivity checks to catch mis-specified categories

When a result feels unexpectedly high (or oddly “clean”), change one input at a time in damages-allocation:

• move the past window end date by 30 days
• swap a future duration assumption
• move one evidence line from one bucket to another

Interpretation: If a small change causes a huge jump, that’s a signal to re-check category mapping and assumptions—not to blindly trust the output.

Step 6: Keep an evidence-to-input trail for review speed

For every field in the model, track:

• evidence date,
• amount,
• bucket/category,
• whether the amount is gross, net, billed, paid, or offset,
• and which timing window applies (past vs. future).

That trail makes it much easier to answer “why is this number here?” during internal review or settlement discussions.

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