Inputs you need for Structured Settlement in California
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
Run this scenario in DocketMath using the Structured Settlement calculator.
To run a structured settlement workflow in DocketMath for California (US-CA), you’ll typically provide a small set of inputs that (1) support a timing/feasibility check and (2) let the tool model the settlement’s cash-flow profile.
Use this input-checklist before you click /tools/structured-settlement. This is not legal advice—it’s a practical data-gathering plan so you don’t get stuck after you’ve started the calculation.
Core facts (usually required)
Settlement mechanics (commonly required)
- If you’re modeling contingencies (for example, life-contingent structures), you’ll need the assumptions used in your proposal.
- Amount and timing (e.g., an “immediate” portion).
- This can help DocketMath match the intended cash-flow more closely.
Timing guardrails (CA-specific)
Because you asked for jurisdiction-aware rules, one key feasibility check many workflows use in California is the general/default statute of limitations period.
California’s general/default limitations period is 2 years under CCP § 335.1 (as provided in your jurisdiction data). Your notes also indicate:
No claim-type-specific sub-rule was found in the material you provided. So the workflow should use the general/default 2-year period rather than a specialized deadline for a specific claim theory.
Practical takeaway for your inputs:
Treat this timing check as a starting point based on the general 2-year period, not as a substitute for a claim-specific legal limitations analysis. In other words, it’s a model guardrail that depends on your dates.
Where to find each input
Use this “source map” to collect what DocketMath needs without reinventing your timeline.
Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.
Dates
- Incident / event date
- Often found in: complaint, police report summary, incident narrative, medical records intake, or the settlement demand narrative.
- Current date (or the date your settlement packet is prepared/delivered)
- Use today’s date, or the date you’re using to anchor the modeling session.
- Case / demand date
- Often found in: the top section of the demand letter, stipulation, or the filing date on court documents.
Amounts and payment schedule
- Total settlement amount
- Often found in: settlement agreement draft, demand offer, mediator’s term sheet, or the proposed settlement terms.
- Proposed payment timing, frequency, and term
- Often found in: the structured payout schedule or settlement structure proposal document.
- Immediate lump sum / periodic components
- Often found in: the settlement breakdown table (commonly included in a term sheet).
Assumptions (discount / interest)
- Rate / discount parameter
- Often found in: your structure proposal assumptions, an annuity quote discussion, or the modeling notes attached to the offer.
- If you don’t have a specific rate, you may still run scenarios, but you should treat the results as scenario-based rather than definitive.
Run it
- Open DocketMath → /tools/structured-settlement
- Enter the inputs, typically including:
- Total settlement amount
- Payment start date
- Frequency and term length (or end date)
- Any lump-sum component (amount and timing), if present
- Discount / interest assumption (if required by the tool)
- Incident date + current (or demand) date for the CA timing guardrail
- Confirm the CA timing mode is using the general/default period:
- 2 years under CCP § 335.1
- No claim-type-specific sub-rule is applied (per the jurisdiction notes you provided)
How outputs change based on your inputs
Here’s what usually shifts in the results when you change inputs:
| Input you change | Typical impact in the output |
|---|---|
| Higher total settlement amount | Generally increases modeled periodic payouts and/or lump-sum equivalents |
| Later payment start date | Can reduce the number of periods that fit the same end date (or change required periodic amounts depending on how the tool holds value constant) |
| Longer term length | Extends the payment stream and often reduces per-period amounts (if total modeled value is held steady) |
| Higher assumed discount/interest | Changes present value and the implied periodic amounts |
| Incident date more than 2 years before your modeling date | The timing guardrail may flag a potential limitations issue under CCP § 335.1 general/default |
| Different payment frequency | Alters the cash-flow shape (and may change present value outputs) |
Common mismatch checks (after you run)
If the modeled stream doesn’t line up with the structure proposal, it’s often one of these:
- incorrect payment start date
- incorrect term length / end date
- missing or mis-stated lump-sum component
- a discount/interest assumption that conflicts with the offer
Gentle disclaimer: These checks help you reconcile inputs and outputs. They are not a determination of legal rights or claim-specific limitations.