How to calculate Settlement Allocator in Washington

Quick takeaways

• In Washington, settlement allocation is handled through the class-action framework in Wash. Super. Ct. Civ. R. 23 (CR 23)—the goal is an allocation that is fair, reasonable, and adequate for the class.
• In DocketMath, you calculate a Settlement Allocator by combining: (1) class-period relevance (eligibility within a selected window), (2) share metrics you input (your chosen quantitative basis), and (3) normalization so the allocations add up to the full settlement “pot.”
• For this Washington guide, DocketMath uses the general/default period approach described by CR 23. If no claim-type-specific sub-rule applies to your period, you should use the general default period rather than switching windows.
• Before relying on results, validate that the output allocations sum to the total settlement amount (within rounding rules). If they don’t, it usually indicates inconsistent inputs (e.g., eligibility flags, dates, or cap/floor configuration).

Inputs you need

Before you run the DocketMath Settlement Allocator tool for Washington (US-WA), collect the following inputs. These should be math-ready (numbers and explicit configuration), not narrative.

A. Settlement-level inputs

• Total settlement amount (number): the gross settlement you intend to allocate.
• Allocation basis selection (choice): confirm what you’re allocating by (examples: claim value proxy, “damages-days” factor, trading-during-period relevance factor).

  • Pick a basis you can apply consistently across claimants under CR 23’s class-action structure.
• Class size (count) (number, optional): useful for sanity checks (e.g., averages), but not required for the core proportional math.

B. Time-window inputs (Washington CR 23-driven default)

• Allocation period start date (YYYY-MM-DD)
• Allocation period end date (YYYY-MM-DD)
• Use the general/default period if your plan uses a single window for all class members.

Important: Your brief indicates no claim-type-specific sub-rule was found. That means you should not switch periods by claimant type unless your record clearly supports a different period beyond the CR 23 general framework.

C. Claimant-level inputs (one row per claimant)

For each claimant (or claimant group), you’ll need at least one numeric share driver, plus any gating or limits.

• Share metric (number): e.g., recognized losses, damages-days, or another proxy you’ve selected for relative share.
• Eligibility flag (checkbox): whether the claimant is included based on your allocation period and administrative inclusion criteria.
• Cap or floor (number, optional): if your process includes minimum/maximum allocation limits, enter them explicitly.

D. DocketMath execution constraints

• Rounding preference (e.g., 2 decimals)
• Do you allow unallocated residual? (yes/no)

  • If “yes,” specify where residual goes (commonly a reserve bucket defined by your administration plan).
  • If “no,” DocketMath should normalize so allocations match the total settlement exactly under the configured rounding approach.

How the calculation works

DocketMath’s Settlement Allocator follows a practical allocation flow: it computes weights and then converts those weights into proportional allocations that sum to the settlement total. In Washington, the “jurisdiction-aware” aspect is mainly about aligning your period/eligibility handling with the class-action framework in CR 23—using the general/default period unless you have a justified alternative.

Step 1: Filter for inclusion using the allocation period

1. For each claimant, translate facts into an Eligibility flag.
2. Claimants outside your selected allocation period (start/end dates) are excluded (effectively set to zero weight).

Because you’re using the general/default period approach, apply the same window logic across claimant categories unless you have a supported reason to do otherwise.

Step 2: Compute each claimant’s weight

DocketMath converts your Share metric into a weight.

A common logic pattern is:

• If eligibility = false → weight = 0
• If eligibility = true → weight = ShareMetric

  • (If you selected a modified basis, the weight may be ShareMetric * modifier—use one consistent basis.)

Key operational rule: keep the basis consistent. If you mix share metrics that are not commensurate (e.g., one claimant group uses “recognized losses” while another uses “damages-days”), you may create distortions even if normalization is mathematically correct.

Step 3: Normalize weights to match the settlement pot

Let:

• S = Total settlement amount
• W_total = sum of all claimant weights

Then each claimant allocation is:

• allocation_i = (weight_i / W_total) * S

This normalization step is what makes the allocator produce a full distribution of the settlement “pot.”

Step 4: Apply caps/floors (if you chose them)

If you add caps/floors, the allocator typically:

1. Applies the limit to eligible claimants, then
2. Re-distributes any remaining allocable amount among claimants not capped out (i.e., re-normalizes after limits so totals still reconcile).

Typical configuration choices:

• No caps/floors
• Apply floor only
• Apply cap only
• Apply both cap and floor

Step 5: Output validation (required)

After running the tool, confirm:

• Total reconciliation: sum(allocation_i) = Total settlement amount (within your configured rounding tolerance)
• Eligibility correctness: zero allocations for ineligible claimants
• Internal consistency: allocations move in the expected direction relative to your Share metric
• No unexplained dominance: a single claimant dominating allocation should have an explanation in the input metric, not an eligibility/date mismatch

Common pitfalls

Settlement allocation problems are usually input/configuration mismatches, not flaws in the proportional normalization concept. Here are the most frequent issues when running a Washington CR 23-aligned allocation.

1. Changing the time window without a supported basis

   • Your note states no claim-type-specific sub-rule was found. If you adjust windows by claim category, you may depart from the general/default period approach and end up with inconsistent eligibility logic.

2. Mixing allocation bases

   • Example: using “recognized losses” as the Share metric for one claimant group while using “damages-days” for another, but still treating them as if they measure the same type of relative share.
   • Fix: choose one allocation basis (or ensure any differences are explicitly supported and consistently applied with appropriate modifiers).

3. Eligibility flag mistakes

   • If you include out-of-period claimants in W_total (for instance, an eligibility checkbox accidentally left “on”), they will dilute everyone’s proportional allocation.

4. Residual handling and rounding

   • If rounding leaves cents unallocated, decide how residual is handled.
   • If “allow unallocated residual = yes,” make sure your plan specifies where residual goes. Otherwise totals and audit trails can become messy.

5. Cap/floor configuration errors

   • A common failure mode is applying a cap/floor and then manually trying to “patch” totals.
   • Fix: configure caps/floors in DocketMath and then rely on its re-normalization/validation rather than ad hoc adjustments.

Sources and references

• Wash. Super. Ct. Civ. R. 23 (Class actions) (general/default class-action framework)
  https://www.courts.wa.gov/court_rules/pdf/SUPCR/SUP_CR_23_00_00.pdf

General note (not legal advice): This guide is intended to be practical and informational about calculation structure and tool setup. Allocation approval and legal sufficiency depend on the specific facts and the court record.

Next steps

1. Open DocketMath’s Settlement Allocator tool: /tools/settlement-allocator
2. Enter your Total settlement amount (settlement pot) and choose your allocation basis.
3. Set the allocation period start/end dates using the general/default period approach (since no claim-type-specific sub-rule was found for period switching).
4. Enter claimant rows with:

   • Eligibility flag
   • Share metric
   • any cap/floor settings you intend to use
5. Run the tool and confirm validation checks:

   • allocations reconcile to the settlement total
   • ineligible claimants receive zero
   • rankings align with your Share metric logic
6. Export and archive:

   • the input configuration (dates, basis, rounding)
   • the claimant table
   • the output allocations (for auditability)

Related reading

• How to calculate Settlement Allocator in Ohio — Full how-to guide with jurisdiction-specific rules
• How to calculate Settlement Allocator in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Settlement Allocator in Philippines — Worked example with real statute citations