How to run Settlement Allocator in DocketMath for California

How to run Settlement Allocator in DocketMath for California

6 min read

Published July 19, 2025 • Updated April 23, 2026 • By DocketMath Team

Article claim inventory in progress

Trust release 4

This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.

Step-by-step

Run this scenario in DocketMath using the Settlement Allocator calculator.

This guide walks you through running Settlement Allocator in DocketMath for California (US-CA). You’ll enter inputs that map to California’s default allocation timeline using jurisdiction-aware rules—then you’ll review the results and sanity-check them against the general statute of limitations framework.

Note: This post describes how to operate DocketMath’s calculator and interpret its outputs. It’s not legal advice, and it doesn’t replace attorney review for fact-specific issues (for example, claim type, accrual details, or tolling).

1) Open the correct tool

  1. Go to /tools/settlement-allocator.
  2. Confirm the calculator is set to California (US-CA).
    • If you see a jurisdiction selector, choose US-CA so the tool applies California-specific logic.

Quick tip: If you’re already working in another DocketMath tool, you can jump directly to Settlement Allocator via the inline link: /tools/settlement-allocator.

2) Enter settlement and timeline inputs

Settlement Allocator typically needs enough information to allocate settlement value across the relevant time window (commonly tied to a claims period). Provide the following kinds of inputs (exact labels can vary slightly by UI):

  • Settlement date (the date the settlement is reached or allocated)
  • Start date / accrual date (or the beginning of the analysis window)
  • Total settlement amount
  • Any allocation drivers DocketMath requests (for example, whether to base allocation on a selected period or on a provided range)

If DocketMath asks for a case timeline window, choose the one that matches your analysis:

  • For many workflow setups, you’ll provide an accident/event date and an end/settlement date.
  • If you’re not sure which date fields your situation should map to, run with your best estimate once, then adjust and compare outputs.

3) Use California’s default statute of limitations rule (general)

Settlement Allocator in DocketMath will use California’s general/default statute of limitations period when no claim-type-specific sub-rule is selected.

For California, the general framework is:

Important: The jurisdiction note you provided states:

  • No claim-type-specific sub-rule was found.
    So in this guide, the calculator should be treated as using the general/default 2-year period under CCP §335.1—not a specialized limitations period for a particular cause of action.

4) Run the allocator

  1. Click Calculate (or the equivalent button).
  2. Wait for DocketMath to compute the allocation.

While it runs, watch for:

  • Any warning banners about missing dates or ambiguous inputs
  • Any message indicating which limitation rule was applied (e.g., “using general/default period”)

5) Review outputs: totals, distribution, and implied time window

After calculation, focus on three output areas:

  • Allocated amount by time slice
    Look for a table or breakdown showing settlement value mapped to different periods. If DocketMath uses a time-phased approach, verify the slices line up with your dates.

  • Implied limitations window
    DocketMath should internally anchor the analysis to the 2-year general period under CCP §335.1. Confirm the displayed window (or the computed start/end boundaries) reflects 2 years.

  • Remaining/unallocated portion (if any)
    Some workflows surface an “outside limitations window” portion. If you see an amount excluded from the allocated portion, it will typically be tied to your input dates plus the default 2-year rule.

6) Adjust inputs and observe output changes

Settlement allocators are sensitive to date selection. Do at least one sensitivity check:

  • Move the start date forward or back (e.g., ±30 days) and re-run.
  • Keep settlement date and total amount fixed.
  • Compare:
    • The allocation totals within the time window
    • Any excluded portion
    • The distribution across slices

If the allocation distribution barely changes when you adjust dates slightly, the tool may be using a coarse allocation method; if it changes dramatically, date mapping is a major driver for your result.

Checklist to confirm the run used the intended rule

Common pitfalls

Below are the most frequent ways California Settlement Allocator runs go wrong when using the general/default limitations rule under CCP §335.1 (2 years).

Pitfall: Assuming a claim-specific statute of limitations when the calculator only applies the general/default 2-year period under CCP §335.1. Your inputs may look right, but the allocation window could be off if the underlying case theory would use a different limitations period.

1) Using the wrong default limitations assumption

Because no claim-type-specific sub-rule was found, the tool should treat the case as governed by the general/default period:

  • 2 years
  • CCP §335.1

If you intended a different limitations rule, you may need to adjust how you structure the analysis window rather than expecting DocketMath to apply a specialized period.

2) Swapping start and settlement dates

Date inversion is a classic input error:

  • Start date after settlement date can shift the analysis window into the wrong segment.
  • Even if the tool accepts the dates, the output allocation slices may not match your intended chronology.

3) Overlooking partial-window allocation behavior

Some allocators show:

  • allocated amounts within the window, and
  • excluded amounts outside it

If you expected everything to be allocated but see an excluded portion, your provided start date may push part of the period beyond the 2-year general window.

4) Forgetting to run a sanity-check scenario

A quick “what if” run helps you validate that outputs change logically:

  • If changing the start date doesn’t affect allocation at all, you may be entering a date field that the tool doesn’t use for the allocation window (or the UI labels are easy to misread).

5) Relying on outputs without inspecting the derived time window

Even with correct totals, allocations can be misleading if the tool’s derived limitations window doesn’t match what you thought the tool would use. Always inspect:

  • the derived start/end boundaries, and
  • the slice labels or time buckets.

Try it

Follow this mini test workflow to verify your setup before running on a full case dataset.

  1. Open /tools/settlement-allocator.
  2. Set jurisdiction to California (US-CA).
  3. Enter:
    • Total settlement amount (choose any round number for testing, like $50,000)
    • Start date (pick a date exactly 2 years before your planned settlement date)
    • Settlement date
  4. Run the calculator.

Expected behavior using the general/default limitations period:

  • Your analysis window should align with 2 years, reflecting CCP §335.1.
  • Your allocation breakdown should cover the intended time span you defined.

Now change one variable: 5. Adjust the start date forward by 30 days (keep settlement date and amount unchanged). 6. Re-run.

What to look for:

  • The allocation inside the window should shift (often decreasing the portion attributable to earlier periods, depending on DocketMath’s slicing logic).
  • If you see minimal change, confirm the tool is actually using the start date to define the allocation window.

Warning: When you test with dummy numbers, still verify the displayed derived time window. Allocation patterns matter more than dollar amounts during setup validation.

Related reading