How to run Damages Allocation in DocketMath for Montana

6 min read

Published April 15, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Damages Allocation calculator.

This guide walks you through running Damages Allocation in DocketMath for Montana (US-MT) using jurisdiction-aware rules. The goal is to help you generate a clear allocation workflow you can reuse for different case sets—without getting lost in configuration.

Note: This walkthrough uses Montana’s general/default statute of limitations approach because no claim-type-specific sub-rule was identified for the Damages Allocation calculation in this context. Montana’s general period in the provided materials is 3 years under Montana Code Annotated § 27-2-102(3).

1) Open the Damages Allocation calculator

  1. Go to the primary call-to-action: /tools/damages-allocation
  2. Confirm the calculator is set to Montana (US-MT).
    • If you see a jurisdiction selector, choose US-MT / Montana before entering damages details.

2) Enter case parameters

In most DocketMath workflows, you’ll enter a combination of:

  • Case timeline inputs (key dates)
  • Damages categories (amounts tied to damage types)
  • Any allocation drivers the calculator uses (depending on the template)

Use a quick checklist before typing values:

Create a quick checklist before typing values

  • Dates: incident date and filing date (or whatever date pair your interface requests)
  • Damage totals: amounts by category you want allocated
  • Constraints: caps, adjustments, or filters (if your jurisdiction-aware rules ask for them)

Tip: If you’re unsure which date field corresponds to the SOL start, pause here—mis-mapped dates are a common source of confusion later.

3) Make sure the Montana SOL rule is applied

Montana’s provided general statute of limitations for this guide is:

As you complete your inputs, look for a jurisdiction-aware status indicator such as:

  • “SOL rule: applied”
  • “Jurisdiction: US-MT”
  • “General/default period selected”

If your UI offers a rule selection, choose the general/default setting rather than any claim-type-specific option, since none was identified in the provided materials.

4) Run the allocation

Click Calculate / Run / Compute (the exact button label may differ).

DocketMath will typically generate:

  • An allocation breakdown by category
  • A summary of totals and any computed adjustments driven by timeline rules (including SOL logic, where applicable)

5) Review outputs and sanity-check the timeline impact

Even when the math is correct, outputs can look unexpected if the SOL “start” date and “end” date aren’t the ones you intended.

A practical way to verify SOL behavior is to compare your dates to the 3-year period:

  • If your filing date is more than 3 years after the relevant trigger date (as specified by the calculator), you may see results reflect SOL-driven reduction or flagging.
  • If your filing date is within 3 years, you should generally see full allocation (subject to other non-SOL adjustments your calculator applies).

If DocketMath displays a pass/fail or “eligible” indicator, treat that as the primary signal and cross-check the computed duration.

6) Iterate: update inputs and watch how outputs change

To build confidence, run several scenarios quickly and change one variable at a time:

Try a “base” run, then adjust one variable at a time:

  • Change filing date by 30–60 days
  • Change one damages category amount
  • Re-run to confirm:
    • category totals respond to damages inputs, and
    • SOL-related output responds to date changes

This helps you separate:

  • Allocation logic changes (driven by damage values and category structure) from
  • SOL-driven changes (driven by dates and the selected general/default rule)

Common pitfalls

Here are the most frequent issues people hit when running Damages Allocation for Montana (US-MT) in DocketMath.

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

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

1) Accidentally using a non-general SOL rule

Because this guide relies on the general/default period, selecting a claim-type-specific setting (if it exists in the UI) can misalign results.

  • Montana general SOL: 3 years
  • Authority: **Montana Code Annotated § 27-2-102(3)
  • Given constraint: no claim-type-specific sub-rule was identified in the provided materials

Pitfall: If you see an option labeled “specific claim type,” don’t assume it’s correct for your scenario. For this guide, keep the calculation on the general/default rule unless your inputs clearly support a different rule path.

2) Mixing up the “trigger” date and the “filing” date

Damages allocation outputs can look “wrong” even when math is right if the wrong date was used as the SOL reference.

Quick check

  • Confirm which date field represents the start of the SOL window (often incident/occurrence/trigger)
  • Confirm which date field represents the end (often filing/commencement)

3) Entering damage amounts that don’t reconcile

If category amounts don’t sum to your intended total, results can confuse downstream review.

Use a reconciliation step

  • ☐ Add category amounts manually
  • ☐ Compare the sum to any “total damages” field
  • ☐ Adjust before calculating again

4) Relying on the output without reading jurisdiction indicators

DocketMath’s jurisdiction-aware logic should show US-MT and SOL behavior in the results panel.

If you don’t see:

  • “Montana / US-MT”
  • “SOL rule applied” (or similar)
  • a computed timeline outcome

…re-check the jurisdiction and SOL rule settings before trusting the allocation.

5) Treating SOL flags as a substitute for full case analysis

This is about tooling workflow and output interpretation, not legal advice.

Warning: Statute of limitations outcomes can involve fact-intensive and rule-dependent questions. Use DocketMath to structure calculations, then review the underlying assumptions and dates carefully in the context of the actual case record.

Try it

Follow this short “muscle memory” exercise using your own numbers (or any set of dates you’re comfortable testing).

Open the Damages Allocation calculator and follow the steps above: Run the calculator.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Quick run checklist (Montana / US-MT)

  • ☐ Open /tools/damages-allocation
  • ☐ Confirm jurisdiction = US-MT
  • ☐ Ensure SOL setting = general/default 3-year period
  • ☐ Enter:
    • incident/trigger date
    • filing date
    • damages amounts by category
  • ☐ Click Calculate
  • ☐ Confirm outputs show:
    • allocation by category
    • any SOL-related eligibility/reduction indicator

Scenario toggles to validate the tool

Run these 3 variations:

  1. Within SOL: set the filing date clearly under 3 years from your trigger date
  2. Near SOL: set the filing date close to the 3-year boundary (a few days before/after, based on your workflow)
  3. Outside SOL: set the filing date clearly over 3 years

Then verify that:

  • Category totals respond to your damages inputs
  • The SOL-related output responds to the date changes

If results don’t behave like that, pause and re-check:

  • the date fields
  • the selected SOL rule (general/default)

Related reading