How to run Offer Of Judgment Analyzer in DocketMath for New York

How to run Offer Of Judgment Analyzer in DocketMath for New York

6 min read

Published September 20, 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

You can run Offer Of Judgment Analyzer in DocketMath for New York (US-NY) to model how an offer may affect risk and potential exposure. This guide focuses on setting the jurisdiction-aware rules correctly for New York and understanding how changes to your inputs can change the analyzer’s outputs.

Note: This is a practical walkthrough to help you use the tool and interpret results at a high level—not legal advice.

1) Start the tool for New York

  1. Open DocketMath and go to the Offer Of Judgment Analyzer:
  2. Confirm the jurisdiction selection is set to:
    • **US-NY (New York)

If you don’t see US-NY selected by default, switch it now so the analyzer applies New York’s offer-of-judgment timing logic and related assumptions.

2) Enter the offer details (the inputs that drive the result)

Look for fields that capture the offer and the procedural posture. If the UI groups inputs, focus on categories like these:

  • Offer amount (the dollar figure being offered)
  • Offer date (sometimes labeled “service date”)
    Use the date that best matches how you entered the offer into the case timeline.
  • Case status / stage (for example, whether you’re modeling something effectively pre-judgment and what point in the case you’re at)
  • Party identification (e.g., whether you’re on the plaintiff or defendant side, if requested)
  • Response timing assumptions (some versions ask you to specify whether the offer was accepted, rejected, or left unresolved)

If DocketMath also asks for cost-related inputs (like fees, costs, or other components the model uses), enter what you know and keep your assumptions consistent across runs so you can compare scenarios reliably.

3) Use the New York timing rule the analyzer expects

DocketMath’s New York logic is tied to the CPLR offer framework. The key statute for offer timing in New York is:

The statute provides, in relevant part:

Any party may serve an offer of judgment upon any other party…” (see N.Y. CPLR § 3220, https://www.nysenate.gov/legislation/laws/CPL/3220).

Important for tool setup: Your brief indicates that no claim-type-specific sub-rule was found. That means you should not try to select claim-type-specific timing (if the interface offers it). Instead, use the general/default period that the tool applies for the New York model.

4) Confirm the analyzer’s jurisdiction-aware assumptions

Before you run, check whether the UI includes a “rules” or “assumptions” panel. In a properly configured jurisdiction-aware tool, you should see something like:

  • New York / CPLR § 3220-based timing
  • A selection for the analysis window, such as:
    • General rule (default) vs.
    • Claim-type-specific (or similarly named)

Because no claim-type-specific sub-rule was identified, choose General rule (default). This aligns your run with the approach described in your guidance.

5) Run the calculation and review outputs

Click Analyze (or the equivalent button). Review the outputs in a way that matches your inputs:

Typical output sections include:

  • A model comparison or benchmark showing how the offer amount relates to the modeled exposure or outcome metric (depending on what you entered)
  • A sensitivity section or “what changes the result” area (showing which inputs drive movement in the results)
  • A scenario summary (for example, acceptance vs. rejection vs. unresolved), if those scenarios are supported in the tool

If the tool supports multiple scenarios, compare them side-by-side so you can see how the outputs shift based on your selected assumptions.

6) Iterate: test how small input changes move the result

A practical way to use the analyzer is controlled scenario testing. Try this sequence:

  • Scenario A (Baseline): your current offer amount and date
  • Scenario B: increase the offer amount by 5%
  • Scenario C: reduce the offer amount by 5%
  • Scenario D: keep the offer amount constant, but adjust the offer date (if the tool lets you)
  • Scenario E: change the case stage/status inputs (if supported)

Then ask:

  • Which output metric changes the most when you tweak one input?
  • Does the direction of change “make sense” with your understanding of the case posture?

This keeps the exercise informational rather than speculative.

7) Save or export results (if available)

If DocketMath provides saving or sharing:

  • Save runs with descriptive names like:
    “NY CPLR 3220 model—Offer $X—Served Y”
  • Export a PDF or use a share link if offered
  • Keep baseline and adjusted scenarios together for easy comparison later

Common pitfalls

These issues most often cause results to look confusing or misleading:

  • Wrong jurisdiction selected
    • If you leave the tool on a non–New York setting, it may apply different offer timing or consequence assumptions.
  • Date mismatch
    • If your offer was actually served on a different date than what you enter, the analyzer’s timing window logic can “drift.”
  • Selecting a claim-type-specific option when none is supported by your guidance
    • Because your brief states no claim-type-specific sub-rule was found, use the general/default period instead of any specialized claim-type timing mode.
  • Leaving key inputs blank
    • Some tools fall back to default assumptions when fields are empty. That can be fine for a first pass, but it weakens comparisons across scenarios.
  • Changing too many variables at once
    • If you adjust offer amount and offer date in the same run, you may not be able to tell which change affected the output.

Quick rule of thumb: change one variable per scenario whenever possible, and keep notes on what you changed between runs.

Try it

Ready to run the analyzer?

When you launch:

  1. Set Jurisdiction = US-NY
  2. Use the general/default period approach consistent with the New York logic (since no claim-type-specific sub-rule was identified)
  3. Enter at least:
    • Offer amount
    • Offer service date
    • any required stage/status fields

Then run at least two scenarios:

  • Baseline: your current numbers
  • Adjusted: a modest change like ±5% offer amount

After running, review:

  • which output metric moves the most, and
  • whether the modeled consequences align with the basic case posture you’re using as assumptions.

Related reading