Abstract background illustration for How to calculate Settlement Allocator in Arkansas

How to calculate Settlement Allocator in Arkansas

7 min read

Published June 4, 2026 • By DocketMath Team

Partially verified

older_than_packet

Quick takeaways

  • In Arkansas class actions, the Settlement Allocator is typically tied to the class notice/plan and the court’s approval workflow under Ark. R. Civ. P. 23—the rule governs the class-action framework, not a single universal “allocator formula.”
  • Use DocketMath’s Settlement Allocator calculator to apply your plan’s logic consistently across claimants, but anchor your inputs to the approved allocation method (and any approved claims/eligibility process).
  • For Arkansas, Ark. R. Civ. P. 23 is the governing starting point for class action procedures; no claim-type-specific allocator sub-rule was found in the provided materials—so you should rely on the general/default approach and the specific settlement allocation plan your case uses.
  • Your result should be auditable: every dollar in the allocator should trace back to an input (e.g., units, damages factor, time-on-class, or other weighting used in the plan).

Note: This guide explains how to calculate and run a Settlement Allocator in Arkansas using DocketMath. It does not provide legal advice, and the “right” allocator formula is ultimately the one described in your settlement agreement and approved under Ark. R. Civ. P. 23.

Inputs you need

Before you touch the calculator, gather the numbers and identifiers your allocator model requires. DocketMath works best when you can map each input to a single claimant-level value and a single class-level pool value.

A. Settlement economics (class-level)

Use these at the top of your model:

  • Total settlement fund to allocate (e.g., $S_total)
  • Amounts excluded from claimant allocation (e.g., attorneys’ fees, costs, administration expenses, incentive awards), if the allocator plan specifies exclusions
    • You’ll typically allocate: S_alloc = S_total − exclusions
  • Allocation method identifier (or formula ID) from the approved plan, so you apply the same logic consistently

B. Claimant-level data

Depending on your approved plan, common claimant-level inputs include:

  • Claimant “units” (e.g., number of qualifying transactions, number of qualifying units, or other counted events)
  • Time-in-class (e.g., days of eligibility), if the plan uses time-based weighting
  • Damages factor (e.g., a per-unit loss model outcome, or a standardized score)
  • Class-period eligibility flags (e.g., “qualifies under the plan”)
  • Evidence adjustments (if your plan uses confirmed vs. estimated amounts)

C. Proration / caps / floors (plan-level)

If your plan has guardrails, you’ll need those parameters:

  • Minimum claim threshold (e.g., claims below a certain value are aggregated or treated differently)
  • Maximum payout cap per claimant
  • Pro-rata scaling rule (e.g., “Payout = (Claimant share / Total eligible share) × allocable fund”)
  • Treatment of disputed or incomplete claims (e.g., holdbacks, later reconciliation, or secondary calculations)

D. Arkansas class-action context (rule anchor)

Arkansas class action procedure is governed by Ark. R. Civ. P. 23, including court oversight of class certification and notice mechanisms relevant to settlements.

Relevant source (Arkansas Rule 23):
Ark. R. Civ. P. 23 (Class Actions)https://courts.arkansas.gov/rules-and-administrative-orders/court-rules/arkansas-rules-civil-procedure/rule-23-class-actions

Clear limitation for this guide: In the materials provided, no claim-type-specific allocator sub-rule was found. Practically, that means your allocator should follow the approved settlement allocation plan using the general/default Rule 23 class-action workflow, rather than inventing separate allocator logic by claim category.

How the calculation works

DocketMath’s Settlement Allocator implements a structured workflow: it takes a claimant-level “allocation score,” sums eligible scores across the class, then converts scores into payout amounts from the allocable settlement fund—optionally applying plan-specific caps/floors and reconciliation logic.

Use DocketMath here: /tools/settlement-allocator

Step 1: Determine the allocable pool

Compute the fund available for claimant allocations:

  • Allocable settlement fund:
    • S_alloc = S_total − exclusions

If your settlement plan treats the entire fund as allocable (less common where fees/costs are excluded), set exclusions to 0.

Step 2: Compute each claimant’s allocation score

Most allocator designs build an allocation score from one or more claimant inputs. Examples include:

  • Units-based: Score_i = Units_i
  • Time-weighted: Score_i = TimeInClass_i × RateFactor_i
  • Damages-factor: Score_i = DamagesFactor_i
  • Multi-factor weighting: Score_i = (Units_i × TimeInClass_i) × Weight_i

In DocketMath, the key is straightforward: your inputs and score structure should match the approved settlement allocation plan. In Arkansas, Ark. R. Civ. P. 23 supplies the class-action procedure context and court oversight, but the allocator math comes from the plan the court approved.

Step 3: Apply eligibility and screening rules

If your plan excludes some claimants (e.g., out-of-class, missing eligibility proof, or failing a threshold), handle them explicitly:

  • Ineligible: set Score_i = 0 and ensure they are not included in the denominator logic (i.e., the eligible TotalScore).
  • Disputed/incomplete: follow the plan’s treatment (e.g., holdback pool, secondary calculation, or later reconciliation).

This is where many allocator spreadsheets drift—ensure the same eligibility filter is applied to:

  • the score calculation, and
  • the eligible denominator.

Step 4: Sum total eligible scores

Compute:

  • TotalScore = Σ Score_i across eligible claimants

This becomes the denominator that translates “relative score” into “relative share of the allocable pool.”

Step 5: Convert scores into payout amounts

For each claimant:

  • Payout_i = (Score_i / TotalScore) × S_alloc

If the plan includes caps/floors, apply them per the plan’s order of operations, for example:

  • Cap: Payout_i = min(Payout_i, Cap_i)
  • Floor: Payout_i = max(Payout_i, Floor_i)
  • Redistribution rule (if required): if capped payments reduce totals, the freed amount must be handled according to the plan (e.g., redistribute proportionally among uncapped eligible claimants, allocate to a holdback, or follow another documented method).

DocketMath can be used to implement this consistently, but you need to supply the redistribution/capping logic that your approved plan specifies.

Step 6: Run DocketMath and review outputs

Run /tools/settlement-allocator with your dataset and parameters. Review:

  • Per-claimant results (typically):
    • Score_i
    • Payout_i
    • any applied adjustments (caps/floors/holds)
  • Totals:
    • Σ Payout_i should reconcile to S_alloc (or to the plan’s documented rounding/holdback approach)

Warning: If the payouts don’t reconcile, it’s often due to:

  • claimants included in the denominator but not the payout list,
  • inconsistent eligibility filtering,
  • rounding not handled per the plan’s documented approach.

Common pitfalls

These issues show up frequently when teams calculate allocators under a Rule 23-governed settlement workflow in Arkansas.

  1. Using a generic formula not tied to the approved allocation plan

    • Ark. R. Civ. P. 23 provides the class-action procedure framework, but the allocator math should be the one described in the approved settlement allocation plan—not a “best guess” that changes midstream.
  2. Including ineligible claimants in the denominator

    • If the plan has eligibility rules (class period, qualifying transactions, proof requirements), apply them consistently to:
      • the score inputs, and
      • the eligible denominator (TotalScore).
  3. Forgetting exclusions from the allocable pool

    • If the plan excludes fees, costs, or administration, distributing the full settlement amount will inflate payouts and break reconciliation:
      • S_alloc should reflect S_total − exclusions.
  4. Applying caps/floors without a redistribution rule

    • If some claimants are capped, you need a documented method for what happens to the excess:
      • redistribute proportionally,
      • distribute to remaining eligible claimants,
      • place into a holdback pool,
      • or follow another plan-specified mechanism.
  5. Assuming there are claim-type-specific allocator sub-rules (when none were provided)

    • In the materials provided, no claim-type-specific allocator sub-rule was found. Don’t invent separate Arkansas allocator logic by claim category; instead, follow the plan’s single described allocation method under the Rule 23 workflow.
  6. Rounding differences that prevent reconciliation

    • Rounding should follow a documented approach (e.g., round to cents, then adjust residuals per the plan—such as assigning the residual to an admin line item or last claimant).
    • Use DocketMath output reconciliation as an early check.

Sources and references

Next steps

  1. Confirm your settlement allocation plan terms

    • Identify the exact score structure (units, time, damages factor), and any thresholds, caps/floors, and redistribution logic.
  2. Build your claimant dataset

    • For each claimant, capture:
      • eligibility status (and reason, if relevant),
      • the inputs used by the plan,
      • any cap/floor parameters required.
  3. **Enter data into