How to calculate Settlement Allocator in North Dakota

Quick takeaways

• North Dakota settlement allocations typically track comparative fault and any jurisdiction-aware statutory modifications that apply to your claim type; DocketMath uses North Dakota (US-ND) jurisdiction-aware defaults to produce a consistent allocator output.
• The allocated amounts change most when you adjust:

  • the percentage of fault by party,
  • whether noneconomic damages caps are enabled (when applicable to your selected scenario), and
  • whether settlement credit / release assumptions affect how the settlement is treated against damages.
• Use DocketMath’s Settlement Allocator for an auditable workflow: capture inputs → verify classifications → run the allocator → review the output line items.

Inputs you need

Before you run the Settlement Allocator in DocketMath, gather inputs that determine both the math and the jurisdiction-aware rules.

Use this intake checklist as your baseline for Settlement Allocator work in North Dakota.

• jurisdiction selection
• key dates and triggering events
• amounts or rates
• any caps or overrides

If any of these inputs are uncertain, document the assumption before you run the tool.

1) Parties and settlement amount

• Total settlement amount (e.g., $500,000)
• Settling parties (e.g., “Defendant A” and “Defendant B”)
• Non-settling parties (if you’re comparing allocation across defendants)

2) Fault allocation inputs (comparative fault)

You’ll need fault percentages that sum to 100% across relevant actors:

• Fault % for each defendant/party (e.g., A: 60%, B: 35%, plaintiff: 5%)
• Fault source basis (choose how you’re sourcing fault):

  • jury verdict / allocation,
  • agreed fault percentages,
  • mediation or modeling assumptions.

3) Damages buckets (to handle caps and allocators correctly)

Provide at least:

• Economic damages (past and/or future, if modeled)
• Noneconomic damages
• Total damages (if you have it already; otherwise DocketMath can total buckets)

If you don’t separate buckets, allocations can still work, but you lose precision where a statute treats noneconomic damages differently.

4) Applicable claim type and modifiers (jurisdiction-aware)

DocketMath needs claim-type switches to apply US-ND logic correctly, such as:

• Tort / personal injury vs. other civil claim
• Whether your model includes noneconomic damages caps (if applicable to the claim type you selected)
• Any limits on damages that your allocator must respect

5) Release / credit assumptions (so the allocator matches the scenario)

Even without going deep into legal strategy, the allocator math depends on:

• Whether you’re modeling:

  • settlement credit against overall damages, or
  • a standalone allocation among settling parties only.
• Whether there’s a single global settlement or separate settlements by party.

How the calculation works

DocketMath’s Settlement Allocator converts your inputs into an allocation matrix that ties together fault-based shares, damages mix, and US-ND jurisdiction rules.

DocketMath applies the North Dakota rule set to the inputs, then runs the calculation in ordered steps. It validates the trigger date, applies rate or cap logic, and produces a breakdown you can audit. If you change any one variable, the tool recalculates the downstream outputs immediately.

Step 1: Normalize fault into “share weights”

DocketMath first converts your fault percentages into weight factors.

• If fault percentages are provided as percentages, DocketMath:

  • validates that they sum to 100%
  • converts each to a share weight:

    • Weight_i = Fault_i / 100

Example (illustrative):

• Defendant A: 60% → Weight_A = 0.60
• Defendant B: 35% → Weight_B = 0.35
• Plaintiff: 5% → Weight_P = 0.05

If your inputs don’t sum to 100%, DocketMath will require you to correct or choose a normalization method so results don’t quietly drift.

Step 2: Decide the damage base that gets allocated

Next, DocketMath selects the “allocation base,” typically one of the following:

• Total damages (economic + noneconomic), or
• Capped noneconomic + uncapped economic, if your claim type activates noneconomic limitations.

This step determines the overall pool before fault shares are applied.

Practical example of how the pool changes:

• Suppose:

  • Economic damages = $200,000
  • Noneconomic damages = $400,000
  • Total modeled = $600,000
• If a cap applies to noneconomic damages in the configured scenario, DocketMath reduces the noneconomic bucket first, then recomputes the allocation base.

Step 3: Apply fault-based allocation to the damages pool

Once DocketMath has the allocation base, it applies fault weights to determine each defendant’s share.

For a standard damages allocation:

• AllocatedAmount_i = AllocationBase × Weight_i

Using the earlier weights and an allocation base of $600,000:

• A: $600,000 × 0.60 = $360,000
• B: $600,000 × 0.35 = $210,000
• (Plaintiff fault can affect recovery modeling depending on the allocator mode and configuration you choose.)

Step 4: Reconcile with the actual settlement amount

If your settlement amount is not equal to the full allocation base, DocketMath reconciles using the allocator mode you selected:

• If settlement is less than total damages: shares are scaled proportionally to the modeled allocation base.
• If settlement exceeds the damages pool: DocketMath flags this as a review item. Allocations can still be computed, but the scenario may reflect special assumptions (e.g., policy limits, structured settlement effects, or separate negotiations).

In audit terms, DocketMath produces:

• an allocation preview (pre-credit / pre-adjustment), and
• a final allocation line-item table aligned to the settlement amount you entered.

Step 5: Apply US-ND jurisdiction-aware rules

Finally, DocketMath applies US-ND jurisdiction logic based on your selections:

• noneconomic cap handling (when enabled by claim-type setup),
• comparative fault treatment consistent with North Dakota’s comparative fault framework,
• and settlement-credit assumptions consistent with the mode you selected.

A quick worksheet view (how outputs respond)

Common pitfalls

Here are the most common reasons allocator outputs come out “off” in US-ND workflows.

• Fault percentages don’t sum to 100%
  Even a 1–2% mismatch can materially change proportional allocations when dollars are large.
• Mixing damages buckets without caps configured
  If noneconomic cap logic is relevant to your scenario, but your allocator doesn’t have cap handling enabled, your allocation base can be too high.
• Using a “total settlement” but treating it like “total damages”
  If the settlement is a negotiated partial resolution, the allocator should scale shares to the settlement amount rather than treat settlement as the damages pool.
• Double-counting settlement credit assumptions
  If you model settlement credit in one way and then also apply a second offset in the damages setup, your results may effectively credit the settlement twice.
• Ignoring plaintiff fault in recovery modeling mode
  Depending on whether you’re modeling “allocation of recovery” vs. “allocation of settlement proceeds,” plaintiff fault can affect the recoverable base or only appear as a reduction factor.

Sources and references

North Dakota settlement allocation math generally relies on comparative fault principles and, when applicable to the claim type selected, statutory treatment of damage categories (including noneconomic limitations, where enabled in the model). This guide focuses on a calculation workflow and DocketMath setup rather than providing legal advice.

For North Dakota legal background (use for your own verification):

• North Dakota comparative fault framework: N.D. Cent. Code § 32-03.2-02
• North Dakota general civil damages concepts (compare fault and damages-related statutes): N.D. Cent. Code § 32-03.2-01 through § 32-03.2-05 (review the full comparative fault chapter as needed)

Next steps

1. Open DocketMath Settlement Allocator
   Start here for the calculator flow: /tools/settlement-allocator
2. Enter fault percentages first
   Make sure they sum to 100% and match your chosen source (verdict, stipulation, or modeled assumption).
3. Build the damages buckets
   Economic and noneconomic totals should reconcile with your total damages figure.
4. Choose the claim-type modifiers
   Enable any US-ND-specific toggles that affect the allocation base (e.g., noneconomic cap handling in the configured scenario).
5. Run and review allocator line-items
   Validate:

   • allocation base,
   • scaled settlement amounts,
   • and any reconciliation notes.

If you want to cross-check inputs before allocating, you can also use DocketMath tools like /tools/compare-fault (when available in your workspace) to validate fault assumptions prior to settlement allocation.

Related reading

• Settlement Allocator Guide for Alabama
• Settlement Allocator Guide for Arizona
• Settlement Allocator Guide for Colorado