Common Damages Allocation mistakes in Montana

The top mistakes

Run this scenario in DocketMath using the Damages Allocation calculator.

Damages allocation errors can cost time—and sometimes money—in Montana cases because they distort what each claim (and each party) is actually “worth” for settlement leverage, mediation posture, and downstream payment calculations. DocketMath’s damages-allocation calculator helps you structure those numbers, but the most common mistakes are usually about jurisdiction-aware setup and input discipline rather than arithmetic.

Below are the most frequent damages allocation mistakes we see in Montana (US-MT) workflows.

1) Using the wrong statute of limitations for the underlying claim

Montana generally uses a 3-year statute of limitations for many civil actions. For limitations timing, the default period is stated in Montana Code Annotated § 27-2-102(3) (general SOL).

Because DocketMath often sits next to claim-viability steps, this error can cascade: you may allocate damages under an assumption that the claim is timely, only to later discover it may be time-barred.

Common failure mode

• You model damages as if the claim is timely, then learn the underlying cause of action is outside the 3-year window.
• The allocation may look precise, but it supports the wrong legal posture.

2) Mixing economic damages and non-economic damages into one bucket

In DocketMath’s damages-allocation flow, separating damage types matters because each bucket typically has different documentation expectations.

A frequent allocation error is collapsing:

• medical expenses, lost wages, out-of-pocket costs (economic)
• pain, suffering, and other non-economic impacts (non-economic)

into a single number early in the workflow.

Why it breaks

• The output becomes harder to validate.
• You can’t easily test “what changes if wage-loss proof is partial?” or “what changes if some medical bills are excluded?”

3) Over-crediting or double-counting overlapping expenses

Double-counting usually appears as one of these patterns:

• Insurance reimbursements counted twice (once as payments received and again as “outstanding”)
• Bills entered in both paid and unpaid form
• The same expense entered in two categories (for example, transportation to treatment included once as a travel line item and again inside a larger medical subtotal)

A simple rule keeps you out of trouble: each dollar should map to exactly one place in your DocketMath inputs.

4) Using inconsistent dates across your inputs and interpretation

Damage totals change depending on date logic. A common error is allocating using one date basis, then interpreting outputs using another.

Examples:

• medical bills entered by paid date, but damages interpreted by service date
• wage-loss entered by pay date, but the loss period framed by missed work weeks (calendar-based)

This often creates subtle allocation drift—especially when later reconciling to a demand letter or a billing summary.

5) Structuring allocations in a way that doesn’t match how proof is organized

Even without offering legal advice, you can reduce avoidable negotiation friction by aligning your allocation categories with how your documents are organized:

• receipts/invoices/statements for economic items
• medical records or treatment notes for causation-linked items
• wage statements for lost income

If your DocketMath inputs don’t mirror your proof plan, you may end up redoing the allocation after discovery or during settlement discussions.

6) Treating DocketMath outputs as “final” without any sensitivity checks

Allocations rarely hold perfectly once records are incomplete. Accepting one total as fixed can cause you to miss how small input changes affect the outcome.

Common sensitivity problems:

• missing a month of wage statements
• excluding a subset of medical bills
• using estimates where documentation exists (or the reverse)

To avoid this, rerun DocketMath with conservative assumptions and compare totals.

Primary action: start with /tools/damages-allocation. You can also cross-check other workflows from /tools.

How to avoid them

You can reduce Montana damages allocation mistakes by tightening your workflow around (1) jurisdiction-aware legal timing assumptions and (2) disciplined, testable inputs.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Lock the Montana general SOL assumption up front

Before doing heavy allocation math, set your baseline timing assumption using:

• Montana general SOL: 3 years
• MCA § 27-2-102(3) (general default)

In practice, treat this as a gating question:

• If the underlying event occurred more than 3 years before filing (or before the relevant accrual trigger, depending on the facts), your damages allocation strategy may not be worth the effort under the default assumption.

If later you confirm a claim category-specific Montana rule, update the model.

Step 2: Separate damage buckets before you total anything

In DocketMath, keep economic and non-economic components distinct until the final summary.

Practical checklist:

Step 3: Use a “no double count” convention—and enforce it

Adopt one convention and keep it consistent throughout your inputs. For example:

• Convention A: Paid amounts go in “Payments received,” not in “Medical damages”; unpaid bills go in “Outstanding medical.”
• Convention B: Enter net out-of-pocket amounts (what the claimant actually paid) and avoid also entering gross bills.

Then reconcile internally:

Step 4: Standardize dates across inputs

Pick one date basis for the allocation, such as:

• service/incurred dates (medical and treatment)
• loss period dates (wage-loss)
• payment dates (only if your proof supports tying damages to cash flow)

Then ensure your DocketMath entries follow that same basis. Quick validation:

Step 5: Use DocketMath for scenario comparisons, not just one number

DocketMath is most effective when you treat outputs as a range. Run at least two versions:

• Conservative model: exclude questionable or partially documented items
• Documented model: include only items you can support cleanly

Compare totals and note what changed. This makes it easier to explain adjustments without rebuilding the entire allocation.

Step 6: Connect outputs to your proof plan

Your DocketMath totals should map back to what you have:

Gentle caution: If your DocketMath allocation totals don’t reconcile to your billing/wage summary within a small tolerance (often ±1–3 line items or rounding differences), treat it as an inputs/model issue first, not a proof issue—until you fix the inputs.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules