How to run Structured Settlement in DocketMath for California

Step-by-step

This guide shows how to run a Structured Settlement calculation in DocketMath for California (US-CA) using jurisdiction-aware rules. We’ll focus on how to set up the inputs, what DocketMath outputs, and where California timing context (SOL) can matter in settlement planning—not legal strategy.

1) Open the calculator and select the California jurisdiction

1. Go to the Structured Settlement tool: /tools/structured-settlement.
2. Confirm the jurisdiction is set to US-CA (California).
3. Choose the calculation mode/type shown in the tool (the calculator labeled structured-settlement).

If your DocketMath interface allows a jurisdiction switch, set it to US-CA so the calculator applies the relevant California timing assumptions where it supports them (for example, using a baseline limitations period for context later).

2) Gather the basic payment facts you’ll enter

Structured settlements model cash flows over time. In DocketMath, you’ll typically provide inputs like:

• Total settlement amount (the gross amount to be structured)
• Start date (when payments begin)
• Payment schedule (e.g., monthly, annual, or a custom schedule)
• Number of payments or end date
• Interest/discount rate (if the calculator asks for it)
• Any lump sum component (if your structure includes an initial payment)

Use your actual settlement proposal numbers when possible. When you don’t have final terms yet, run multiple scenarios to see how changing dates, counts, or rates changes the output.

Pro tip: Keep a quick written log of your assumptions for each run, such as:

• “Scenario A: 20 payments, 3% rate, payments start 2026-06-01”
• “Scenario B: monthly payments ending 2030-01-15, 4.5% rate”

That makes it easier to update the model when the other side revises terms.

3) Enter inputs in DocketMath and watch how outputs change

As you update inputs, DocketMath’s output typically shifts in predictable ways:

• Start date change
  Moves the timing of future payments; projections (and present value, if shown) adjust because receiving money earlier vs. later changes the discounting math.
• Payment count / end date change
  Extends or shortens the stream; you’ll usually see differences in total projected payments and in discounted amounts.
• Interest/discount rate change
  A higher rate generally changes the present value required to fund the same stream (even if nominal totals look similar).
• Lump sum inclusion
  Adds/changes both nominal totals and present value, since an upfront amount is not discounted (or is discounted less than later payments).

If the tool provides breakdowns by timing (for example, a payment schedule summary), use those to verify that the entered structure matches what you intend to model.

4) Add California timing context using the general limitations rule

California’s general statute of limitations (SOL) for many civil actions is 2 years, governed by California Code of Civil Procedure (CCP) § 335.1.

This matters as context for settlement discussions—DocketMath’s Structured Settlement calculator is not the same thing as deciding whether a claim is timely filed.

For this article’s baseline timing reference, use:

• General SOL Period: 2 years
• General Statute: CCP § 335.1
• Source: https://www.alllaw.com/articles/nolo/personal-injury/laws-california.html

Important clarification:
No claim-type-specific sub-rule was found. The 2-year period above is a general/default baseline, not a guarantee that a particular claim fits the general rule.

5) Run at least two scenarios (don’t rely on one)

Structured settlement modeling is sensitive to schedule and rate. A practical workflow is to run at least two scenarios side-by-side:

• Scenario A (conservative): lower discount rate or shorter duration (depending on what your inputs allow)
• Scenario B (aggressive): higher discount rate or longer duration

Then compare DocketMath outputs side-by-side, typically including:

• total projected payout (nominal)
• payment schedule details
• present value / discounted amount (rate-sensitive)

This helps you see how fragile (or stable) the numbers are to changes in assumptions.

6) Save or export your calculation results

If DocketMath supports saving, exporting, or copying results, do the following:

• Save your preferred run as “current proposal”
• Keep an alternate run as “backup” or “alternate term”
• Record the key inputs alongside the output (start date, frequency/count or end date, rate, lump sum)

This speeds up revisions and reduces confusion when versions change during negotiations.

7) Use the output as a communication tool—not a conclusion

Structured settlement outputs help translate settlement terms into a clear payment plan. Still, the calculator output is only one part of the broader process.

When sharing the results, consider including:

• the assumptions you entered (especially start date, schedule, and discount rate)
• whether the other side is using matching assumptions
• what’s still unknown (for example, the actual payment commencement date or agreed funding structure)

Common pitfalls

Structured settlement models usually break due to setup, not math. When running US-CA in DocketMath, watch for:

• Using the wrong jurisdiction setting
  Confirm US-CA is selected so the California baseline timing context you’re using aligns with your forum assumptions.
• Mixing up the general SOL baseline vs. claim-specific rules
  This guide references CCP § 335.1 as a 2-year general/default baseline. It does not provide claim-type-specific sub-rules.
• Entering an inconsistent start date
  If your “start date” doesn’t match the first payment date you intend to model, the projected stream and any present value outputs can shift.
• Confusing total nominal payments with present value
  Total projected payout ≠ present value. Discount rate changes the present value even if nominal totals appear similar.
• Single-scenario tunnel vision
  If you only run one case, you may miss how sensitive the results are to schedule or rate.
• Mixing frequencies (annual vs. monthly) without updating count/end date
  Ensure the payment frequency matches the number of payments (or your end date).
• Not documenting assumptions
  Without saving inputs, it’s hard to explain why Scenario A differs from Scenario B.

Try it

To run this in DocketMath now, start with the Structured Settlement calculator here: /tools/structured-settlement.

Quick checklist before you click “calculate”:

As you test runs, compare outputs such as:

• Payment stream schedule (does it match your intended calendar?)
• Total projected payments (nominal totals)
• Present value / discounted amount (rate-sensitive)
• Any tool breakdowns that explain when payments occur

Finally, when you include timing context in your notes, label it clearly as the general/default SOL baseline:

• **2 years under CCP § 335.1 (general/default SOL baseline)

Related reading

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