How to run Structured Settlement in DocketMath for California

Step-by-step

This guide walks you through running a Structured Settlement in DocketMath for California (US-CA) using jurisdiction-aware rules tied to the California Structured Settlement Protection Act.

1) Start the Structured Settlement workflow in DocketMath

Open the tool here:

• Primary CTA: /tools/structured-settlement

Choose California (US-CA) as the jurisdiction if DocketMath prompts you to select it (or confirm the jurisdiction setting is set to US-CA).

2) Enter the core structured settlement inputs

DocketMath’s structured-settlement calculator typically needs at least these categories of information. If your screen uses slightly different labels, map them to the same concepts:

• Payment stream

  • Frequency (e.g., annual, monthly)
  • Start date (first payment date)
  • End date (last payment date) or number of payments
  • Amount per payment (or a schedule if amounts change)
• Discounting / valuation assumptions

  • Discount rate (annualized) used to convert future payments into present value
• Transfer-related framing (for California workflows)

  • Whether you are modeling the value of payments to be received (baseline valuation)
  • Whether you are also comparing that value to a proposed transfer price (useful for discussions/negotiation economics)

If you have an actual payment schedule from the structured settlement agreement, enter that schedule directly (rather than approximating it as a single lump sum). The payment timing is usually a major driver of present value.

3) Confirm that DocketMath is using California’s default transfer framework

California’s structured settlement transfer regime is governed by Cal. Ins. Code §§ 10134–10139 (Structured Settlement Protection Act).

Practical implication for DocketMath runs: In California, a transfer of structured settlement payment rights is not simply something you “compute” into existence with a PV calculation. Under the statute, transfers must be handled through a court-approval process.

DocketMath’s jurisdiction-aware layer should therefore reflect that, in California, the transfer concept is court-approval-first, not “free-form.” Your calculator can help quantify value, but it does not replace the legal approval requirement.

4) Run the calculation and review the outputs

After inputs are entered, run the calculator.

You should expect outputs along these lines:

• Present value (PV) of the payment stream using your discount rate
• Total nominal value (sum of future payments without discounting)
• Payment timing breakdown (if shown by the UI)
• Potentially comparison figures if you enter a proposed transfer price

How to interpret it quickly:

• If PV is much lower than the nominal totals, the discount rate and how long payments are deferred likely drive most of the difference.
• If the payment stream has long delay (late start) or a long tail (extended end), relatively small discount-rate changes can materially change PV.

5) If you are modeling a transfer price, align your comparison with California’s “approval first” approach

Under Cal. Ins. Code §§ 10134–10139, the key legal question is whether the transfer is addressed through the statute’s court-approval framework (including the statutory standards the court must consider).

In a DocketMath workflow used for transfer-related analysis, treat PV as:

• the valuation basis for discussions and economic comparisons, and
• a number you may want to reconcile with any proposed purchase/transfer economics,

…but keep the separation clear:

• PV ≠ court approval
• A PV comparison can help you understand pricing, timing, and value—but it does not determine whether a transfer is effective under California law.

6) Use DocketMath results consistently across scenarios

A strong way to use DocketMath is to run multiple scenarios while changing one variable at a time, such as:

• Discount rate: try 3.0%, 5.0%, 7.5%
• Payment frequency: monthly vs. annual (if your payment schedule supports it)
• Start date: compare earlier vs. later payment commencements (if there’s uncertainty)

Repeatability checklist:

• Keep the payment schedule identical across runs
• Change only the discount rate (or only dates) per scenario
• Record PV and nominal totals for each scenario so you can compare them quickly

7) Rely on California jurisdiction settings for default behavior (and avoid assuming sub-rules)

The California Structured Settlement Protection Act provides the general/default framework for transfers of structured settlement payment rights.

No claim-type-specific sub-rule was found for this tool guidance. That means your DocketMath workflow should rely on the statute’s general transfer framework rather than switching to a special-case rule based on a particular claim type—unless DocketMath explicitly provides a jurisdiction-mapped claim-type selection mechanism with a clearly supported rule.

Common pitfalls

Here are mistakes that commonly lead to confusing or non-actionable results when running structured settlement calculations in DocketMath for California:

1. Using a lump-sum assumption when the agreement is a stream
   If payments are actually periodic, entering a single lump sum can distort PV significantly—especially once discounting is applied.

2. Mismatching payment dates and frequency
   Monthly vs. annual schedules can shift PV enough to affect comparisons. Double-check:

   • first payment date
   • recurrence pattern
   • last payment date or count

3. Changing the discount rate unintentionally across runs
   It’s easy to re-enter 5.0% as 5.1% (or to use a different UI default). Decide the rate per scenario and keep it documented.

4. Assuming a calculation “approves” a transfer
   California transfers are regulated by Cal. Ins. Code §§ 10134–10139 and require advance court approval under the statute’s framework. Even if a number looks favorable, the court-approval requirement remains.

5. Assuming claim-type sub-rules without explicit support
   As noted above: no claim-type-specific sub-rule was found for this guidance. Default to the statute’s general framework unless DocketMath clearly supports a California-specific claim-type selection you can point to.

6. Not preserving an audit trail of inputs
   If PV changes later, you’ll want the exact payment schedule, discount rate, and timing assumptions used in each run.

Quick self-audit:

• Dates match the settlement schedule
• Frequency matches the schedule
• Discount rate is documented
• PV vs. nominal comparisons are recorded
• Transfer comparisons are treated as valuation only (not legal approval)

Try it

Use this quick, practical testing plan to validate a California run in DocketMath:

1. Run a baseline valuation

   • Enter the full payment schedule exactly as provided.
   • Use one discount rate (e.g., your default assumption) to compute PV.

2. Run a sensitivity check (discount rate)

   • Re-run with at least 2–3 additional discount rates.
   • Track how PV responds.

3. Run a timing check (start date)

   • If the schedule has uncertainty, test “earliest plausible start” vs. “latest plausible start.”
   • Compare PV deltas.

4. If you add a proposed transfer price, compare against PV

   • Use PV as the valuation anchor.
   • Do not interpret the comparison as meeting California’s legal approval standards under Cal. Ins. Code §§ 10134–10139.

When you’re done, you should have:

• PV and nominal totals for the baseline case
• A small matrix of PV outcomes under different discount rates and timing assumptions
• A clear sense of whether discounting or timing differences drive most of the variation

Related reading

• How to calculate Structured Settlement in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Structured Settlement in Philippines — Worked example with real statute citations
• Inputs you need for Structured Settlement in Philippines — Input checklist with sourcing guidance