Why Structured Settlement results differ in California

The top 5 reasons results differ

Run this scenario in DocketMath using the Structured Settlement calculator.

If you’re comparing Structured Settlement outputs for California (US-CA) and they don’t match, the differences usually come from the inputs and from jurisdiction-aware rules that DocketMath (structured-settlement) applies—or excludes—based on CA assumptions. In most “same case, different result” scenarios, it’s not the math; it’s the data you fed in and the default rule set used.

1) Claim timing: the default limitations period (not a special-case rule)

California’s general civil statute of limitations for many injury-related claims is 2 years, shown in the jurisdiction data as CCP §335.1. Importantly, no claim-type-specific sub-rule was found in the provided CA jurisdiction data—so the tool should treat this 2-year period as the default, not a special carve-out.

• General SOL period used: 2 years
• General statute: CCP §335.1
• Source statement: CA personal injury laws summary indicates 2 years as the general rule
  Source: https://www.alllaw.com/articles/nolo/personal-injury/laws-california.html

Why it changes results: If you input dates that shift the claim from “timely under the default” to “outside the default” window, downstream timing-related assumptions in the model can change. That can affect outputs such as payment schedule feasibility or timing-related adjustments.

2) Start date / accrual date mismatch

Even when two people agree on the gross settlement value, they may disagree on when the claim became legally actionable. DocketMath is sensitive to the timeline fields you provide, such as:

• accrual / claim start date
• settlement agreement date (if you input it)
• payment start date (if applicable)

Result effect: Moving the accrual date by weeks or months can change whether the modeled schedule is treated as consistent with the default limitations framework—and that can ripple into the calculated payment structure.

3) Different payment plan assumptions (frequency, term, and escalation)

Structured settlements can be modeled using different streams, including:

• payment frequency (e.g., annual vs. more frequent spacing)
• term length (fixed term vs. other term logic your workflow supports)
• escalation (COLA-style increases)

If one run uses level payments while another uses escalation, the present value and the resulting funding/structure numbers will differ.

4) Amount allocation details (lump sum vs. installments)

Many workflows split a settlement into components, such as:

• structured payments / installment stream
• separate lump-sum portion

DocketMath reflects your split. Two runs using the same total gross settlement—but different structured-vs-lump-sum allocations—can produce different outputs even when everything else matches.

5) Input normalization and units

Small data-entry differences are a frequent cause of “why don’t these match?” outcomes, such as:

• writing money as 250000 vs $250,000
• using inconsistent date formats
• entering “years” where a field expects “months”
• leaving out a required conversion/normalization field (if your workflow exposes one)

Result effect: The tool is deterministic—if the inputs differ, the outputs will differ.

How to isolate the variable

Don’t try to reason from the final discrepancy alone. Instead, isolate the cause inside DocketMath by holding everything constant except one input.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

A quick diagnostic checklist

A practical “change one thing” protocol

1. Baseline run: Use your most complete set of inputs.
2. Toggle only timing: Change only the accrual/claim start date by a small, meaningful increment (e.g., 30 days).
3. Re-run and compare: Note exactly which outputs change.
4. Toggle only payment model inputs: Change only payment frequency or escalation (one at a time).
5. Toggle only allocation: Change only the lump-sum vs. structured split.
6. Repeat until matched: Once the outputs align, you’ve identified the variable.

To keep the process focused, start at the primary tool here:

• /tools/structured-settlement

If you’re also checking other calculation components, you may prefer starting from:

• /tools

Next steps

1. Record the “diff”
   Write down the exact lines or fields that differ between runs (e.g., payment amount, number of payments, escalation effect, funding total, or timing-related indicators).

2. Audit dates first
   Because the provided CA guidance uses a default 2-year SOL under CCP §335.1, the most common mismatch source is usually the date inputs (especially accrual/claim start date).

3. Compare payment plan parameters
   Verify frequency, term, escalation, and any frequency-to-term conversion you may have applied.

4. Verify allocation logic
   Confirm that both runs use the same gross amount and the same split between structured and lump-sum components.

5. Do a minimal reproducible run
   Keep only the required inputs, run once, then add optional inputs back one-by-one until you reproduce the mismatch.

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado