Common Damages Allocation mistakes in California

The top mistakes

Damages allocation in California isn’t just an accounting exercise—it can affect what you can plausibly seek, how your figures are presented, and how they line up with the applicable statute-of-limitations (SOL) framework. When you use DocketMath (the damages-allocation calculator), small input mistakes can cascade into an output that’s arithmetically consistent but legally or evidentially hard to defend.

Below are the most common allocation mistakes we see when people run California damages through DocketMath / damages-allocation.

1) Mixing “damages” with “amount already paid” (and double-counting offsets)

A frequent error is treating insurance payments, prior settlements, or reimbursements as if they were additional damages rather than offsets. In many scenarios, those amounts reduce the net recovery you’re seeking, depending on how they’re characterized and documented.

What goes wrong in DocketMath:

• You enter paid/received amounts as “owed” damages.
• The calculator then outputs an inflated allocation total.

How to spot it quickly:

• If your total damages jump beyond what your medical/repair totals support, you may be double-counting.
• Check whether your numbers reflect gross claimed amounts versus net sought (after offsets).

2) Using the wrong time window for what damages cover

California’s general SOL period is 2 years under CCP §335.1. The jurisdiction data also notes that no claim-type-specific sub-rule was found, so this article uses the general/default 2-year baseline only.

What goes wrong in DocketMath:

• You allocate lost wages or other time-based damages to periods that fall outside the 2-year window you’re modeling.
• The output may look precise, but the covered time span may be risky.

3) Failing to separate economic vs. non-economic categories

California damages allocation often benefits from clean category separation, such as:

• Economic damages (medical costs, repair costs, lost wages), and
• Non-economic damages (pain and suffering, loss of enjoyment, etc.).

What goes wrong in DocketMath:

• You enter a lump sum into a single field, or you combine categories.
• The tool can still compute totals, but it becomes harder to map results to the way evidence (bills, pay records) and narrative are usually presented.

Downstream effect:
If the case narrows later, category-inconsistent numbers are more difficult to justify component-by-component.

4) Assigning future damages without a supporting method

Another common issue: allocating “future” amounts as if they were simply “more of the same,” without tying them to an assumption you can explain.

What goes wrong in DocketMath:

• You include future medical or future lost earnings but don’t define the projection structure (start/end dates, rate, or duration).
• The calculator produces a future total, but you can’t readily explain how it was built.

Fix pattern:
Use a consistent structure such as rate × duration, and ensure the duration aligns with your assumptions and the evidence you have (or plan to develop).

5) Rounding in a way that changes totals materially

Users often round too early—especially when breaking figures into months—and then round again. Over multiple categories, this can create “math drift.”

What goes wrong in DocketMath:

• Each category is rounded separately.
• The sum of rounded parts doesn’t match the rounded total you expect.

Quality check:
Keep cents during intermediate steps when possible, and round once at the final step (or at least use one consistent rounding strategy).

6) Confusing “past vs. future” with “SOL exposure”

People sometimes assume that “past damages” automatically fit within the SOL window. But SOL coverage depends on accrual and how the actionable period is defined—not merely whether the harm occurred in the past.

What goes wrong in DocketMath:

• You treat the entire “past” number as within the 2-year period automatically.
• You may over-allocate economic loss outside the modeled general/default SOL framework.

7) Omitting key inputs that control the calculator’s output

DocketMath (damages-allocation) is only as reliable as the inputs you provide. If you leave out inputs (or leave fields blank and assume they don’t matter), the output can become misleading.

Common missing inputs:

• Paid amounts that should be treated as offsets (not damages)
• Date ranges for wage loss or expenses
• Period definitions for future projections (start/end dates, rate, duration)

How to avoid them

A safer allocation workflow is mostly about inputs, sequencing, and keeping a clear record of assumptions—especially for California’s general/default 2-year baseline under CCP §335.1.

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.

Use a “net sought” mindset before you calculate

Decide whether you’re modeling:

• Gross claimed damages, or
• Net sought damages (after offsets)

Then keep that decision consistent in DocketMath.

Checklist:

Constrain damages to the relevant 2-year baseline (general/default)

For the general/default SOL baseline used here:

• 2 years
• CCP §335.1
• Source context: Nolo’s compilation page (as provided in the jurisdiction data)

Because the jurisdiction data indicates no claim-type-specific sub-rule was found, treat this as a baseline model, not a guarantee for every claim type.

Checklist:

Split categories instead of using one bucket

Prefer a structured allocation:

• Economic (medical + expenses, wage loss), and
• Non-economic (pain/suffering)

In DocketMath, populate category fields deliberately so the output can match your notes and supporting materials.

Checklist:

Make future damages explainable (rate × duration)

If you include future figures, tie them to:

• a rate (monthly/weekly), and
• a duration (start date → end date),
  using a consistent projection method.

Checklist:

Run two quick “sanity checks” after the calculation

Use the output to catch the common failure modes:

• Document check: Compare allocation totals to your underlying materials (bills, pay stubs, invoices).
• Rounding check: Rounded final numbers should still approximate the unrounded logic you intended.

Tip: If you only check totals after rounding, you can miss an input entered under the wrong category/field—producing a total that “looks right” but is category-wrong.

Lock your inputs, then document what changed

When you revise a figure, note what changed and how the output moved:

• Change the wage-loss date range → total should generally move with that timeframe
• Change paid amounts treated as offsets → net sought should move accordingly

If you need a reference while working, use the tool here: damages-allocation. You can also browse other DocketMath tools at DocketMath tools.

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