Spreadsheet checks before running Damages Allocation in Oklahoma

5 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

DocketMath’s damages allocation workflow is only as reliable as the inputs you feed it. Before you run damages allocations in Oklahoma (US-OK), this spreadsheet checker is designed to surface common data problems that can silently distort totals, dates, and category splits—especially when the calculation depends on time-based rules.

Here’s what the checker is built to catch before you run damages-allocation:

Missing or inconsistent dates
- Blank “incident date,” “filing date,” or “event date” fields
- Dates entered in multiple formats (e.g., 01/05/2024 vs 2024-01-05)
- “End date” earlier than “start date,” which can flip or zero out time windows
Wrong or mismatched jurisdiction context
- Accidentally using the wrong jurisdiction code in the spreadsheet
- Mixing Oklahoma rows with non-Oklahoma rows in the same allocation sheet (even one rogue row can contaminate subtotals)
Statute of limitations (SOL) inputs that can’t be evaluated
- Missing the key date needed to evaluate 22 O.S. §152
- Non-numeric “days” fields where the checker expects a date-based derivation
General SOL period applied incorrectly
- Oklahoma’s general/default limitations period referenced here is 1 year
- This checker flags cases where your sheet appears to apply a different period without a clearly supported basis.
- Per the provided jurisdiction data, no claim-type-specific sub-rule was found, so the checklist treats 1 year under 22 O.S. §152 as the default evaluation period in this checker workflow.
Allocation math integrity issues
- Category percentages that don’t add up to exactly 100% (or don’t match the allocation mode)
- Negative amounts in categories that are intended to represent damages totals
- Totals that don’t reconcile, such as:
  
  Total claimed ≠ sum of allocation categories
  
  Total damages ≠ sum of line items
Spreadsheets that look right but behave wrong
- Text-formatted numbers (e.g., "$10,000" stored as text)
- Trailing spaces or hidden characters in category labels
- Duplicate rows for the same event (common when exports are appended twice)

Pitfall: A single date typed as text can prevent the checker from computing the SOL window. The result can be a damages allocation that “runs” but is based on stale or default values rather than actual timelines.

When to run it

Run the spreadsheet checker at three points—each one catches a different class of problems.

Before you launch DocketMath damages allocation
- Purpose: block garbage-in, garbage-out.
- You want the spreadsheet clean enough that outputs reflect your intended facts and structure.
Immediately after you map columns
- Purpose: verify that the checker sees the fields you think it sees.
- This is where mismatches happen: a “date filed” column gets mapped to an “incident date” slot, or jurisdiction tags are overwritten.
After any bulk edits or exports
- Purpose: catch formatting damage caused by copying from another system.
- Common triggers:
  
  Importing from case management exports
  
  Re-running macros or reformatting columns
  
  Joining multiple spreadsheets into one allocation file

Oklahoma timing rule context (default evaluation)

For Oklahoma, the checker uses the general/default limitations period you provided:

General SOL period: 1 year
General statute: 22 O.S. §152
Source reference (provided jurisdiction context): https://www.findlaw.com/state/oklahoma-law/oklahoma-criminal-statute-of-limitations-laws.html

Because the jurisdiction data indicates no claim-type-specific sub-rule was found, the checker treats the 1-year general/default period under 22 O.S. §152 as the baseline evaluation standard for this workflow.

Warning: Don’t rely on a spreadsheet that “passes” category math checks while failing SOL-date completeness. In Oklahoma, a missing or inconsistent date can move items into or out of the effective window, which changes allocations downstream.

Try the checker

Use DocketMath’s damages allocation tool like this:

Go to DocketMath → Damages Allocation
- Primary CTA: /tools/damages-allocation
Confirm your sheet is labeled for **Oklahoma (US-OK)
- If your workflow allows a jurisdiction selector, verify it’s set correctly before running.
Paste or upload your spreadsheet data
- Ensure date fields are real dates (not text).
- Confirm numeric fields are numeric (no currency symbols in cells that must be numbers).
Run the spreadsheet checks
- Then review the flagged items.
- Fix issues in the spreadsheet, re-run checks, and only then run the allocation computation.

Inputs the checker expects (practical checklist)

Use these quick verification steps before clicking calculate:

How outputs change when checks fail

When the checker finds a defect, it typically affects one of these output dimensions:

Spreadsheet issue	Typical checker impact	Likely downstream effect
Missing key date	SOL evaluation cannot be performed	Allocation may default or become unreliable
Date stored as text	Date parsing fails	Time windows miscomputed
Percentages don’t total 100%	Category weighting inconsistent	Category shares skew totals
Totals don’t reconcile	Integrity rules fail	“Total damages” doesn’t match sum of components
Jurisdiction mixed	Rule context conflict	Incorrect timing assumptions applied

Gentle note: This checker helps validate spreadsheet structure and input readiness. It is not legal advice, and it cannot replace review of the underlying facts or applicable legal analysis.

If you want to start now, open /tools/damages-allocation.