Inputs you need for Damages Allocation in Ohio

4 min read

Published April 15, 2026 • By DocketMath Team

Inputs you will need

Run this scenario in DocketMath using the Damages Allocation calculator.

Damages allocation in Ohio often turns on whether your damages are time-barred and how you’ve structured the underlying claims for allocation purposes. DocketMath can help you run a jurisdiction-aware workflow, but it needs specific inputs first—especially dates tied to Ohio’s general statute of limitations (SOL).

Ohio default SOL rule (used when no claim-type-specific sub-rule is identified):

  • Ohio applies a general/default SOL period of 6 months (0.5 years) under Ohio Rev. Code § 2901.13.
  • This content uses that general period because no claim-type-specific sub-rule was found for the topic you’re modeling. If your situation involves a different category that changes the limitations analysis, you’ll need to reflect that in your inputs before running the calculator.

Note (not legal advice): SOL analysis can be fact-specific (including accrual, tolling, and how your theory frames “the event”). Treat this as a practical modeling checklist, not a determination of rights.

Before you run DocketMath’s damages-allocation calculator, gather these inputs:

Required inputs for the allocation run

The date that triggers limitations for the damages theory you’re using in your model. Needed to measure whether the general SOL period is satisfied. Example categories: Some models apply timing analysis only to certain components. Decide what your allocation framework treats as “affected.” For example:

Ohio-specific rule input you should be aware of

This uses Ohio Rev. Code § 2901.13 as the governing general/default statute and applies a 6-month (0.5-year) window in the DocketMath configuration (US-OH).

Pitfall: If your claim actually falls into a category with different limitations than § 2901.13’s general/default period, using the default could distort time-based allocation outputs.

Where to find each input

You’ll enter the inputs directly in the /tools/damages-allocation workflow.

  1. Event date

    • Use the date your facts treat as the limitations trigger for the damages theory you’re modeling.
    • Enter it in the calculator’s event/start date field.
  2. Filing/assertion date

    • Use the date the claim was filed in the proper forum (or the operative assertion date your workflow uses).
    • Enter it in the calculator’s filed/entered field.
  3. Damages by category

    • Break down your damages totals into the categories you listed.
    • Enter each category amount into the corresponding fields.
  4. Eligibility / timing sensitivity

    • Choose which categories the model should treat as subject to SOL-based adjustment.
    • In the tool, this may appear as toggles, checkboxes, or a selection list.
  5. Constraints

    • If you want the calculator to enforce caps or preserve certain allocation rules, select those options before you run.

Run it

Once your inputs are ready, run the DocketMath → damages-allocation calculator using the Ohio configuration (US-OH). The core logic you’re relying on includes:

What the output will typically tell you

After you run the calculator, expect results in two layers:

  1. **Timing eligibility impact (based on dates)

    • The calculator measures whether the difference between your event date and filing/assertion date falls inside the 6-month general window.
    • If the dates are outside the window, the tool will generally reduce or zero-out allocations for categories you marked as “timing eligible.”
  2. **Allocated damages breakdown (category-level)

    • The calculator allocates your entered damages by category.
    • Any enabled constraints (caps or proportion rules) affect how final category allocations are computed.

Warning: If you input a filing date that predates the event date (or uses an “operative date” your theory doesn’t support), the calculator can misclassify eligibility and materially change allocation totals.

How changes to inputs affect outputs (fast test)

Before relying on final numbers, do a quick “what-if” sensitivity check:

  • Move filing/assertion date forward
    • More categories often become eligible within the 6-month window → totals typically increase.
  • Move event date later
    • Shortens the time between dates → generally increases eligibility.
  • Toggle timing sensitivity for categories
    • If you mark only certain components as timing-affected, only those category allocations should move when SOL eligibility changes.
  • Add constraints
    • Caps can reduce totals even if categories are eligible.

If you need a second pass, rerun with only one variable changed at a time (dates first, then category eligibility) so you can see what drives the delta.

Related reading