Abstract background illustration for How to run Damages Allocation in DocketMath for Ohio

How to run Damages Allocation in DocketMath for Ohio

6 min read

Published June 4, 2026 • By DocketMath Team

Verified · 3 primary sources

This page has current canonical verification receipts.

Quoted from the source law itself. Not legal advice; confirm how it applies to your matter.

Current verified answer

Ohio damages-allocation: limitation period is see statute; threshold percentage is 50.

Run the allocation

Authority and key facts

Citation: Ohio Rev. Code § 2307.22

View the primary source

Verified April 25, 2026

  • Limitation Period: see statute
  • Threshold Percentage: 50
  • Threshold Percentage: 50
  • Threshold Percentage: 50

Step-by-step

This guide walks you through running Damages Allocation in DocketMath for Ohio using jurisdiction-aware rules. You’ll be able to confirm which allocation approach applies, then generate results based on the inputs you provide.

Note: This walkthrough explains how to use DocketMath and the Ohio rules your calculator is configured to apply. It’s not legal advice.

1) Start the Ohio Damages Allocation calculator

  1. Open DocketMath’s Damages Allocation tool: /tools/damages-allocation
  2. Confirm the jurisdiction is set to Ohio (US-OH).
  3. Choose the allocation type that matches your scenario (or leave it to the calculator if it prompts you to select).

2) Gather the Ohio-specific inputs you’ll feed into the tool

The Ohio configuration your tool is set up to use is based on Ohio Rev. Code § 2307.22 (including the subsection structure and how fault-based allocations are handled under that section).

Before you run the calculator, assemble:

  • Parties you want included in the allocation (commonly: plaintiff and each relevant defendant)
  • The damages figure(s) you intend to allocate (for example, a single total amount used as the allocation basis)
  • The fault percentages you intend to use for allocation
  • Any settlement receipt information you plan to model (if your workflow includes receipts)

If your workflow includes receipts, use the tool’s receipts/settlement fields as shown in the UI. In the verified configuration, receipts behavior is configured using the statute’s “limitation period” concept (shown in the verified facts packet as “see statute”).

3) Enter comparative-fault percentages and apply the configured thresholds

DocketMath uses jurisdiction-aware configuration for comparative fault logic. For the Ohio tool configuration you’re using:

  • comparative-fault threshold percentage: 50
    • Rules are configured with 50 / 50 thresholding behavior

Practically, this means the calculator’s logic can change based on how your entered fault percentages relate to that 50% trigger. To keep results consistent:

  • Double-check that fault percentages are consistent with your underlying fact model
  • Enter percentages using the format the tool expects (for example, whole numbers vs decimals, depending on the UI)

A good workflow check:

  • Sum all defendant fault percentages you plan to allocate.
  • If the tool expects the total fault to align to a target (commonly 100%), make your input set match that expectation so allocations don’t drift.

4) Select/enable joint-and-several behavior if it matches your scenario

Ohio’s allocation framework includes joint-and-several concepts as implemented by the DocketMath Ohio configuration under Ohio Rev. Code § 2307.22.

In the verified configuration used for the Ohio tool:

  • joint-several threshold percentage: 50

So, when you enter or confirm comparative-fault inputs, the calculator can determine whether joint-and-several treatment applies according to its threshold-based logic tied to Ohio Rev. Code § 2307.22.

5) Model receipts/settlements (if applicable) using the tool’s receipts fields

Ohio addresses receipt-related mechanics under Ohio Rev. Code § 2307.22(C) and related subsections within that section.

In DocketMath’s Ohio configuration, receipts modeling includes a “limitation period” setting sourced from the statute (shown in the verified facts packet as “see statute”). Use receipts fields if:

  • You have settlement receipts to account for in your damages allocation, or
  • You need the tool to reflect how those receipts affect net allocation outputs for the scenario you’re modeling

If you don’t have receipts in your scenario, leave receipts disabled/blank so the allocation reflects the fault/damages basis only.

6) Run the allocation and review the output structure

After inputs are complete, run the calculation.

You should expect outputs that:

  • Break out allocation components using the selected logic paths (fault-based and/or joint-and-several), depending on your inputs relative to the configured 50% thresholds
  • Compute allocation amounts derived from the damages basis you entered
  • Reflect receipt effects if you included receipts in the run

If the output includes multiple views/tabs/columns:

  • Treat each view as a different allocation presentation generated from the underlying logic
  • If you see unexpected differences, re-check the inputs that control logic selection (especially the fault percentages relative to 50%)

7) Validate the result by changing only one variable

Before finalizing anything for a document workflow, sanity-check using controlled changes:

  • Change only one defendant’s fault percentage (for example, +5 points)
  • Keep the damages total and any receipts information unchanged
  • Re-run and observe:
    • Whether the calculator switches logic behavior around the configured 50% threshold
    • Whether allocation amounts move smoothly (proportional changes) or show a step-change (logic-path changes)

This “one-variable at a time” check is one of the fastest ways to catch data-entry issues (such as inputs summing differently than expected) and to confirm that you’re interpreting threshold-driven behavior correctly.

Common pitfalls

  • Fault threshold surprises near 50%
    The Ohio configuration includes 50% thresholds for comparative fault and joint-and-several logic. If inputs are near 50%, results can change more than you’d expect from proportional math alone.

  • Fault percentages not matching the tool’s expected total
    If the calculator expects the fault set to meet a target total (often 100%), entering values that don’t align can cause allocations to look “off,” even when each individual percentage seems reasonable.

  • Receipts entered when your scenario doesn’t include them (or omitted when it does)
    Receipts can materially affect net allocation outputs. Only enter receipts if they’re part of the scenario you’re modeling under Ohio Rev. Code § 2307.22(C) and its related structure.

  • Using the wrong allocation approach for the narrative
    If your scenario is better represented by joint-and-several treatment, but you run with comparative-fault-only inputs (or vice versa), the output will reflect that mismatch.

  • Inconsistent damages basis inputs
    Ensure the “total damages” (or damages basis) value you enter is the one you intend to allocate under the Ohio Rev. Code § 2307.22 framework your tool uses.

Warning: If results look implausible, check whether you crossed a 50% threshold between runs before assuming the model is wrong—threshold-driven logic is a common source of “step-change” outputs.

Try it

If you want to see how the Ohio damages allocation logic behaves inside DocketMath, do a quick test run with your real inputs:

  1. Open /tools/damages-allocation
  2. Set jurisdiction to Ohio (US-OH)
  3. Enter:
    • Your damages basis
    • Fault percentages for each defendant
    • Receipts only if they apply to your scenario
  4. Run the calculation
  5. Re-run with a small change to one fault percentage to test sensitivity around the configured 50% threshold

A practical test set (conceptual—use your own numbers):

  • One defendant slightly below 50%
  • Another defendant slightly above 50%
  • Then swap those relative positions (so the “below vs above 50%” relationship changes)

Comparing those runs helps confirm that your inputs are triggering the same logic-path behavior the tool is configured to apply under Ohio Rev. Code § 2307.22.

Related reading