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:
| Component | Amount (Base) |
|---|---|
| Medical bills | 18,000 |
| Lost wages | 22,000 |
| Pain & suffering (estimate) | 30,000 |
| Interest | 2,000 |
| Costs & fees | 13,000 |
| Subtotal | 85,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.
| Component | Allocated Amount |
|---|---|
| Medical bills | 18,000 |
| Lost wages | 22,000 |
| Pain & suffering | 30,000 |
| Interest | 2,000 |
| Costs & fees | 13,000 |
| Total | 85,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:
