How to calculate Offer Of Judgment Analyzer in Montana

Quick takeaways

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

• In Montana, an offer of judgment can be associated with costs and fees consequences when a party rejects the offer, under Mont. Code Ann. § 27-1-211.
• DocketMath’s Offer Of Judgment Analyzer (US-MT) helps you model and compare scenarios (offer amount vs. judgment amount, plus cost/fee inputs). It does not guarantee any particular legal outcome.
• The Montana guidance you provided is general/default: you did not identify a claim-type-specific timing rule. The analyzer should therefore apply the general/default period rather than switching timing logic by claim type.
• To get useful output, focus on these inputs:

  • Offer amount
  • Expected or actual judgment amount
  • Whether the offer was accepted or rejected
  • Modeled costs/fees (so the calculation reflects the “costs and fees” concept in § 27-1-211)

Inputs you need

To calculate in DocketMath → Offer Of Judgment Analyzer (US-MT), collect the inputs below. DocketMath typically maps these to calculator fields—use the closest accurate numbers you have.

Use this intake checklist as your baseline for Offer Of Judgment Analyzer work in Montana.

• jurisdiction selection
• key dates and triggering events
• amounts or rates
• any caps or overrides

If any of these inputs are uncertain, document the assumption before you run the tool.

Core numeric inputs

• Offer amount (Montana offer of judgment value):
  The dollar figure stated in the offer (e.g., $50,000).

• Judgment amount (expected or actual):
  The amount the court awards (e.g., $45,000).

  • If you’re running a scenario before trial, use a reasonable litigation estimate.
  • If you’re running after trial, use the judgment in hand.

• Costs/fees model (for risk comparison):
  Enter either (or both, if the tool allows):

  • Expected recoverable costs (e.g., filing, deposition, transcript costs), and/or
  • Expected attorney’s fees (only if you have a basis to model them)

Decision-path inputs

• Acceptance status:

  • Accepted: the analyzer should not apply rejection-based exposure.
  • Rejected: the analyzer should apply the rejection-based cost/fee consequence model tied to Mont. Code Ann. § 27-1-211.

• Timing model (default/general rule):
  Use the analyzer’s timing inputs as general/default timing because no claim-type-specific sub-rule was provided.

  • State clearly in the analyzer that you’re using the general/default logic, not a claim-type-specific rule.

Optional scenario inputs (if your tool exposes them)

• Percent or multiplier for fees (to project a rough range rather than a fee-by-fee log)
• Discount for collectability (to reflect economic reality, if the tool supports it)

How the calculation works

DocketMath approaches offer-of-judgment analysis as a comparison and risk modeling problem. In Montana, the provided statutory concept centers on what may happen regarding costs and fees when a party rejects an offer.

DocketMath applies the Montana rule set to the inputs, then runs the calculation in ordered steps. It validates the trigger date, applies rate or cap logic, and produces a breakdown you can audit. If you change any one variable, the tool recalculates the downstream outputs immediately.

1) Rule trigger: “rejected offer” exposure under Montana law

The statute you provided is:

• Mont. Code Ann. § 27-1-211
  “A party who rejects an offer of judgment may be subject to the provisions of this section regarding costs and fees.”

How DocketMath uses this:

• When you select Rejected, the analyzer turns on the cost/fee consequence modeling based on your entered costs/fees (and any other relevant timing fields).
• When you select Accepted, the analyzer should not apply the rejection-based cost/fee framework.

Important nuance (“may” vs. “must”):
Because the language says “may be” subject, results are best understood as modeled exposure—not a guaranteed or automatic outcome. Your entered inputs drive the estimate.

2) Default/general timing treatment (no claim-type-specific rule provided)

You also instructed:

• No claim-type-specific sub-rule was found. The above is the general/default period.

How DocketMath uses this:

• The analyzer should apply the general/default period you configured for Montana.
• It should not attempt to substitute a different time window based on a particular claim type.

Practical takeaway: if you’re unsure which timing model applies in your case, defaulting to the general approach (as reflected in your provided jurisdiction settings) is the safest way to align your scenario with the rules you supplied.

3) Economic comparison: offer vs. judgment

Even though § 27-1-211 focuses on costs and fees after rejection, the “value” of an offer depends heavily on the relationship between:

• Offer amount (what was offered), and
• Judgment amount (what the court awarded)

In DocketMath terms, your inputs support comparisons such as:

• Offer higher than judgment: the offer could be economically favorable (especially if cost/fee exposure is modeled meaningfully).
• Offer lower than judgment: the rejection might look less risky or even favorable to the rejecting side, depending on your cost/fee assumptions.

4) Output: modeled cost/fee exposure and scenario differences

While the exact labels can vary by interface, the analyzer typically provides outputs based on your selections and entries, such as:

• Estimated cost/fee exposure (driven by your costs/fees inputs)
• Scenario deltas comparing the consequences under different choices (e.g., accepted vs. rejected, or different offer/judgment numbers)
• Flags indicating that rejection-based modeling and the default/general timing approach were used

Because § 27-1-211 emphasizes costs and fees upon rejection, the most defensible outputs to rely on are those tied to your entered costs/fees and the rejection toggle.

5) Sensitivity: why small changes matter

To interpret results correctly:

• Adjust judgment amount and rerun—valuation swings can flip the economic story.
• Update costs/fees—these inputs often dominate the practical “exposure” estimate.
• Re-check rejection/acceptance—choosing the wrong option can dramatically change the result.

Common pitfalls

• Assuming Montana is claim-type-specific when the provided data is general/default:
  Since no claim-type-specific timing rule was identified in your jurisdiction inputs, the analyzer should use the general/default period logic.

• Underestimating costs/fees:
  If your entered costs are far below likely recoverable spend, the modeled exposure will be understated. Garbage-in, garbage-out applies even when the calculation mechanics are correct.

• Using an unrealistic judgment estimate:
  Pre-trial projections can be wrong. If the real judgment ends up far from your entered value, the offer/judgment comparison can reverse.

• Forgetting the rejection toggle:
  If you mark an offer as Accepted, the analyzer should not apply § 27-1-211 rejection-based exposure—outputs can be misleadingly low if the scenario is wrong.

• Treating “may be subject” as “automatic”:
  The provided statutory text uses discretionary language (“may”). DocketMath can’t convert discretion into certainty—so treat results as modeled risk/estimate, not a promise.

Sources and references

• Mont. Code Ann. § 27-1-211 (Montana offer of judgment; rejection and cost/fee exposure)
  https://leg.mt.gov/bills/mca/title_0270/chapter_0010/part_0020/section_0110/

Start with the primary authority for Montana and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.

• Primary authority reference

Next steps

1. Open DocketMath’s Offer Of Judgment Analyzer:
   /tools/offer-of-judgment-analyzer
2. Enter a baseline scenario:

   • Offer amount
   • Expected/actual judgment amount
   • Rejected vs. accepted
   • Modeled costs/fees
   • Confirm the timing uses the general/default approach (since no claim-type-specific rule was provided)
3. Run multiple comparisons:

   • Use at least two scenarios to test sensitivity (for example, a different offer amount, or a different judgment estimate).
4. Update inputs one at a time:

   • Change judgment first
   • Then change costs/fees
   • Finally verify timing fields match the general/default approach

Related reading

• Offer of Judgment Analyzer Guide for Alabama
• Offer of Judgment Analyzer Guide for Arizona
• Offer of Judgment Analyzer Guide for Colorado