How to run Settlement Allocator in DocketMath for Oklahoma

Step-by-step

This guide walks you through running Settlement Allocator in DocketMath for Oklahoma (US-OK). The goal is to help you map one settlement amount to multiple claim components using jurisdiction-aware timing rules—without turning this into legal advice.

DocketMath’s Settlement Allocator uses a default time period for Oklahoma based on the general statute below. No claim-type-specific sub-rule was found, so the same default period is applied across the board (i.e., you won’t see different periods by claim category inside this calculator).

Statutory timing basis (Oklahoma):

• Okla. Stat. tit. 12, § 2023 (general/default limitations period)

  • Source: OSCN document page: https://www.oscn.net/applications/oscn/DeliverDocument.asp?CiteID=84050

To start, open the tool here: /tools/settlement-allocator

1) Open the tool and set the jurisdiction

1. Go to /tools/settlement-allocator.
2. Select Jurisdiction: Oklahoma (US-OK).
3. Confirm the tool indicates it is using the Oklahoma default timing rule (based on Okla. Stat. tit. 12, § 2023).

2) Gather the settlement inputs you’ll need

Before you type anything, collect these details from your settlement paperwork or case file. DocketMath’s output quality depends on input clarity.

Typical inputs you should be ready to provide:

• Settlement amount (the total to allocate)
• Allocation components (the categories you want the settlement distributed across)
• For each component, the basis dates the allocator needs (often a “start” and an “end” date, or a structured date pair depending on how the calculator is configured)

If your settlement agreement uses labels like “damages” and “fees/costs,” translate those into the component list DocketMath supports.

3) Enter component lines (what to allocate)

Add one line per allocation component you want DocketMath to assign a share to. For each component:

• Paste/select the component label (keep it short and consistent)
• Enter the relevant dates that drive the allocation period calculation
• Enter any component amount only if your workflow/tool setup requires it; otherwise, the allocator will distribute based on its timing methodology

Important Oklahoma note: DocketMath’s behavior for this Oklahoma configuration is tied to the general/default limitations period under Okla. Stat. tit. 12, § 2023. Because no claim-type-specific sub-rule was found, you should expect the same period to apply to all components in the calculator’s timing logic.

4) Review how the rule impacts outputs (timing-driven allocation)

Settlement Allocator results are driven by the relationship between:

• your component’s dates, and
• the default Oklahoma period used by DocketMath (from Okla. Stat. tit. 12, § 2023)

Practical effect:

• Components whose date ranges align more closely with the allocation period tend to receive a larger share.
• Components that fall outside or stretch beyond the effective allocation window can receive a reduced share, depending on the calculator’s weighting approach.

5) Run the calculation

1. Click Calculate (or the equivalent action in the UI).
2. Review the allocation table once it generates.

If DocketMath provides intermediate breakdowns (for example, period ratios or weighting factors), save or export them if possible. Those details make it easier to see what changed after you adjust inputs.

6) Validate outputs with a quick sanity check

Before finalizing:

• Confirm the allocated amounts sum to the settlement amount (or match the tool’s rounding policy).
• Check that each component’s output is non-negative and aligns with the dates you entered.
• If you changed a key date (like “incident date” or “resolution date”), verify you see a corresponding shift in allocation.

A simple checklist:

• Jurisdiction set to Oklahoma (US-OK)
• Rule shown aligns with Okla. Stat. tit. 12, § 2023
• Date fields reflect the actual component timeline
• Allocation totals reconcile with the settlement figure
• Output distribution is directionally plausible given the date ranges

7) Export or record your results

Once you’re satisfied:

• Export the results if DocketMath supports it in your environment.
• Record your input dates and settlement amount in your working notes so you can rerun later if new documentation arrives.

Common pitfalls

These are the errors that most often cause Oklahoma allocations to look “off” in DocketMath.

1) Confusing the date basis

Settlement agreements can include multiple dates:

• incident/occurrence date
• demand date
• filing date
• mediation date
• settlement execution date
• payment date

DocketMath’s allocator logic depends on which dates you map to the calculator fields. If you use the wrong ones, the tool will compute the allocation using that wrong timeline.

2) Assuming Oklahoma has claim-type-specific timing rules inside the tool

Some jurisdictions implement different limitations timing by claim category. For Oklahoma, no claim-type-specific sub-rule was found for the allocator behavior described here.

So if you expected separate buckets driven by distinct Oklahoma limitations categories, the tool will instead use the general/default period tied to:

• Okla. Stat. tit. 12, § 2023

3) Omitting a component or double-counting

Allocations go sideways when:

• a component you meant to include is missing, or
• a component is represented twice (for example, damages entered both as “general damages” and “economic damages” with overlapping date fields)

Do a reconciliation pass:

• Does every settlement consideration you want represented appear once?
• Do the components overlap, or are they meant to be distinct?

4) Rounding surprises

Many calculators round to whole dollars (or two-decimal precision). If you see a small mismatch between total settlement and the sum of component outputs, it’s often rounding—not a mathematical failure.

Quick check:

• Difference is within expected rounding (e.g., $1–$2)

5) Treating the statute citation as the only “rule input”

Even though the statute citation drives the default timing period, DocketMath still needs component-specific dates. “Garbage in, garbage out” applies here: incorrect date mapping will change the output.

Try it

Want a fast way to validate your workflow before you commit to a full allocation?

1. Open /tools/settlement-allocator
2. Select Oklahoma (US-OK)
3. Enter:

   • a known settlement amount (use a number you can verify)
   • 2 components with clearly different date ranges (for example, one component with dates closer together, another with a longer span)
4. Click Calculate
5. Change only one date on one component and rerun.

You’re looking for this kind of behavior:

• The output for the edited component shifts in a consistent direction.
• The sum of allocations still matches the settlement total per the tool’s rounding rules.

Related reading

• How to calculate Settlement Allocator in Ohio — Full how-to guide with jurisdiction-specific rules
• How to calculate Settlement Allocator in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Settlement Allocator in Philippines — Worked example with real statute citations