Abstract background illustration for How to run Offer Of Judgment Analyzer in DocketMath for Tennessee

How to run Offer Of Judgment Analyzer in DocketMath for Tennessee

7 min read

Published June 4, 2026 • By DocketMath Team

Partially verified

older_than_packet

Step-by-step

Below is a practical walkthrough for running Offer Of Judgment Analyzer in DocketMath for Tennessee (US-TN) using the jurisdiction-aware rules built for Tenn. R. Civ. P. 68.

Note: This guide explains how to use the analyzer and how the outputs are typically affected by inputs. It’s not legal advice and doesn’t replace reviewing the rule text for your specific case posture.

1) Open the analyzer in DocketMath (Tennessee mode)

  1. Go to the tool page: /tools/offer-of-judgment-analyzer
  2. Select or confirm the jurisdiction as:
    • US-TN — Tennessee

If DocketMath supports automatic jurisdiction detection, still verify the selected jurisdiction before entering numbers.

2) Enter the core offer terms (what the defendant offered)

Tenn. R. Civ. P. 68 is an “offer to allow judgment” mechanism. In DocketMath, you’ll typically supply these offer-facing inputs:

  • Offer amount (the “money” portion)
  • Offer effective against (e.g., the claimant being offered a judgment “for” that amount)
  • Offer date (if the tool asks; helpful for timeline-related assumptions)
  • Any cost language (if the tool supports “with costs” / “costs then accrued” concepts)

The rule’s core structure is that, at any time more than 10 days before the trial begins, a defending party may serve an offer allowing judgment to be taken for the money/property “or to the effect specified,” and the offer includes “costs then accrued.”
Source (rule page): https://www.tncourts.gov/rules/rules-civil-procedure/68

3) Enter the case outcome you want compared to the offer

To analyze “what happens if the outcome ends up above/below the offer,” DocketMath needs the eventual decision point. Common inputs include:

  • Expected/assessed judgment amount
    • Use the amount you anticipate the court award will be (or the actual award for a retrospective run).
  • Compare point
    • Some tools treat this as “judgment total” (including or excluding certain items). If DocketMath asks, choose the comparison basis it offers.

If you run multiple scenarios (e.g., different judgment estimates), you’ll see how sensitive the analyzer results are to the judgment amount relative to the offer.

4) Add costs and fee-related inputs (only if the tool requests them)

Even though the timing structure in Tenn. R. Civ. P. 68 references “costs then accrued,” the analyzer may also ask for additional assumptions so it can estimate cost-shift impacts.

Fill these only if you have reasonable numbers or conservative estimates:

  • Litigation costs (if prompted)
  • Attorney fees (if prompted)

If you don’t have reliable values, it’s usually better to leave them blank (if allowed) than to guess. Otherwise the output may look precise while resting on uncertain inputs.

5) Confirm the timing rule assumptions (the “more than 10 days before trial begins” window)

Tennessee’s default timing language is tied to the trial start date:

  • The rule allows an offer “[a]t any time more than 10 days before the trial begins.”

Important clarity for Tennessee usage in the analyzer:
The jurisdiction data provided for this workflow notes that no claim-type-specific sub-rule was found. That means this walkthrough should treat the general/default timing period as the governing period in the analyzer workflow—rather than relying on a special category rule.

Warning: Don’t input “10 days” as the threshold. Tenn. R. Civ. P. 68 says “more than 10 days.” If you’re close to the boundary, use the trial start date assumed by the tool (or run sensitivity checks with different trial-start estimates).

6) Run the calculation and review the outputs

After entering (at minimum) the offer amount and judgment/compare value, then any timing/cost fields DocketMath requests:

  1. Click Calculate / Run Analyzer.
  2. Review the output sections, which commonly include:
    • A comparison view (offer vs. outcome)
    • A potential cost-shift effect (and sometimes a fee/cost delta) depending on whether the eventual judgment falls on the more favorable or less favorable side of the offer

Because you’re using US-TN, DocketMath should apply Tenn. R. Civ. P. 68 timing and cost structure instead of using rules from other states.

What to double-check in your inputs (quick checklist)

Use this before running calculations:

  • Jurisdiction is set to US-TN
  • Offer amount is entered in the correct units (not mixed with costs unless the tool asks)
  • Judgment amount matches the tool’s compare point definition
  • Offer date (if required) is more than 10 days before trial begins
  • Costs/fees fields are left blank if you don’t have defensible numbers (and only filled if the tool uses them for the output you care about)

Common pitfalls

Offer-of-judgment analysis is easy to get subtly wrong. These are the issues that most often distort results in DocketMath runs for Tennessee:

  1. Using the wrong Tennessee timing window

    • Tenn. R. Civ. P. 68 uses “more than 10 days before the trial begins.”
    • If you set an offer date that is exactly 10 days (or you approximate trial start without aligning to the tool’s day-count logic), results may reflect an unintended scenario assumption.
  2. Assuming a claim-type-specific sub-rule exists

    • For this Tennessee workflow, no claim-type-specific sub-rule was found.
    • Treat the general/default timing period as governing in the analyzer rather than expecting a special category rule.
  3. Mixing “judgment total” with a different comparison basis

    • Some tools define the input as “judgment total” in a specific way (e.g., whether certain components are included).
    • If your number doesn’t match the tool’s definition, the offer-vs-outcome comparison can flip even if the underlying case facts are unchanged.
  4. Leaving costs/fees blank but expecting cost-shift detail

    • If the tool’s output depends on cost/fee inputs, blank fields can reduce detail or change what the analyzer displays.
    • If you want more granularity, first run a minimum-input scenario (offer + judgment), then rerun with costs/fees only when you have supportable estimates.
  5. Treating the analyzer output as case-ready authority

    • DocketMath calculations are scenario analysis based on the inputs you provide.
    • They’re best used to understand “what if” outcomes and how sensitive results are to key variables—not as final legal conclusions.

Pitfall: If you are near the 10-day boundary, run two versions using different trial-start estimates (your best estimate and a conservative alternative) to see whether results materially change.

Try it

Here’s a quick way to validate your Tennessee setup in DocketMath before relying on the results.

Suggested trial scenario (for learning, not legal use)

  • Set jurisdiction: US-TN
  • Enter:
    • Offer amount: $25,000
    • Judgment amount (scenario A): $20,000
    • Judgment amount (scenario B): $35,000
  • If the tool asks for it, set the offer date to a date clearly more than 10 days before trial begins.

Run two calculations and compare

Create two runs:

  1. Run A: Offer = $25,000; Outcome = $20,000
  2. Run B: Offer = $25,000; Outcome = $35,000

Then observe:

  • Whether the offer-vs-outcome relationship changes as expected
  • Whether the analyzer produces a different cost impact direction across A and B

Use this “sanity test” table

ScenarioOffer amountJudgment amountRelationshipWhat you should see in output
A$25,000$20,000Judgment below offerOne side of the cost/penalty logic
B$25,000$35,000Judgment above offerThe logic flips or changes materially

If both runs look the same, re-check:

  • the jurisdiction selection
  • whether you actually changed the judgment input
  • whether the tool requires costs/fees to generate the output section you’re reviewing

Related reading