How to run Offer Of Judgment Analyzer in DocketMath for Delaware

How to run Offer Of Judgment Analyzer in DocketMath for Delaware

6 min read

Published April 19, 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

This guide shows how to run DocketMath’s Offer Of Judgment Analyzer for Delaware (US-DE) and how the tool’s jurisdiction-aware rules connect to Delaware’s civil fee-shifting baseline.

Note: DocketMath’s analyzer helps you model outcomes and timing concepts. It’s not legal advice and shouldn’t replace case-specific review of the governing rule, local practice, and any opt-in/opt-out mechanics that may appear in your pleadings.

1) Open the analyzer and select the Delaware jurisdiction

  1. Go to the tool: **Offer Of Judgment Analyzer
  2. Set jurisdiction to Delaware (US-DE).
  3. Confirm the tool is applying Delaware defaults.
    • The analyzer should indicate internally that Delaware (US-DE) is the active jurisdiction once you select it.

If you don’t see a jurisdiction selector in your view, double-check that you’re in the Delaware version/workflow for the analyzer. Your goal is to ensure the calculations reflect Delaware’s civil fee/cost baseline.

2) Confirm the rule basis the tool uses for cost/fee treatment

Delaware’s starting point for fee recovery in civil actions is 10 Del. C. § 507. It provides the general baseline that:

  • Text (summary): In any civil action, the court shall award costs to the prevailing party, including reasonable attorney’s fees, unless otherwise provided by statute or rule.
  • Citation: 10 Del. C. § 507

How this matters in the analyzer: DocketMath uses § 507 as a general/default framework for how cost-and-fee effects may be modeled when a more specific override is not indicated.

Important clarification (no claim-type-specific override found): The Delaware setup described here does not include a claim-type-specific sub-rule in the analyzer’s rule mapping. In other words, the tool treats § 507 as the default rationale/period unless the analyzer indicates a more specific override for your scenario.

3) Enter the offer and case timing inputs

The analyzer typically relies on inputs like the following (UI labels can vary):

  • Offer amount: the dollar figure you’re modeling.
  • Time anchor date: a date tied to when the offer is considered “made” (or another scenario milestone).
  • Acceptance / rejection timeline, or a “days until judgment”-type input.
  • Expected judgment amount: the estimated final outcome amount for the modeled comparison.
  • Party role (if asked): which side you are modeling as the “offeror” or “offeree.” This can affect how “prevailing party” assumptions are applied in the results.

As you update inputs, watch outputs that recalculate:

  • whether the offer appears “more favorable” compared to the modeled judgment,
  • how the cost/fee components are presented under the Delaware default framework,
  • and the modeled difference between scenarios (the “delta” in the tool’s summary).

4) Add any fee-related assumptions the analyzer requests

Depending on your configuration, the analyzer may show optional fee/cost fields such as:

  • Estimated attorney’s fees (or a rate/fee figure)
  • Estimated taxable costs
  • Interest/other adders (if enabled)

Use assumptions that are as consistent as possible across scenarios. Even moderate changes in assumed fees can shift the “net effect” outputs substantially.

Gentle reminder: because the tool is modeling based on your inputs, the results are only as good as the assumptions you enter.

5) Run the analysis and review outputs in the order presented

After clicking Calculate / Analyze, review outputs from top to bottom:

  1. Scenario summary
    • Often includes a comparison between offer value and the modeled judgment.
  2. Cost/fee impact section
    • Reflects the Delaware default framework tied to 10 Del. C. § 507 (prevailing-party costs including reasonable attorney’s fees, unless otherwise provided by statute or rule).
  3. Timing/threshold indicators
    • If the analyzer includes any time/threshold logic, verify the days or anchor date you entered matches your intended narrative.

6) Iterate: run “what-if” variations before you lock numbers

Rather than running only one version, try several iterations so you can see how sensitive the modeled outcome is to your assumptions:

  • Base case: your best estimate of judgment and fees.
  • Favorable outcome: judgment moves closer to the offer.
  • Unfavorable outcome: judgment meaningfully differs from the offer.
  • Optional extra sensitivity: change timing by a small amount (for example, ±10 days) if the analyzer supports it.

The goal isn’t certainty; it’s understanding which inputs drive the result the most.

7) Use the output to structure your internal decision memo (without treating it as advice)

Once you have results, capture the key numbers in a simple table and record the inputs used. Clearly label them as modeled assumptions.

A quick documentation checklist:

Common pitfalls

Delaware-specific fee modeling can drift off course for reasons that are easy to miss in the UI. Use this checklist to avoid common errors.

Warning: If your case is governed by a statute or rule that overrides the baseline in 10 Del. C. § 507, the analyzer’s default modeling could misstate how fees/costs should work in practice.

In this Delaware analyzer setup, 10 Del. C. § 507 is used as the general/default rule because no claim-type-specific sub-rule was found in the tool’s Delaware rule mapping for this workflow.

If your matter is governed by a different, more specific fee-shifting provision, you may need to adjust your approach (or at minimum document the limitation and verify governing authority separately).

Pitfall 2: Feeding inconsistent timing anchors

Timing mismatches can skew outputs. For example:

  • the time anchor date you treat as “offer made,” and
  • the days until judgment you enter

can conflict with your narrative.

Quick fix:

Pitfall 3: Over-optimistic fee assumptions

The tool may display a precise “net effect,” but it’s only as realistic as the fee/cost assumptions you enter.

Instead:

Pitfall 4: Confusing offeror/offeree framing

If the UI asks who you are (offeror vs. offeree), select the correct role. In many offer-effect models, which side benefits from leverage depends on role and the prevailing party assumptions used in the tool.

Pitfall 5: Not documenting inputs

When you export or copy results, you’ll get more value later if you keep an input snapshot.

At minimum, record:

  • offer amount
  • modeled judgment amount
  • attorney’s fees and costs assumptions
  • timing inputs (anchor date and/or days)

Try it

Ready to run a Delaware scenario in DocketMath? Start here:

  • Set jurisdiction to **Delaware (US-DE)
  • Enter:
    • your offer amount
    • your modeled judgment amount
    • a realistic timing (days and/or anchor date)
    • any fee/cost assumptions if requested by the tool

Then do a fast test cycle:

As you compare outputs, keep the Delaware fee baseline in mind: 10 Del. C. § 507 directs the court to award costs to the prevailing party, including reasonable attorney’s fees, unless a statute or rule provides otherwise. In this Delaware analyzer setup, that baseline is the tool’s default framework for modeling cost/fee effects.

If you want additional context while testing inputs, browse the DocketMath blog: /blog (see link below).

Related reading