How to run Offer Of Judgment Analyzer in DocketMath for Kansas

Step-by-step

This guide walks you through running DocketMath’s Offer Of Judgment Analyzer for Kansas (US-KS) so the calculation reflects the tool’s jurisdiction-aware rules. You’ll use K.S.A. § 60-2002 as the governing rule for Kansas’s costs and the offer-of-judgment mechanism. This is an educational walkthrough—not legal advice.

1) Open the analyzer

Start by launching the Offer Of Judgment Analyzer:

• Primary CTA: /tools/offer-of-judgment-analyzer

2) Confirm the jurisdiction is set to Kansas

Inside the tool, locate the Jurisdiction selector and choose:

• US-KS — Kansas

If DocketMath remembers a previous jurisdiction from your last session, still verify it before computing. A wrong jurisdiction setting can change timing logic and how the tool models cost incentives under the applicable rule set.

3) Enter the dates (focus on the “offer” timeline)

Kansas’s offer-of-judgment provisions are governed by K.S.A. § 60-2002. The statute includes general guidance on costs and an offer of judgment mechanism under subsection (c).

In the analyzer, look for date fields such as:

• Date the offer was made
• Date of judgment (or date judgment entered / case ended, depending on the tool’s wording)
• Any additional deadline/timing field the analyzer asks you to compare against the offer period

General/default period note (important):
Based on the jurisdiction data provided, no claim-type-specific sub-rule was found. That means the analyzer should treat the relevant “offer period” as a general/default mechanism for Kansas, rather than applying a specialized timing rule tied to a particular type of claim—unless the tool explicitly prompts you for claim-specific data or you have additional Kansas statutory detail beyond what’s captured here.

Tip: If the tool only asks for the core dates (offer date and judgment date) and does not ask for claim type, assume the calculation is using the default/general Kansas approach.

4) Enter the monetary amounts the tool needs

Most offer-of-judgment workflows compare an offer amount to a judgment amount (the amount the court entered, or the amount you are modeling as “known”).

Enter values for fields such as:

• Offer amount
• Judgment amount (the judgment figure you want to compare against)
• Any optional party/preference fields (for example, whether you want to label a modeled party as “prevailing” vs. “non-prevailing,” if the UI offers that)

Also check for options like currency formatting or rounding. If you don’t have a reason to change defaults, leave rounding as-is so you can more easily compare runs.

5) Add costs-related inputs (when prompted)

Because K.S.A. § 60-2002 also addresses cost allowance, the analyzer may ask for inputs that help estimate cost exposure or cost timing effects.

Common prompts include:

• Estimated costs
• Filing fees and taxable costs
• Post-offer costs (if the tool separates costs into phases)

If you don’t have line-item support, enter a consistent estimate (and remember that estimates can change the “net” outcome). The goal is consistency across scenarios—so you can see how the offer strategy shifts the result within the assumptions you provided.

6) Review the analyzer outputs

After you complete required fields, run the calculation.

DocketMath typically shows output that helps you understand the relationship between the offer and the judgment, such as:

• A comparison summary (how the judgment relates to the offer)
• A timing-impact view (whether the offer falls within the relevant window the tool is using)
• A cost incentive effect (whether your inputs suggest higher cost risk or a potential recovery)
• A net estimate (if the tool supports netting using your cost inputs)

Scenario testing (recommended)

Use the output to stress-test your assumptions:

• “What if the offer had been $10,000 higher/lower?”
• “What if the judgment amount moves closer to/farther from the offer?”
• “What if the judgment date changes by a few days?”

This helps you see which inputs move the result most.

7) Validate the assumptions you used

Before relying on any output, do quick sanity checks:

• Are dates in the correct format?
• Is the judgment amount the correct figure (not a settlement number, unless that’s exactly what you’re modeling)?
• Did you enter costs as the tool expects (for example, total costs vs. post-offer costs, if separate fields exist)?

8) Export/share if your workflow supports it

If the tool offers a shareable link, export, or downloadable summary, use it to keep track of:

• the jurisdiction used (US-KS),
• the dates you entered, and
• the amounts and cost assumptions.

This is especially useful when you run multiple offer variations.

Common pitfalls

Even when the workflow looks simple, these are the issues that most often distort Kansas results in an Offer Of Judgment Analyzer workflow.

Pitfall checklist

• Wrong jurisdiction selected (e.g., leaving a default that isn’t US-KS)
• Missing or inconsistent dates

  • Offer date and judgment date must align with what the tool expects
• Using the wrong “judgment amount”

  • For example, entering a settlement payment amount when the model is intended to compare against the judgment entered by the court
• Forgetting the role of the general Kansas rule

  • K.S.A. § 60-2002 is the general/default foundation in this jurisdiction setup
  • Don’t invent claim-type-specific timing rules without statutory support and without the tool prompting for that level of detail
• Entering costs into the wrong field

  • If the tool separates costs (e.g., pre-offer vs. post-offer), make sure you place each estimate where the UI asks
• Mixing estimates and exact figures without tracking

  • Example: you use an exact offer amount from the record but estimate costs—note that mismatch when interpreting net outputs

Kansas-specific misunderstanding to avoid

Kansas’s costs and offer-of-judgment framework is addressed in K.S.A. § 60-2002, including:

• allowance of costs to the prevailing party as a matter of course (subsection (a)),
• allowance of other costs in the court’s discretion (subsection (b)),
• and an offer of judgment mechanism (subsection (c)).

From the provided jurisdiction data: there was no claim-type-specific sub-rule found. So the analyzer’s “offer period” should be treated as the general/default mechanism for Kansas unless the tool explicitly asks for claim type or additional statute detail is provided.

Try it

Use this quick practice workflow to see how DocketMath’s Kansas configuration changes outcomes when you vary inputs.

Scenario practice (3 runs)

Keep the judgment amount the same, and run three different offer amounts:

• Run A: Offer below the judgment amount
• Run B: Offer near the judgment amount
• Run C: Offer above the judgment amount

If the tool supports it, repeat the three runs shifting only the offer date earlier/later while holding the judgment date constant.

What to watch in the outputs

As you compare runs, look for changes in:

• Cost incentive direction (does the model view your position as more/less favorable?)
• Whether the tool indicates the timing window was met
• Whether any net estimate flips as the offer crosses the judgment threshold
• Which input seems to drive the biggest variation (offer amount vs. date vs. cost inputs)

Reference anchor

All of these outputs should be understood through the lens of K.S.A. § 60-2002—including the general costs framework and the offer-of-judgment concept under subsection (c).

Related reading

• How to calculate Offer Of Judgment Analyzer in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Offer Of Judgment Analyzer in Philippines — Worked example with real statute citations
• Inputs you need for Offer Of Judgment Analyzer in Philippines — Input checklist with sourcing guidance