How to run Settlement Allocator in DocketMath for Colorado

Step-by-step

Run this scenario in DocketMath using the Settlement Allocator calculator.

This guide walks you through running Settlement Allocator in DocketMath for Colorado (US-CO) using jurisdiction-aware rules—so the allocations align with how Colorado disputes are commonly structured. This is a workflow explanation, not legal advice.

1) Open the Settlement Allocator tool

Start at the primary call to action: /tools/settlement-allocator

If you’re already in DocketMath, you can jump there directly and proceed with the inputs below.

2) Confirm jurisdiction is set to Colorado (US-CO)

Look for a jurisdiction selector in the tool UI and set it to:

• US-CO

DocketMath uses that jurisdiction setting to apply Colorado-specific allocation logic (for example, how it treats certain claim categories and common order-of-operations assumptions).

3) Choose the allocation method in the tool

In Settlement Allocator, select the method that best matches your case posture and settlement documentation. If the interface provides multiple methods, pick the one that corresponds to what you have the most support for in your settlement breakdown (for example: percent-based, weighted factors, or claim-category-based, depending on the options shown).

Practical rule of thumb:

• If your settlement offer/term sheet already lists percent shares by claim, use a percent/claim-based approach.
• If you have valuation indicators (like ranges, damages estimates, or probability weights), use a weighted approach.

4) Enter party/claim categories that match your document structure

Settlement Allocator works best when your input categories match the way settlement terms are expressed. Create line items for the categories you want allocated, such as:

• Compensatory damages (if applicable)
• Attorney’s fees (if included as a line item in the settlement terms)
• Costs (if separately stated)
• Interest (if separately stated)
• Any agreed “other” component (if the settlement breakdown has it)

Use the exact wording from your settlement breakdown where possible—even if you later rename labels in reports. Consistent categorization reduces reallocation surprises.

5) Provide the settlement total and the currency assumptions

Enter:

• Total settlement amount (the gross amount being allocated)
• Any pre/post assumptions the tool asks for (for example, whether the total is “all-in” versus “allocation excluding fees,” depending on what the UI offers)

If DocketMath asks whether amounts are already inclusive of fees/costs, set the toggle accordingly—otherwise the tool may double-count components during allocation.

6) Input claim-level amounts or drivers

Depending on the selected method, you’ll either provide:

• Claim amounts (for example: $X compensatory, $Y fees, $Z costs), or
• Weights/factors (for example: each claim’s weight, relative strength, or valuation driver)

If you’re using a weighted approach:

• Keep the scale consistent (for example, 1–10 weights for every claim category)
• Avoid mixing absolute dollars with weights unless the tool explicitly supports it

7) Review allocator outputs before exporting

After you submit, DocketMath produces:

• A claim/category allocation table
• A party-level or component-level breakdown (depending on the tool’s settings)
• Totals that should reconcile to your settlement total

Use the reconciliation checks in the UI (if present). Common flags include inconsistencies when:

• Allocations don’t sum to the settlement total
• A required category is missing
• A component exceeds the amount you indicated as “included”

8) Export or copy the results for your settlement paperwork workflow

Once the allocations look correct:

• Export the report if the tool provides download options, or
• Copy the allocation table into your workflow documentation

If DocketMath includes report sections (like assumptions and input echo), keep those pages—they’re usually what you’ll need when you revisit the allocation after revisions.

9) Validate scenario changes quickly

One advantage of using DocketMath is fast reallocation. If your settlement terms change—say, the fee component changes or interest is added—rerun with updated inputs and compare outputs.

A simple validation checklist for each rerun:

• Does every line item still appear?
• Do the allocations still reconcile to the same “total settlement amount” you entered?
• Did the party/category splits move in a way that matches the change you made?

To speed this workflow, you can keep the tool open and iterate only on the fields that changed.

10) Keep a “reason log” for revisions

While DocketMath can generate allocation math, your record of why you changed inputs matters in the broader case file. Maintain a short internal note next to each rerun, for example:

• “Updated fee component to match signed addendum (was $18,000, now $24,000).”
• “Added interest line item because the release states interest is included at settlement.”

This reduces confusion if multiple parties review the allocation.

Common pitfalls

Settlement allocations tend to fail for predictable reasons. Here are the most common ones when running Settlement Allocator for Colorado (US-CO) in DocketMath.

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

Mismatched “all-in” vs “exclusive” totals

Many settlement forms state whether the settlement amount is:

• All-in (includes fees/costs), or
• Exclusive (fees/costs are added separately)

If you set the toggle incorrectly in the tool, your allocations may not reconcile.

Missing claim categories that exist in the settlement terms

If the settlement agreement lists categories (for example, “attorney’s fees” and “costs”), but your tool input omits one, DocketMath may redistribute that omitted value into remaining categories—creating a result that can look mathematically plausible while being substantively wrong.

Double-counting fees and costs

Double-counting happens when:

• You enter fees as a separate component and
• Also indicate that the settlement total already includes fees

If your settlement total is “inclusive,” keep it consistent: either let the tool derive fees/costs from inclusion logic or input them as separate line items—don’t do both.

Inconsistent scaling for weighted methods

When using weights:

• Keep the scale consistent (for example, always 1–10 or always 0.1–1.0)
• Don’t mix percentage integers (like 30, 40, 50) with fractional weights (like 0.3, 0.4, 0.5) unless the tool explicitly converts

Failing to reconcile totals after each rerun

Allocations can look “close” while still leaving pennies or dollars unassigned. Before export:

• Check that allocation totals equal the settlement total
• Confirm rounding behavior matches what you need for your paperwork

Try it

If you want to test the workflow without disrupting an existing case file, do a quick dry run:

• Go to /tools/settlement-allocator
• Set Jurisdiction = US-CO
• Create 3–5 claim categories (for example: compensatory damages, attorney’s fees, costs)
• Enter a settlement total (use any realistic test number)
• Run once with amounts
• Rerun with a small change (for example, increase fees by 10%)
• Compare the output table totals and allocation shifts

You’ll learn two things fast:

1. Which inputs the tool treats as “included” versus “separate”
2. How the allocator redistributes value across categories when a component changes

Want an even faster iteration loop?

• Keep the same categories and only change one value per rerun.
• Screenshot or copy the output so you can quickly compare results.

Related reading

• Settlement Allocator Guide for Alabama
• Settlement Allocator Guide for Arizona
• Settlement Allocator Guide for Connecticut