Spreadsheet checks before running Damages Allocation in Ohio
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Running Damages Allocation in Ohio is easiest when you first validate the inputs that control the statute-of-limitations (SOL) logic. DocketMath’s spreadsheet checker is designed to catch the common mistakes that can silently distort damages timelines—especially when the calculator uses an SOL cutoff to decide which damages periods are eligible.
Below are the main spreadsheet issues the checker can flag before you run DocketMath → Damages Allocation for Ohio (US-OH).
| Check | What it looks for | Why it matters for allocation |
|---|---|---|
| SOL cutoff alignment | A date range that extends past the SOL window for the claim’s timeline inputs | Post-cutoff dates can produce overstated recoverable amounts if the spreadsheet doesn’t reflect eligibility boundaries |
| Missing or inconsistent “start” vs “event” dates | Blank cells, mixed formats, or start dates occurring after event dates | Allocation depends on chronological order; date inversions can shift which sub-periods fall inside/outside the eligible window |
| Fractional-year conversion errors | Manual conversions from days/months into “years” (or rounding that changes outcomes) | Ohio’s general SOL is calculated as 0.5 years using Ohio Rev. Code § 2901.13—small rounding differences can change whether the spreadsheet includes an extra slice |
| Negative or zero-length periods | A computed duration of 0 days or a negative number caused by swapped columns | That can cause the calculator to allocate $0, or worse, misattribute amounts across periods |
| Silent unit mismatch | “Days” entered where the sheet expects “years,” or vice versa | Damages allocation is sensitive to units; the checker warns so outputs track the same unit system throughout |
| Multi-tab inconsistencies | Fields copied between tabs where one tab has different date formats | Your allocation totals can drift even when the “numbers” look the same |
Note (important): DocketMath’s Ohio workflow uses the general/default SOL period. In the Ohio materials you provided, no claim-type-specific sub-rule was found, so the checker applies the general SOL as the baseline rather than switching logic by claim category.
For this workflow, the checker anchors eligibility logic to the general SOL period provided: 0.5 years, supported by Ohio Rev. Code § 2901.13 (as cited in the provided source PDF).
Source: https://codes.ohio.gov/assets/laws/revised-code/authenticated/29/2901/2901.13/7-16-2015/2901.13-7-16-2015.pdf
When to run it
Use the spreadsheet checker before you run Damages Allocation—particularly when any of the following changes occur:
- You modify date inputs (e.g., incident date, filing date, last relevant date, accounting period start/end).
- You adjust unit handling (days vs months vs years) or rounding rules.
- You import data from another spreadsheet, CSV, or accounting system.
- You change formulas in any column that feeds the allocation timeline.
Practical workflow (minimize rework)
- Step 1: Run the checker on your raw inputs tab.
- Step 2: Fix flagged date formats, missing values, and unit mismatches.
- Step 3: Only then run /tools/damages-allocation so the calculator uses clean inputs.
- Step 4: If totals look off, re-check SOL alignment and the computed eligible windows first—those are typically the highest-impact error points.
Because the Ohio general SOL period in this workflow is 0.5 years, your sheet’s “time since” calculations should match that baseline closely. Even small date mistakes (like an off-by-one day or an inconsistent rounding approach) can change which portion of damages falls inside the eligible window.
Warning: If your spreadsheet converts 0.5 years into an approximate day count (for example, 182 vs 183 days), the cutoff can shift unintentionally. The checker is meant to prevent “looks right but allocates wrong” outcomes.
Try the checker
You can validate your Ohio damages spreadsheet using DocketMath’s workflow starting here:
- Primary CTA: /tools/damages-allocation
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Inputs to review in your spreadsheet
As you run the checker, focus on:
- Start date of the damages timeline segment you’re allocating
- End date (or event/through date) that defines the period to measure
- Any filing/relevant cutoff date your sheet uses to decide eligible vs non-eligible periods
- The unit system used in any “time difference” column (days, months, or years)
How outputs should change when inputs are corrected
When the checker finds and you fix issues, you’ll usually see one (or more) of the following patterns after re-running:
- Eligible window expands or contracts
Correcting date order or unit mismatches can move the cutoff boundary, changing which rows contribute to recoverable totals. - Totals change in discrete steps
Damages allocation is often computed by period slices, so fixing a mismatch may exclude/include a whole slice rather than slightly adjusting every line. - Some line items drop to $0
If a period becomes zero-length after correction (e.g., swapped dates), the allocation for that slice should appropriately go to zero.
Quick self-check (before you click)
Use these checks as a fast sanity pass:
If you want the fastest path: run the checker, fix the top 1–3 date/unit flags, then run Damages Allocation again. That sequence usually resolves the largest drivers of allocation error.
Gentle reminder: This content supports workflow accuracy and spreadsheet hygiene, not legal advice. For legal questions about SOL application to a particular claim, consult a qualified professional.