How to run Offer Of Judgment Analyzer in DocketMath for Virginia

How to run Offer Of Judgment Analyzer in DocketMath for Virginia

6 min read

Published September 12, 2025 • Updated April 23, 2026 • By DocketMath Team

Article claim inventory in progress

Trust release 4

This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.

Step-by-step

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

This guide walks you through running Offer Of Judgment Analyzer in DocketMath for Virginia (US-VA). The analyzer is designed to apply jurisdiction-aware rules, meaning you’ll select US-VA and then enter the case details needed to estimate outcomes tied to Virginia’s offer-of-judgment framework.

Note: This post explains how to run the analyzer in DocketMath and how the numbers flow through the calculations. It does not provide legal advice or guarantee results in your case.

1) Open the tool for Virginia

  1. Go to the analyzer page:
    • Primary CTA: /tools/offer-of-judgment-analyzer
  2. If the tool prompts you for jurisdiction, choose:
    • Jurisdiction: Virginia
    • Jurisdiction code: US-VA

DocketMath uses the selected jurisdiction to apply the correct timing and cost-shifting logic under Va. Code Ann. § 8.01-271.1.

2) Enter the offer timeline inputs

Offer-of-judgment analysis depends heavily on whether the offer was served and how much time the opposing party had to respond—because the statute provides a default period for acceptance after service.

Virginia’s statute explains that when a party makes an offer to settle, the party may file it with the court and serve it on the opposing party. For purposes of this guide/tool workflow, the key timing concept is that the statute establishes a default period unless another timing rule applies.

Important for this calculator: your brief notes that no claim-type-specific sub-rule was found. That means DocketMath will use the general/default period from Va. Code Ann. § 8.01-271.1 as the baseline (rather than a special timing rule for a specific claim type).

As you fill inputs, focus on what the tool labels, typically:

  • Offer date / Offer served date (use the field name the UI intends—often this should be the service date, not when it was drafted)
  • Acceptance window or days until key cutoff (if the tool asks)
  • Judgment date (if applicable; some outputs may reference how long the matter was pending)

Input tip: If your case documents include multiple dates (draft date, filing date, service date), pick the one that the tool’s label refers to. If you’re unsure, start with the date described as service.

3) Add the financial inputs (these drive the payoff)

The analyzer needs the numeric parts that connect “better-off” comparisons after an offer.

At minimum, plan to enter:

  • Offer amount (the settlement figure you offered)
  • Judgment / award outcome amount (the amount the case results in—often entered as the final judgment, final award, or damages field)

If the calculator asks for additional numbers, enter them too, such as:

  • Costs (if there is a cost input)
  • Pre-offer vs. post-offer costs (if the tool models them separately)

If you’re unsure how to translate your case numbers into the tool’s fields, a practical way to start is:

  1. Enter the offer amount
  2. Enter the final judgment/award number
  3. Add costs/other fields only if the tool specifically requests them (and with the definitions the UI provides)

4) Set party and procedural context (if the UI asks)

Some analyzers change results depending on which side made the offer and what the eventual outcome was relative to the offer. In DocketMath, look for toggles such as:

  • Are you analyzing plaintiff’s offer or defendant’s offer?
  • Which party is the “making party”?
  • Whether your setup implies the judgment exceeded the offer or fell below it (sometimes derived from your amounts, sometimes asked explicitly)

These switches matter because the statute’s cost consequences are tied to whether the final result is more favorable than the offer for the making party (under Va. Code Ann. § 8.01-271.1).

5) Run the calculation and review the outputs

Once inputs are entered:

  • Click the tool’s Calculate / Analyze / Run button (whatever wording the UI uses).

You should expect outputs organized into categories such as:

  • Outcome comparison (whether the judgment/award is greater than or less than the offer)
  • Estimated cost consequences (modeled from Va. Code Ann. § 8.01-271.1)
  • A net-effect summary (often framed as a “better/worse than offer” result)

Because DocketMath is jurisdiction-aware, the explanation or breakdown should reference Va. Code Ann. § 8.01-271.1 and apply the statute’s timing framework.

6) Use the “what-if” loop (inputs → outputs)

If you want to see what actually drives the estimate, run multiple scenarios and compare the output changes. A simple loop:

  • Change offer amount (e.g., by 5–10%)
  • Re-run the analyzer
  • Compare cost/impact line items

Also try varying:

  • Judgment/award amount (if you’re modeling uncertainty)
  • Cost inputs (if the tool supports them)
  • Offer timing/acceptance inputs (if editable)

This helps you understand which inputs materially affect the “better/worse than offer” outcome.

Common pitfalls

DocketMath’s Offer Of Judgment Analyzer is built to follow Va. Code Ann. § 8.01-271.1, but results can still be skewed by input choices. Watch for these common issues:

  • Using the wrong jurisdiction code

    • If you don’t select US-VA, the analyzer may apply a non-Virginia framework.
  • Confusing “offer date” with “service date”

    • The statute’s mechanics rely on service and the time the other side has after service. If the UI distinguishes these, use the field intended for the service date.
  • Assuming a claim-type-specific rule is modeled

    • Your brief indicates no claim-type-specific sub-rule was found, so the tool uses the general/default period from the statute as the baseline timing rule.
  • Swapping offer amount vs. judgment/award amount

    • Those two numbers often determine the direction of the comparison. If they’re reversed, the analyzer’s conclusion can flip.
  • Leaving cost fields blank when the tool expects them

    • If the UI requires costs to compute modeled consequences, you may get incomplete or misleading estimates when costs aren’t entered.

Pitfall: If the judgment equals the offer, the tool’s “better/worse than offer” logic may treat the boundary case differently than you expect. Re-check the exact wording in the results panel.

Try it

To test the workflow right now:

  1. Open the analyzer here: /tools/offer-of-judgment-analyzer
  2. Select:
    • **Virginia (US-VA)
  3. Enter, at minimum:
    • Offer amount
    • Judgment/award amount
  4. Then add:
    • Offer service/offer date inputs (and acceptance-related inputs if the tool prompts for them)
    • Costs if the tool asks for them

After one run, do a quick iteration:

  • Increase the offer by $1,000 (or 5%, whichever is easier)
  • Re-run
  • Compare the output’s cost/impact items

This “small changes, see the delta” approach is usually the fastest way to validate you entered the right values.

Related reading