Settlement Allocator Guide for Oklahoma

8 min read

Published March 22, 2026 • By DocketMath Team

What this calculator does

DocketMath’s Settlement Allocator is designed to help you split a single settlement amount into components that can later be used for documentation, reporting, or internal case math workflows. The calculator focuses on allocating proceeds across categories you define—commonly:

  • Compensatory damages (e.g., pain and suffering, medical costs, lost wages)
  • Economic damages (e.g., measurable out-of-pocket costs)
  • Non-economic damages (e.g., general/pain and suffering)
  • Interest (if you track it separately)
  • Costs and fees (if your agreement or case file tracks them separately)

Because settlement paperwork often needs consistent internal accounting, the allocator can also help you produce a clean “audit trail” of how totals were derived—especially when you have multiple figures (damages, interest, liens, or agreed allocations).

Oklahoma timing note (why the “allocation” workflow matters)

Even though an allocator doesn’t itself decide claims or liability, it’s commonly used alongside a statute-of-limitations (SOL) workflow. For Oklahoma, criminal SOL references appear in 22 O.S. § 152 with a 1-year period, plus a specific 2-year exception listed as 22 O.S. § 152(H) in your jurisdiction data.

  • 22 O.S. § 152: 1 year (exception noted as P1 in your data)
  • Okla. Stat. tit. 22, § 152(H): 2 years (exception noted as V1 in your data)

Source used for the SOL summary: https://www.findlaw.com/state/oklahoma-law/oklahoma-criminal-statute-of-limitations-laws.html

Note: Settlement allocation and SOL analysis are related in practice because documents created during settlement (and the dates embedded in them) can later be cross-referenced in motions, briefs, or compliance reviews. The allocator helps organize amounts; it does not determine which claims are valid.

When to use it

Use DocketMath’s Settlement Allocator when you have a settlement number and need to break it into line items for a record that will stand up to review. Typical trigger points include:

  • You received or are negotiating a lump-sum settlement (e.g., one wire amount or one check).
  • Your settlement agreement references multiple damage categories even though payment is one total.
  • You’re reconciling separate calculations (medical total, wage-loss total, non-economic estimates) into a single payment.
  • Your case file includes prior figures (e.g., estimates) but the settlement is finalized at a different amount.
  • You need to show a straightforward math method for how the final allocation was produced.

Oklahoma-specific workflow timing

If your case touches time-based rules—especially if criminal timing is involved—Oklahoma’s 22 O.S. § 152 framework shows a general 1-year SOL with a 2-year exception under 22 O.S. § 152(H) (per your provided jurisdiction sub-rules P1 and V1).

That means your internal recordkeeping often benefits from:

  • A clear event date (e.g., date of incident)
  • A clear document date (e.g., settlement agreement signature date)
  • A consistent method to map settlement dollars to categories

Pitfall: People often allocate settlement money without recording the category basis (e.g., “we estimated X for medical and Y for non-economic”). If you later need to justify the split, missing category documentation can force re-work under pressure.

Direct link to the tool

Start here: **DocketMath Settlement Allocator

Step-by-step example

Below is a practical walkthrough using DocketMath’s Settlement Allocator in a way that matches how many settlement teams build allocation records.

Scenario

You settle a matter for $85,000. The agreement (or your internal calculation memo) breaks it into:

  • Medical bills: $18,000
  • Lost wages: $22,000
  • Pain and suffering (non-economic estimate): $30,000
  • Interest: $2,000
  • Costs and fees: $13,000

The subtotal of the listed components is:

ComponentAmount (Base)
Medical bills18,000
Lost wages22,000
Pain & suffering (estimate)30,000
Interest2,000
Costs & fees13,000
Subtotal85,000

In this example, the base totals already equal the settlement amount ($85,000), so the allocation is 1:1. Now let’s also show what happens when the settlement differs from the base estimates.

Step 1: Enter the settlement total

In the tool:

  • Settlement total: 85,000

When the settlement amount changes, every allocated category output will change accordingly—especially if your inputs represent a base allocation that needs proportional scaling.

Step 2: Enter category bases

Add each category with its “base” amount.

Example entries:

  • Medical bills: 18,000
  • Lost wages: 22,000
  • Pain & suffering: 30,000
  • Interest: 2,000
  • Costs and fees: 13,000

Because the bases sum to the settlement total, the output allocation typically mirrors these values.

Step 3: Review computed outputs

Your expected output should show allocation amounts that sum to the settlement total.

ComponentAllocated Amount
Medical bills18,000
Lost wages22,000
Pain & suffering30,000
Interest2,000
Costs & fees13,000
Total85,000

If the tool uses proportional scaling, it will still match totals—just through math rather than a direct 1:1 pass-through.

Step 4: Run a “settlement differs from bases” variant

Now assume the settlement is $80,000 instead of $85,000, while the category bases stay the same.

  • Base subtotal = $85,000
  • Settlement total = $80,000
  • Scaling factor = $80,000 ÷ $85,000 ≈ 0.941176

Allocated medical bills ≈ 18,000 × 0.941176 = $16,941.18
Allocated lost wages ≈ 22,000 × 0.941176 = $20,705.88
…and so on.

The calculator’s value is that it automates the proportional math and keeps the total cleanly reconciled.

Note: If your settlement agreement specifies exact allocations rather than a proportional split, enter the category bases as fixed final allocations (or adjust so the categories already sum to the settlement total). Otherwise, proportional allocation may produce numbers that conflict with the contract language.

Common scenarios

Settlement allocation issues usually fall into a few repeat patterns. Here are the most common ones you’ll see when using DocketMath’s Settlement Allocator.

1) Lump-sum payment with category estimates

Problem: You have reasonable estimates, but the payer issues one check.
Use the allocator to: convert category estimates into a proportional allocation so the totals reconcile to the lump sum.

Checklist:

2) Settlement includes interest but agreement doesn’t explain it

Problem: Payment includes an interest component, but you’re not sure whether to treat it as damages or separate.
Use the allocator to: isolate the interest line item if you track it, so your allocation output reflects your internal reporting approach.

Reminder: The tool allocates dollars you provide; it does not decide legal characterization.

3) Medical and wage totals are revised close to settlement

Problem: Last-minute receipts and payroll records change amounts.
Use the allocator to: rerun allocations quickly with updated category bases—while keeping the settlement total fixed.

Practical approach:

  • Enter updated medical and wage totals as new bases
  • Keep non-economic estimate consistent unless you intentionally revise it
  • Confirm the tool output sums to the settlement total

4) Multiple settlements over time

Problem: One client/account has multiple settlement events.
Use the allocator to: standardize each allocation record and keep categories aligned across agreements.

Simple workflow:

  • Allocate Settlement A and export/save the output
  • Repeat for Settlement B using the same category labels (medical, wages, non-economic, interest, costs/fees)
  • Compare outputs across time

5) Time-based issues tracked alongside settlement documentation (Oklahoma)

If your matter involves criminal SOL timing references (or related time-sensitive issues in your file), keep Oklahoma’s SOL framework handy as a recordkeeping anchor:

  • 1-year SOL general rule: 22 O.S. § 152
  • 2-year SOL exception: 22 O.S. § 152(H) (listed in your sub-rules as exception V1)

Your settlement allocator won’t compute SOL dates, but your file often needs both:

  • When the event occurred
  • When the agreement was signed
  • How the settlement was allocated

Warning: If your settlement packet includes time-sensitive references, double-check that the document you’re relying on (e.g., incident date vs. filing date vs. agreement date) is the same date you used elsewhere in your SOL or case timeline notes.

Tips for accuracy

Accuracy in allocation is mostly about disciplined inputs and output review. Use these best practices to reduce mistakes.

Lock down the category labels

  • Use the same category names across runs (e.g., “Lost wages” vs. “Wages”).
  • Keep “non-economic” clearly labeled so it doesn’t get mixed into “damages” generically.
  • If your documentation separates interest or costs, mirror that separation.

Make sure totals reconcile

After running the tool:

Related reading