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

How to run Offer Of Judgment Analyzer in DocketMath for Pennsylvania

6 min read

Published June 4, 2026 • By DocketMath Team

Under review

missing_or_unverified_packet

Step-by-step

Below is a practical walkthrough for running Offer Of Judgment Analyzer in DocketMath for Pennsylvania (US-PA). This guide focuses on jurisdiction-aware rules using Pennsylvania’s offer-like mechanism under Pa. R.C.P. No. 238 (delay damages) and the general procedural foundation in 42 Pa. Cons. Stat. § 8101.

Note (Pennsylvania’s “offer” concept): Pennsylvania does not have a single, standalone “offer of judgment” rule that mirrors Fed. R. Civ. P. 68 in structure and effect. The functional equivalent in Pennsylvania practice is Pa. R.C.P. No. 238, which can award delay damages (prejudgment damages-as-interest) when the rule’s conditions are met.
Default period expectation: Pennsylvania uniquely lacks a claim-type-specific sub-rule discoverable for this analyzer setup, so you should expect the tool to use a general/default delay period.

1) Open the Pennsylvania Offer Of Judgment Analyzer

  1. Go to DocketMath: Offer Of Judgment Analyzer
    Primary CTA: /tools/offer-of-judgment-analyzer
  2. If the UI asks for jurisdiction or configuration, select:
    • Jurisdiction: US-PA (Pennsylvania)

2) Choose the analyzer mode that matches your scenario

DocketMath may present “offer” workflows that focus on things like (a) comparing an offer amount to the eventual recovery, and/or (b) calculating potential delay damages under the applicable logic.

Use the mode that best matches what you’re trying to model:

  • Model a PA delay-damages scenario grounded in Pa. R.C.P. No. 238
  • Compare an “offer” (or settlement demand) vs. the outcome to see whether additional amounts may flow from the rule logic

Because Pennsylvania operates differently than a classic offer-of-judgment framework, be especially careful about how your entries are mapped inside the calculator. In practice, the analyzer should still apply Pennsylvania’s jurisdiction-aware assumptions—just not via an exact Fed. R. Civ. P. 68 clone.

3) Enter the core inputs (the minimum set that drives the result)

Use the analyzer fields to input values such as:

  • Proposed settlement / offer amount
    (This is the “offer anchor” the tool uses for comparison.)
  • Final judgment or recovery amount
    (The outcome figure the tool uses to determine whether and how delay damages are computed under its model.)
  • Key dates
    Commonly includes the filing date and/or the dates that define the start and end of the delay-damages window—depending on how the calculator structures the timeline.
  • Monetary basis used for the delay-damages component
    Some calculators ask for what amount to treat as the base for delay damages calculations.

Practical formatting tips:

  • Enter dates in the format the calculator requests (e.g., MM/DD/YYYY).
  • Keep currency formatting consistent (avoid symbols if the UI expects numbers only).
  • If the tool asks whether an amount is “inclusive” or “exclusive” of certain components, follow the UI’s definitions—misclassification can noticeably change totals.

4) Confirm the jurisdiction rules are applying: Pa. R.C.P. No. 238

Pennsylvania’s delay-damages approach is rooted in Pa. R.C.P. No. 238, supported by Pennsylvania’s civil procedure statutes including 42 Pa. Cons. Stat. § 8101.

When you run the calculator, look for confirmation signals such as:

  • “Using Pa. R.C.P. No. 238
  • “Delay damages” or an “interest-like” prejudgment component
  • A computed delay window that is derived from the rule logic implemented in DocketMath

Default delay period (important)

For this analyzer configuration, plan on the general/default delay period. The reason is straightforward: the jurisdiction data provided indicates no claim-type-specific sub-rule was found. So the tool should apply the default rather than switch periods based on a particular claim type.

Pitfall: Don’t assume Pennsylvania delay damages automatically change based on claim category within this tool. With the information available here, this setup uses the general/default period.

5) Run the calculation and read the output sections

After you submit the inputs, the analyzer should provide results typically broken into parts, such as:

  • A comparison outcome (whether the recovery supports/activates the modeled delay-damages computation under the tool’s logic)
  • A delay-damages component (often shown as an interest-like amount over a computed delay window)
  • A modeled total (base amount + delay-damages add-on, where applicable)
  • A breakdown or timeline-derived notes (base vs. add-on, and the effective delay window)

Use the output to sanity-check your inputs:

  • If the delay window looks implausibly short or long, revisit your date inputs.
  • If the totals look “off,” check whether you entered the correct offer anchor and recovery amount in the fields the tool expects.

6) Iterate: adjust one input at a time

To understand what drives the result, run multiple small variations:

  • Scenario A (baseline): enter your best estimate of offer + expected outcome + dates
  • Scenario B: increase the offer amount by a set delta (e.g., +$10,000)
  • Scenario C: change a key date (e.g., move the filing date by 30 days)
  • Scenario D: change the final judgment / recovery amount

Compare how the delay-damages component changes each time. This is the quickest way to confirm whether the calculator is responding to the inputs you think it is.

Common pitfalls

  • Assuming Pennsylvania uses Fed. R. Civ. P. 68 directly

    • Pennsylvania’s mechanism is Pa. R.C.P. No. 238 (delay damages). The mechanics are not identical to the federal offer framework.
  • Mismatched date logic

    • Even a small shift in a date can change the computed “delay window,” which can significantly affect the delay-damages component.
  • Using the wrong “amount anchor”

    • If the calculator expects the offer amount to be a particular comparison input, but you instead enter a figure that includes other components (or is otherwise not what the UI calls “offer”), outputs can be misleading.
  • Forgetting the default period rule

    • This setup should use the general/default delay period because no claim-type-specific sub-rule was found for a targeted override.
  • Over-trusting a single run

    • Treat outputs as a computational estimate. Run at least 2–4 iterations varying one input at a time to see what actually drives the number.

Reminder / disclaimer: This tool-driven analysis is meant to be computational and educational—not legal advice. Actual entitlement to and calculation of delay damages under Pa. R.C.P. No. 238 can depend on procedural facts and compliance details that may not be fully captured by a calculator interface.

Try it

  1. Start the calculator: /tools/offer-of-judgment-analyzer
  2. Choose Pennsylvania (US-PA) if there’s a jurisdiction selector.
  3. Enter these fields carefully:
    • Offer / demand amount
    • Final judgment / recovery amount
    • Key dates that define the delay window in the tool’s model
  4. Run the analysis.
  5. Do a quick sensitivity test:
    • Increase the offer amount by 10%
    • Re-run
    • Compare how the computed delay-damages add-on changes

If the output includes a displayed delay window, copy that window into your notes. Then rerun using the same dates so only the amount changes—this makes comparisons much clearer.

Related reading