How to run Damages Allocation in DocketMath for Oklahoma
6 min read
Published April 15, 2026 • By DocketMath Team
Step-by-step
This walkthrough shows how to run Damages Allocation in DocketMath for Oklahoma (US-OK) using jurisdiction-aware rules. It also explains how Oklahoma’s statute of limitations (SOL) period affects what you should include in your damages allocation window—without providing legal advice.
Note: Oklahoma’s SOL rule applied here is a general/default period. No claim-type-specific sub-rule was identified in the provided jurisdiction data, so the calculator uses the default rule rather than a specialized one for particular causes of action.
1) Open the Damages Allocation calculator
- Go to Damages Allocation.
- Confirm the calculator is set to Oklahoma (US-OK). If you see a jurisdiction selector, choose US-OK.
2) Enter the core case facts DocketMath needs
Most damage-allocation workflows require at least:
- Start date of the damages period (e.g., first date of measurable harm)
- End date (often the filing date, cutoff date, or another chosen date)
- Amount basis (the total alleged damages or a damage component)
- Allocation method (how you want DocketMath to distribute amounts over time)
In DocketMath, enter those fields in the calculator UI and keep your dates consistent—especially if you’re entering multiple damage components or running separate allocations.
3) Apply Oklahoma’s SOL window in the calculator
For Oklahoma, the jurisdiction data provided lists:
- General SOL period: 1 years
- General statute cited: 22 O.S. §152
When you run the tool, look for the SOL or “time-bar”/“lookback window” control. If DocketMath supports it, set the SOL logic to use the general/default period of 1 year under 22 O.S. §152.
What this means in practice:
- DocketMath will allocate damages only within the allowed lookback window (i.e., portions outside the SOL period may be excluded or flagged depending on the calculator’s design).
- Your end date is typically what anchors the window (commonly tied to filing or another selected cutoff). If you choose a later end date, the lookback window shifts accordingly.
Warning: If you input an end date that is later than the real filing/cutoff date you intend to analyze, DocketMath may include damage periods you’d otherwise want excluded.
4) Choose allocation settings (and watch output change)
After SOL windowing, your allocation method determines how the remaining damages are spread.
Common approaches you may see in the UI:
- Proportional by time (allocate based on the number of days in each sub-period)
- Front-loaded / back-loaded distributions (if supported)
- Component-based allocation (if the tool lets you split damages into categories)
Key “input → output” relationships to confirm:
- Changing the start date: affects how much time falls inside the 1-year SOL window, which changes the allocated totals.
- Changing the allocation method: keeps the same included timeframe but redistributes amounts across sub-periods.
- Splitting damages into components: can change totals if SOL filtering is applied before versus after splitting (so the order of operations matters).
5) Review the results panel
Once you generate the allocation, review:
- Included vs excluded periods (or an equivalent breakdown)
- Total allocated damages within the SOL-filtered window
- Any time-sliced table showing amounts by period/date range
- Any notes or warnings DocketMath provides about the SOL logic
A quick checklist:
6) Export or document the output for case workflow
If DocketMath includes export options, save:
- The allocation table
- The assumptions (start/end dates, allocation method, jurisdiction rule)
- Any SOL-related flags or exclusions
This makes it easier to revisit the run later (for example, if you revise the cutoff date or adjust the damages period).
Common pitfalls
Running Damages Allocation smoothly in Oklahoma usually comes down to a few repeat issues. Here are the ones most likely to distort the output.
- missing a required input
- using a stale rate or rule
- ignoring calendar or holiday adjustments
- skipping documentation of assumptions
Incorrect or inconsistent date anchoring
- Symptom: “Included” period doesn’t align with your filing/cutoff logic.
- Cause: End date used in the tool doesn’t match the date you intend to anchor the SOL lookback.
- Fix: Re-check the end date you entered and confirm the calculator’s anchoring behavior.
Assuming a claim-type-specific SOL rule is applied
Because the provided jurisdiction data only identifies a general/default period and does not list claim-type-specific sub-rules, DocketMath should apply the default SOL rule rather than a specialized one.
Note: This guide uses the general SOL period of 1 year tied to 22 O.S. §152. If you later identify a specific claim type with a different SOL in your internal workflow, you’ll want to adjust your modeling approach rather than relying on this default.
Mixing damage components that belong in different timeframes
- Symptom: Some components appear fully excluded while others are partially included, even though they should overlap.
- Cause: Components were entered as one combined amount with one shared timeframe when the underlying facts differ.
- Fix: Split components into separate calculator runs (or separate component inputs, if supported).
Date format errors (quietly harmful)
- Symptom: A 1-year window looks too short or too long.
- Cause: Day/month or month/day ambiguity in manual entry.
- Fix: Use an unambiguous date format where possible (e.g., YYYY-MM-DD) and verify the displayed parsed dates.
Misreading the output when SOL exclusions are applied
- Symptom: You assume output totals equal the “amount basis.”
- Cause: The calculator may filter out periods outside the SOL window.
- Fix: Compare amount basis vs allocated total and confirm the difference is explained by SOL exclusion.
Try it
If you want to validate your setup quickly, do a controlled run and change only one input at a time.
- Open Damages Allocation.
- Set jurisdiction to US-OK.
- Enter a date range that is clearly longer than 1 year (for example, 18 months).
- Use a simple allocation method (time-proportional, if available).
- Generate results and confirm:
- DocketMath includes approximately 12 months (the SOL window) and excludes the rest.
- Now change only the end date by 30 days:
- Expected effect: the included window shifts, so allocated totals by sub-period should update.
For a quick verification step, also try a “tight window” test:
- Use a start/end range that is just under 1 year.
- Expected effect: SOL exclusions should be minimal or none, so allocated totals should closely match the amount basis (subject to rounding and method).
Pitfall: Don’t compare two runs where you changed both the start date and the allocation method—those changes can mask each other and make it hard to see whether SOL filtering is working.
