How to calculate Settlement Allocator in New York

Quick takeaways

• Settlement Allocator in New York (US-NY) is built around timing rules in CPLR Article 9 (§§ 901–909), which govern how you determine the default period for allocation calculations.
• You must supply the key dates (for example, claim period start/end) plus the total settlement amount to produce a numeric allocator output in DocketMath.
• This guide uses the general/default period because no claim-type-specific sub-rule was found in the available jurisdiction data for Article 9—so the logic below applies unless you identify a separate NY-specific rule for a particular claim type.
• Use DocketMath’s settlement-allocator tool to compute allocation factors consistently, then map those factors to each eligible period/damages component.
• Watch for date misalignment (calendar math errors) and missing event/anchor dates, which are common drivers of incorrect allocations.

Inputs you need

Before you run DocketMath → /tools/settlement-allocator, gather these inputs. Organize them per claimant (or per damages bucket if your workflow separates them).

Core numeric inputs

• Total settlement amount (NY_total_settlement)

  • Example: 1250000
• Allocator basis amounts (depending on your DocketMath configuration)

  • Common approach: allocate by time-based exposure or period-based weighting
• If DocketMath requires it in your setup:

  • Estimated total eligible days for the case-level period
  • Per-claimant eligible days within that case-level period

Key date inputs (Article 9 timing)

CPLR Article 9 (§§ 901–909) is period-driven. To apply the default period logic cleanly, collect:

• Claim period start date (claim_start)
• Claim period end date (claim_end)
• Relevant “event” or accrual anchor used to determine the applicable default period in your workflow

  • For example, if your internal process identifies an accrual date, that’s your anchor date.
• Any tolling or suspension dates you intend to reflect in your eligible period (if you’re modeling an extended default period)

Coverage/rules toggles in DocketMath (if available)

Depending on how DocketMath is configured for US-NY:

• Jurisdiction selection: ensure it is set to US-NY
• Allocation method selection (e.g., time-weighted vs. fixed-weighted)

  • If you choose time-weighted allocation, the eligible day counts become the primary drivers.

Quick checklist

• US-NY jurisdiction selected
• NY_total_settlement filled
• claim_start and claim_end collected
• Any accrual/anchor dates identified
• Per-claimant eligible day counts prepared (or the inputs DocketMath needs to compute them)

How the calculation works

DocketMath’s settlement-allocator converts your timing information into allocation factor(s), then multiplies those factors to determine each party’s share of the settlement. This is a mechanics overview—not legal advice.

1) Establish the “default period” using NY CPLR Article 9

New York’s CPLR Article 9 (§§ 901–909) provides the timing framework used for period-based allocation calculations. Under the jurisdiction data provided for this guide:

• No claim-type-specific sub-rule was found, so the calculation uses the general/default period from Article 9 (§§ 901–909).

In practice, this step determines:

• The eligible period window used for allocation.
• How to calculate eligible days (or time units) inside that window.

What this means for your inputs

Even if you already know the factual timeline (claim_start → claim_end), DocketMath needs the Article 9-driven period logic to determine:

• whether parts of that timeline fall inside the Article 9 default allocation window, and
• how much of each claimant’s timeline contributes to their eligible day count.

2) Compute per-claimant (or per-bucket) time weight

With the default period window set, DocketMath (or your input prep feeding it) computes a time weight for each claimant/bucket:

• eligible_days_i = number of days (or time units) of claimant i that fall within the default allocation window
• case_total_eligible_days = sum of eligible days across claimants/buckets (or the size of the default window, depending on your modeling setup)

Then:

• allocation_factor_i = eligible_days_i / case_total_eligible_days

If your dataset includes multiple damages buckets (for example, different conduct periods), run the allocation per bucket or structure inputs so DocketMath can aggregate by bucket.

3) Apply factors to the settlement amount

Once allocation factors are established, each share is:

• settlement_share_i = NY_total_settlement × allocation_factor_i

When DocketMath sums all shares, the outputs should reconcile to NY_total_settlement (subject to rounding rules).

4) Reconciling rounding and “sum-to-total” checks

Time-based calculations often create fractions. In your workflow:

• Prefer “round at the end” rather than rounding each intermediate step.
• Check reconciliation after export:

  • Sum of computed shares ≈ NY_total_settlement
  • Any rounding remainder should be distributed consistently (commonly to the largest factor or a designated final line item).

Tip: Early rounding can produce drift when many claimants have small eligible-day differences. If you see the sum not matching the total, review where rounding occurred.

Common pitfalls

1) Treating claim_start/claim_end as the entire allocator window

If you treat claim_start → claim_end as the entire allocator window, you may accidentally include days that fall outside the Article 9 default-period logic.

• Fix: Ensure DocketMath is fed the timing anchor(s) it expects for US-NY and verify the tool’s displayed/used default period window.

2) Confusing “event dates” with “eligible allocation dates”

Many settlement documents include event dates (notice, occurrence, filing). Allocation typically uses a period window derived from the Article 9 rules, so:

• event date ≠ allocation window in many workflows

• Fix: Confirm which dates/anchors drive DocketMath’s eligible-day math (not just narrative event timestamps).

3) Off-by-one day errors (inclusive vs. exclusive endpoints)

Time-weighted allocators are sensitive to whether you count:

• inclusive vs. exclusive endpoints,

• same-day intervals,

• leap years and month boundaries.

• Fix: Use a consistent day-count convention in your inputs. Test with a simple claimant whose timeline clearly covers full days.

4) Assuming claim-type-specific rules exist when they weren’t identified

This guide uses the general/default period because no claim-type-specific sub-rule was found in the provided jurisdiction data for CPLR Article 9 (§§ 901–909).

• Fix: If you later identify a claim category with a distinct NY allocation mechanism, re-run using the correct rule set and update your inputs.

5) Not verifying that outputs reconcile to the total

A settlement allocator should produce shares that sum to NY_total_settlement (after rounding adjustments).

• Fix: Do a sum-to-total check after exporting results from DocketMath and reconcile any rounding deltas explicitly.

Sources and references

• New York CPLR Article 9 (§§ 901–909) — period rules for allocation frameworks
  https://www.nysenate.gov/legislation/laws/CVP/A9

Next steps

1. Open DocketMath and go to /tools/settlement-allocator: https://docketmath.com/tools/settlement-allocator
2. Select US-NY jurisdiction settings.
3. Enter:

   • NY_total_settlement
   • claim_start and claim_end
   • the timing anchor(s) your workflow uses to apply CPLR Article 9 default period rules
4. Run the calculation and review:

   • the default period window used,
   • eligible day counts (or allocation factors),
   • each claimant/bucket settlement share.
5. Perform the reconciliation check:

   • verify that the sum of all shares matches NY_total_settlement after rounding.

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