How to run Settlement Allocator in DocketMath for Oklahoma
6 min read
Published June 23, 2025 • Updated April 23, 2026 • By DocketMath Team
Trust release 4
This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.
Step-by-step
Run this scenario in DocketMath using the Settlement Allocator calculator.
Follow these steps to run Settlement Allocator in DocketMath for Oklahoma (US-OK). This walkthrough is designed to help you allocate settlement amounts across parties and/or claims while using jurisdiction-aware timing logic, with the default statute of limitations (SOL) rule as the baseline.
Note: Oklahoma’s general/default SOL period used here is 1 year, based on 22 O.S. § 152. No claim-type-specific sub-rule was identified for this automation, so do not treat 1 year as universal for every possible Oklahoma claim category.
1) Open the Settlement Allocator tool
- Go to the primary CTA: /tools/settlement-allocator
- Select jurisdiction: US-OK (Oklahoma).
- Confirm the tool is using the Oklahoma default SOL baseline:
- General SOL period: 1 year
- General Statute: 22 O.S. § 152
2) Enter settlement inputs
DocketMath’s Settlement Allocator generally needs information that affects both allocation and timing assumptions. Use inputs that match how your settlement agreement (or internal allocation memo) is structured.
Common inputs include:
- Settlement total (e.g., $50,000)
- Allocation buckets (e.g., medical expenses, wage loss, non-economic damages, attorney’s fees—whatever your agreement uses)
- Parties / payees (e.g., claimant, spouse, minor beneficiary, or separate pay lines)
- Relevant dates used for timing evaluation:
- Incident date (or accrual date, if your documentation uses that term)
- Filing date (if relevant to the SOL calculation your workflow uses)
- Settlement date (useful for reporting outputs, depending on how the tool is configured)
If your agreement or your case materials distinguish between incident and accrual, enter the date that best matches your underlying facts and terminology. The key is consistency across runs: use the same “trigger date” concept each time you recalculate.
3) Ensure the “1-year” Oklahoma SOL rule is applied as the default
Before calculating, verify the jurisdiction rule summary in DocketMath reflects:
- 22 O.S. § 152
- General SOL period: 1 year
- No additional claim-type-specific SOL applied (because none was identified for this automation)
This verification matters because the allocator may display time-bar risk indicators or influence timing-related annotations that depend on which SOL rule set is selected.
4) Run the calculator
Click Calculate / Run, then review the summary and results.
Look for a summary panel that includes:
- Oklahoma rule reference (e.g., 22 O.S. § 152, 1 year)
- The dates you provided
- Any derived evaluation such as within SOL / outside SOL
If the tool provides toggles like “apply SOL logic” or “use default SOL,” ensure the option matches your intent. For this Oklahoma setup, your baseline reference is the general/default 1-year period.
5) Review outputs bucket-by-bucket
Review results in three layers:
Numeric allocation results
- Confirm each bucket’s dollar amount
- Confirm the bucket totals reconcile to the settlement total (including any rounding behavior the tool uses)
Timing / eligibility indicators
- Identify whether the tool treats the scenario as within or outside the 1-year default SOL baseline
- Note any “risk” flags or timing annotations (if displayed)
Explanatory notes and rule grounding
- Look for language stating the period is the general/default 1-year rule under 22 O.S. § 152
- Since no claim-type-specific Oklahoma sub-rule was found for this automation, treat outputs as grounded in the default rule you selected, not as confirmation that every underlying claim type is timely.
Gentle disclaimer: This guidance is for using the tool and interpreting its outputs. It is not legal advice, and it cannot confirm legal timeliness for every claim category.
6) Iterate with corrected dates (not just numbers)
If outputs look inconsistent with your expectations:
- Re-check the incident/accrual date—confirm that it matches your case trigger date concept.
- Re-check the filing date—confirm it is the date litigation was initiated (or the date relevant to your internal SOL framework).
Then re-run the calculator. In many settlement allocation workflows, a small date change can shift the scenario from within to outside the 1-year default baseline, which can alter timing flags and related annotations.
Common pitfalls
Here are common issues when running Settlement Allocator for Oklahoma (US-OK) using the default 1-year SOL under 22 O.S. § 152:
- Using the wrong date field
- Example: entering a negotiation start date where an incident/accrual date is expected.
- Assuming the 1-year default applies to every Oklahoma claim type
- This guide uses general/default logic from 22 O.S. § 152. No claim-type-specific sub-rule was identified for this automation, so don’t treat 1 year as universal.
- Mismatch between bucket structure and your agreement
- If the tool expects, say, 3 buckets but your agreement uses 5, the output may not map cleanly to the agreed categories.
- Not reconciling totals
- Always confirm allocations sum to the settlement total (and understand rounding).
- Not updating inputs after changing settlement language
- If your settlement agreement changes terminology (e.g., “wage loss” vs. “lost earning capacity”), update labels and bucket mapping so the allocator output matches the final document.
Quick checklist before you click Calculate:
Warning: If your case involves a potential claim category that has a different SOL than the general/default 1-year baseline used here, relying on the default rule can produce misleading timing flags. Use the allocator as an assistance tool tied to the selected rule set—not as a definitive legal timeliness determination.
Try it
- Open DocketMath’s Settlement Allocator: /tools/settlement-allocator
- Choose US-OK as the jurisdiction.
- Enter:
- A settlement total (any test value is fine for learning)
- 2–3 allocation buckets
- An incident/accrual date and filing date (or the dates your workflow uses)
- Run the tool and review:
- Whether it treats the scenario as within or outside the 1-year default SOL
- The resulting bucket allocations and any timing annotations
If you want to sanity-check the date logic, do a quick two-run test:
- Run A: incident/accrual date set so the timeline is just under 1 year
- Run B: shift the incident/accrual date so the timeline is just over 1 year
- Compare outputs to see how the allocator reacts to the 1-year baseline under 22 O.S. § 152
