How to calculate Settlement Allocator in Arizona

Quick takeaways

• DocketMath’s Settlement Allocator translates a settlement into claim-specific shares so you can model how settlement money might be distributed among class members.
• In Arizona, you generally use Ariz. R. Civ. P. 23 as the governing class-action framework (including damages-class concepts like predominance and superiority)—but Rule 23 does not supply a claim-type-specific “settlement allocator math formula.” The allocator math you model should follow the settlement’s stated allocation method and the court’s Rule 23 approval process.
• To calculate an allocator, you’ll usually need three buckets of information: (1) class scope, (2) claimant-level eligibility/metrics, and (3) the settlement’s payment formula (proportional, tiered, time-based, capped, etc.).
• The output depends heavily on your inputs—especially class definition accuracy, how you treat missing values, and how the settlement weights categories (if it does).

Inputs you need

Before you start, gather the inputs that DocketMath will use to compute a Settlement Allocator for US-AZ (Arizona). Organize your data so each claimant/claim unit has consistent fields.

A. Class and settlement scope inputs

• Case caption / docket identifier (for project tracking inside DocketMath).
• Class definition summary (eligibility description used in the settlement).
• Settlement fund amount (cash component to be distributed).
• Any set-asides that affect distribution (e.g., administrative expenses modeled outside the claimant pool).
• Allocation method stated in the settlement (if present), such as:

  • proportional to documented loss
  • proportional to units purchased / transactions
  • time-based scaling (e.g., months in class period)
  • tiered weighting (e.g., categories with multipliers)

B. Claimant-level inputs (one row per claimant/claim unit)

• Eligibility flag (eligible vs. excluded).
• Claim metric (the number the settlement uses—loss amount, units, etc.).
• Claim metric cap/floor (if your settlement imposes them).
• Category/tier label (if weighting differs by category).
• Proof status (if the model distinguishes between “documented” vs. “estimated” amounts).

C. Allocation parameters

• Total of claim metrics in the class pool (if your formula is ratio-based).

  • If you don’t have it, DocketMath can compute totals once you load claimant-level metrics.
• Normalization rules (for example: only include eligible claimants; treat missing values as 0 vs. imputed estimates).
• Rounding rules (common for payment schedules).
• Residual handling approach (if your settlement includes a mechanism for leftover amounts due to rounding or caps).

D. Jurisdiction-aware rule check (Arizona Rule 23 context)

Use this checklist to ensure your model aligns with what courts look for at a high level under Ariz. R. Civ. P. 23:

• Numerosity, commonality, typicality, and adequacy are addressed for class certification under Ariz. R. Civ. P. 23.
• If there is a damages class, your settlement modeling respects the class framework concepts of predominance and superiority (as used under Rule 23’s damages analysis).
• Your distribution approach is consistent with the settlement terms presented for approval under Ariz. R. Civ. P. 23.
• You are not assuming a claim-type-specific allocation formula exists inside Rule 23 itself—none was identified in the provided rule source. This guide therefore models allocation as a function of the settlement’s stated method, not as a Rule 23-supplied formula.

How the calculation works

DocketMath’s Settlement Allocator uses a ratio/tier approach that typically follows the settlement’s payment logic. Since the settlement agreement determines the method, DocketMath primarily automates the arithmetic and enforces your modeling rules.

Step 1: Filter to the claimant pool

You define the denominator population:

• Eligible claimants included in the distribution
• Excluded claimants removed (or placed into a separate bucket if the settlement says so)

Practical effect: if you accidentally include ineligible metrics, the denominator grows and every claimant’s share shrinks.

Step 2: Compute adjusted claim value per claimant

For each claimant, DocketMath calculates an adjusted claim value using your formula inputs, usually one of these patterns:

Step 3: Sum adjusted values across the pool

DocketMath totals the adjusted values for the included claimant pool:

• total_adjusted = Σ adjusted_i

Practical effect: if you cap some claimants, the total decreases, which increases everyone else’s relative share unless the settlement reallocates capped amounts elsewhere.

Step 4: Allocate the settlement fund

If the settlement is a single cash distribution fund:

• allocated_i = settlement_fund × (adjusted_i / total_adjusted)

If the settlement uses multiple sub-pools (e.g., different categories with separate pot amounts), DocketMath allocates within each sub-pool:

• allocated_i(subpool) = subpool_fund × (adjusted_i / total_adjusted_subpool)

Step 5: Apply administrative rules and rounding

Finally:

• subtract/exclude modeled non-distribution items (if entered that way),
• round to your payment schedule rules.

Practical effect: rounding can create tiny residuals. DocketMath can model residual handling based on how you set it up (for example, distribute residuals proportionally or assign them to a specified bucket).

Arizona framing: what Ariz. R. Civ. P. 23 does—and does not—do

Ariz. R. Civ. P. 23 governs class actions and substantially mirrors Fed. R. Civ. P. 23. It requires (among other concepts) numerosity, commonality, typicality, and adequacy, and for damages class contexts it involves predominance and superiority.

However, Rule 23 is not a settlement-allocation math manual. It does not provide a universal, claim-type-specific formula for computing payout shares. So for Arizona allocator calculations, treat the settlement’s stated allocation method as the controlling driver of the allocator math—then use Rule 23 as the review lens for whether the class framework and treatment align with certification/approval requirements.

Source: Ariz. R. Civ. P. 23 (see “Sources and references”).

Common pitfalls

Use this checklist before you run the final allocator:

• Using the wrong denominator

  • Common cause: including ineligible claimants or excluding claimants the settlement includes.
• Ignoring tier multipliers

  • If your settlement uses categories, forgetting multipliers changes relative shares dramatically.
• Misapplying caps/floors

  • Caps can compress high-end claims; ensure the cap applies to the same metric the settlement uses.
• Mixing metric units

  • Example: using “dollars” in one row and “transactions” in another without normalizing to the settlement’s method.
• Treating missing data as zero when settlement requires estimation

  • If estimated claims are permitted, you need the estimation pathway encoded correctly.
• Double-counting set-asides

  • If you entered administrative fees as both a separate set-aside and a reduction of the distribution fund, you may under-allocate.
• Assuming a Rule 23 numeric allocation formula exists

  • Arizona’s Rule 23 governs class action requirements; this guide does not assume Rule 23 supplies a claim-type payout formula. The settlement controls the allocator math.
• Pooling when the settlement separates sub-pools

  • A settlement might allocate separate pots per category. Modeling them as one combined pool can produce correct totals but incorrect relative shares.

Sources and references

• Ariz. R. Civ. P. 23 (class actions; substantially mirrors Fed. R. Civ. P. 23)
  Source: https://govt.westlaw.com/azrules/Document/N3F4D3FC0F18211E198D6CFA72CFFFE45
  Key points used here: Rule 23 governs class actions and substantially mirrors Federal Rule 23, requiring numerosity, commonality, typicality, adequacy, and (for damages classes) predominance and superiority.
• No claim-type-specific sub-rule was identified in the provided rule text source. This guide therefore does not assume a unique settlement-allocation formula exists under Rule 23.

Next steps

1. Go to DocketMath → Settlement Allocator and label the project as US-AZ (Arizona).
2. Load claimant-level data with consistent fields (eligibility, metrics, tiers, caps/floors, and proof/estimation flags).
3. Encode the settlement allocation method you are modeling (proportional, tiered, capped, capped + tiered, or mixed documented/estimated).
4. Run