How to run Offer Of Judgment Analyzer in DocketMath for Ohio

Step-by-step

Run this scenario in DocketMath using the Offer Of Judgment Analyzer calculator.

This guide walks you through running DocketMath’s Offer Of Judgment Analyzer for Ohio (US-OH). The analyzer is designed to apply jurisdiction-aware rules to help you model the cost consequences of an offer of judgment under Ohio Rev. Code § 2323.17.

1) Open the tool

Start at the primary call to action:

• /tools/offer-of-judgment-analyzer

On the tool page, make sure the jurisdiction is set to Ohio (US-OH). If you see a jurisdiction selector, choose US-OH so the analyzer uses Ohio-specific assumptions tied to Ohio Rev. Code § 2323.17.

2) Confirm what Ohio rule you’re modeling (default period)

Ohio’s governing statute, Ohio Rev. Code § 2323.17, authorizes written offers of judgment in certain civil actions. The statute also sets a cost-shifting consequence when an offer is rejected and the eventual judgment is not more favorable than the offer.

In this content, we’re using the general/default period because no claim-type-specific sub-rule was found in the provided jurisdiction data.

• Ohio Rev. Code § 2323.17 (general default):

  • If the offer is rejected and the judgment obtained is not more favorable, the rejecting party shall be liable for all costs incurred after the offer.

The analyzer should rely on this default logic rather than a special sub-rule.

3) Enter the offer and compare judgment amounts

Add the core numbers the analyzer needs to evaluate whether the judgment is more favorable than the offer:

• Offer amount (the dollar figure in the written offer)
• Judgment amount (the modeled or known eventual judgment)
• Comparison setting (if shown):

  • If the tool asks for an explicit toggle, select the option that matches your scenario.
  • If it computes automatically, enter the offer amount and judgment amount and let it determine the comparison.

Practical tip

If you’re modeling multiple outcomes (for example, a lower settlement vs. a higher verdict), run the analyzer more than once—one scenario per judgment number—so you can see how cost-shifting changes.

4) Add costs inputs (so “costs incurred after the offer” can be calculated)

Because Ohio Rev. Code § 2323.17 ties liability to costs incurred after the offer, the tool needs a way to represent those post-offer costs.

Depending on the tool’s interface, you’ll typically provide one or more of:

• Estimated costs incurred after the offer, or
• a breakdown such as:

  • post-offer filing-related costs
  • post-offer deposition/reporting costs
  • post-offer service/sheriff costs
  • (the exact fields may vary by how the calculator is built)

If the tool provides optional fields, you can often proceed with a single “total post-offer costs” figure. Precision helps, but starting broad is fine if you’re stress-testing your assumptions.

5) Review the tool’s output summary

After you submit inputs, DocketMath should return results like:

• a scenario assessment based on the comparison (offer rejected / judgment not more favorable vs. more favorable)
• an estimated cost exposure tied to “costs incurred after the offer” under Ohio Rev. Code § 2323.17
• a net difference view (how much the costs change under the modeled comparison)

Use the output to answer practical questions such as:

• “Does my modeled judgment meet the ‘more favorable than the offer’ threshold?”
• “If it doesn’t, what’s the magnitude of the exposure tied to post-offer costs?”

Reminder: This is an estimate based on the numbers you enter—not a guarantee of what a court will award.

6) Use the jurisdiction tag to keep results consistent

If you’re comparing Ohio against another jurisdiction in your workflow, keep a record of your jurisdiction setting (US-OH). Mixing outputs from different jurisdiction tabs/settings can lead to incorrect comparisons.

A simple workflow:

• Run Ohio first (US-OH)
• Save or note your results
• Switch jurisdiction (if needed) and rerun

7) Document assumptions for repeat runs

To make your modeling repeatable, write down your assumptions in a note:

• offer amount
• judgment amount
• post-offer costs estimate
• whether you’re using the general/default Ohio rule model (no claim-type-specific override applied)

This helps when you rerun after updates to the judgment estimate or cost forecast.

Common pitfalls

Below are the most frequent issues people run into when running offer-of-judgment models in DocketMath for Ohio (US-OH)—especially when mapping the statute’s cost consequence.

• Modeling the wrong consequence trigger
  Ohio Rev. Code § 2323.17 is tied to whether the judgment is not more favorable than the offer. If you input a judgment that is numerically below (or otherwise not more favorable than) your offer, the model should reflect post-offer cost liability. If you mark the comparison incorrectly, your result can flip.

• Using pre-offer costs as if they were “after the offer”
  The statute shifts “costs incurred after the offer.” If you enter total litigation costs without separating post-offer costs, the model can overstate exposure. Keep post-offer estimates focused on the period after the offer date.

• Forgetting that this is the general/default period
  The provided jurisdiction data does not identify a claim-type-specific sub-rule. That means the analyzer applies the statute’s general/default behavior tied to “all costs incurred after the offer.” Don’t assume a special timing rule unless DocketMath’s interface or jurisdiction rules explicitly provide it.

• Relying on a single input set for multiple scenarios
  Offer outcomes often change as a case progresses. Running the analyzer repeatedly—one scenario at a time—produces clearer insight than trying to “average” multiple outcomes into one input.

• Misreading the output as certainty
  The statute sets a statutory cost framework, but real cases may involve additional nuances. Treat DocketMath outputs as input-driven estimates, not definitive predictions.

Try it

You can run the calculator from this page:

• /tools/offer-of-judgment-analyzer

A quick “sanity check” workflow while testing:

1. Pick an offer amount (example: a single dollar figure you can easily compare).
2. Enter a judgment amount and test three scenarios:

   • run where judgment = offer
   • run where judgment < offer
   • run where judgment > offer
3. Keep post-offer costs constant for clean comparisons.

You should then see the model change the cost-shifting outcome based on the “more favorable than the offer” comparison.

To anchor the logic to Ohio law, the key statutory rule you’re modeling is:

• Ohio Rev. Code § 2323.17:
  If the offer is rejected and the judgment obtained is not more favorable than the offer, “the rejecting party shall be liable for all costs incurred after the offer.”

If you’re updating an ongoing matter, rerun after any of the following change:

• updated settlement/valuation
• refined post-offer costs forecast
• revised judgment expectation

This iterative approach helps keep your modeling aligned with the statute’s cost-trigger structure instead of locking you into outdated estimates.

Related reading

• Offer of Judgment Analyzer Guide for Alabama
• Offer of Judgment Analyzer Guide for Arizona
• Offer of Judgment Analyzer Guide for Colorado