How to run Offer Of Judgment Analyzer in DocketMath for Colorado

How to run Offer Of Judgment Analyzer in DocketMath for Colorado

6 min read

Published October 18, 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

Here’s how to run DocketMath’s Offer Of Judgment Analyzer for Colorado (US-CO) and apply jurisdiction-aware logic tied to C.R.S. § 13-17-202.

Note: This walkthrough explains how to use DocketMath and what the Colorado rule generally triggers. It’s not legal advice, and you should still review your specific filing facts (dates, offer terms, and case posture) before relying on the result.

1) Open the analyzer and select Colorado

  1. Go to DocketMath → Offer Of Judgment Analyzer:
  2. Set the jurisdiction to US-CO (Colorado).
  3. Confirm the rule set shown in the UI is based on C.R.S. § 13-17-202.

Colorado’s statute generally provides that in any civil action, when the plaintiff makes an offer of settlement and the offer is not accepted, the court shall award reasonable attorney fees and costs under the statute’s conditions—based on how the case outcome compares to the offer. The analyzer uses Colorado’s offer/award timing and comparison framework to evaluate whether fee-shifting appears triggered.

2) Enter the required dates (so the tool can test eligibility)

In many offer-of-judgment tools (including DocketMath), timing determines eligibility. Enter the dates your case uses for the statutory comparison.

Common date inputs include:

  • Offer date (when the written settlement offer was made)
  • Offer expiration / rejection date (if the UI asks)
  • Judgment date (when the court entered judgment)
  • Service date (if prompted)

If the interface asks for a cutoff, “effective period,” or similar timing window, use the statute-relevant date fields so the tool can apply the intended timing logic.

Pitfall: If you enter the wrong date type (for example, using an “email date” instead of the date supported by your offer documentation), the analyzer can change from “appears triggered” to “not triggered,” even when your offer and judgment amounts look favorable.

3) Enter the offer amount and the final judgment amount

Next, enter the numeric values used for the offer-versus-outcome comparison:

  • Offer amount (the settlement amount in the offer)
  • Final judgment amount (what the plaintiff or defendant ultimately recovered, as reflected in the judgment)

If the UI supports component fields, use them carefully:

  • Interest or costs components (only if your judgment breaks these out and the tool expects them separately)
  • Net vs. gross selection (choose the option that matches how your judgment is presented)

As a practical rule, the analyzer will compare your offer amount to the judgment amount (and any related components, if you enter them) to evaluate whether the statute’s conditions appear met.

4) Choose who made the offer (plaintiff vs. defendant)

Colorado’s statute is structured around the plaintiff making an offer of settlement and the resulting fee-shifting conditions.

In the analyzer, select:

  • Plaintiff made the offer, or
  • Defendant made the offer (only if the tool supports evaluating either direction for your jurisdiction setup)

This selection matters because it changes the way DocketMath applies the statute’s “offer-maker vs. outcome” logic.

5) Confirm the default rule window (Colorado “general/default” period)

For Colorado in this analyzer configuration, use the general/default statutory framework.

  • Colorado rule used in this guide: C.R.S. § 13-17-202 (general/default period)
  • No claim-type-specific sub-rule found: This guide uses the default statutory framework without adding special carve-outs by claim category.

So your best approach is:

  • enter the statute-relevant dates accurately,
  • enter the offer and judgment amounts exactly as reflected in the documents,
  • and don’t assume a claim-type override unless the tool or its jurisdiction rules explicitly indicate one.

6) Run the calculation and review outputs

Click Analyze (or the tool’s equivalent action).

Review the outputs for:

  • A trigger assessment (whether the conditions appear met based on your inputs)
  • A fee/cost outcome estimate or directional result (depending on the UI)
  • A summary of inputs used, so you can spot mismatches quickly
  • The numeric comparisons the tool applied (for example, differences between offer amount and judgment amount)

Then, if results are surprising, revisit the inputs in the order most likely to matter:

  1. dates (especially judgment entry vs. signing/other dates),
  2. offer amount,
  3. judgment amount and whether costs/interest were handled correctly.

7) Iterate: update one variable at a time

To make the result actionable, rerun with controlled changes:

  • Change only the judgment amount to see how sensitive the trigger is.
  • Change only the offer amount to test revised scenarios (for example, a revised offer).
  • Change only the judgment date if you discover the tool used the wrong docket date.

This “single-variable rerun” approach helps you understand whether the outcome is close to a threshold or comfortably within it—without redoing everything manually.

Common pitfalls

These are the issues that most often cause incorrect or unexpected outputs for Colorado under C.R.S. § 13-17-202:

  • Date mismatches

    • Using “signed date” instead of the judgment entered date
    • Entering the offer date as the date it was emailed rather than the date supported by your offer filing/serving documentation
  • Totals that don’t match the judgment document

    • Judgments sometimes list separate components:
      • damages
      • attorney’s fees awards
      • costs awards
      • interest
    • If you combine components inconsistently with how the analyzer expects amounts, you can distort the offer-vs-judgment comparison.
  • Forgetting to select who made the offer

    • If the UI asks plaintiff vs. defendant and you select the wrong party, it can reverse the outcome logic.
  • Assuming special claim-type rules apply

    • For this Colorado configuration, no claim-type-specific sub-rule was found.
    • Use the general/default period tied to C.R.S. § 13-17-202, not a claim-by-claim timing override.
  • Ignoring offer terms

    • If your offer was conditional (for example, tied to dismissal terms) and the UI provides fields for conditions, don’t skip them—conditions can change how the offer is treated by the analyzer.

Warning: DocketMath’s analyzer depends on the inputs you enter. If the offer or judgment has multiple lines/components, capture them accurately rather than collapsing everything into one number.

Try it

If you want a quick start, use this workflow:

  1. Set jurisdiction to US-CO
  2. Enter:
    • offer date
    • judgment date
    • offer amount
    • final judgment amount
    • who made the offer (plaintiff/defendant)
  3. Click Analyze
  4. Review:
    • the trigger result
    • the numeric comparison summary
    • the list of inputs the tool used

Then run a quick sensitivity check:

  • Increase the offer amount by a small step (for example, +$5,000 or +$10,000) and rerun.
  • Watch whether the trigger flips.

This is a fast way to see whether the result is driven by a tight threshold (sensitive) or by a wider margin (robust), without manually recalculating every scenario.

Related reading