How to run Settlement Allocator in DocketMath for Montana

How to run Settlement Allocator in DocketMath for Montana

6 min read

Published July 26, 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

Below is a practical walkthrough for running Settlement Allocator in DocketMath for Montana (US-MT). This process is designed to apply jurisdiction-aware rules, including Montana’s default statute of limitations framework where relevant.

  • Select Montana in the Settlement Allocator tool.
  • Enter the trigger dates and any caps or rates.
  • Run the calculation and save the output.

1) Open the correct tool

  1. Go to DocketMath → Settlement Allocator.
  2. Use this primary CTA to jump straight there: /tools/settlement-allocator.
  3. Confirm the jurisdiction is set to Montana (US-MT). If your interface supports jurisdiction switching, select Montana before entering any case details.

2) Gather the minimum inputs you’ll need

Settlement Allocator works best when you provide the settlement-related fields it uses to allocate amounts across components. While DocketMath’s exact field labels can vary slightly, your workflow typically looks like this:

  • Settlement total (the gross settlement amount being allocated)
  • Allocation components (the categories you want DocketMath to distribute across—commonly things like economic damages, non-economic damages, and/or other stated buckets)
  • Dates needed for jurisdiction-aware logic (for Montana, you’ll frequently use key case dates so the tool can align outputs with the relevant time window)

If your screen includes date fields, pull from your case timeline, such as:

  • incident date / accrual date (if asked)
  • filing date (if asked)
  • settlement agreement date (if asked)

Note: Settlement Allocator’s Montana behavior uses the general/default statute of limitations period because no claim-type-specific sub-rule was found for this calculator workflow. That means the tool is applying the general rule, not a specialized one.

3) Understand Montana’s default SOL rule DocketMath is using

For Montana, the General SOL Period is 3 years, based on Montana Code Annotated § 27-2-102(3).

  • Montana Code Annotated § 27-2-102(3) provides a 3-year general statute of limitations for many civil claims.
  • This workflow uses the general/default period (not a claim-type-specific exception), consistent with the “no claim-type-specific sub-rule found” note for this setup.

When Settlement Allocator prompts for timeline inputs, its allocation outputs may change depending on whether key dates fall within that 3-year window or outside it. In plain terms: the placement of dates can shift the tool’s recommended logic, even if your settlement total stays the same.

4) Enter your Montana data

Now input your values into DocketMath:

  • Enter the settlement total
  • Enter each allocation bucket you want DocketMath to compute
  • Populate all date fields the tool requests

As you type:

  • Watch for inline validation (for example, date order checks like “filing date cannot be earlier than incident/accrual date,” if your interface uses those constraints)
  • Ensure the dates are in the format the tool expects

5) Run the allocator and review outputs

Once you submit:

  • DocketMath will generate allocation results across the components you provided or that it infers from your inputs.
  • Review:
    • Allocated amounts per category
    • Any jurisdiction-aware warnings related to Montana’s 3-year general statute of limitations (for example, if the tool detects a timeline outside that window)

If your outputs include a summary section, cross-check that:

  • The sum of allocated components equals (or appropriately reconciles with) the settlement total.
  • Any date-driven flags align with your case timeline.

6) Adjust inputs to see how outputs change

This is where you get the most value quickly. Try changing one variable at a time:

  • If you move the “key date” closer to (or farther from) the 3-year mark, you should see date-driven logic change.
  • If you change the allocation bucket definitions (or enter different component amounts), you should see distribution changes while the Montana default SOL logic remains the same.

Make 2–3 “what if” runs so you can understand which fields most affect outcomes:

  • Scenario A: key date within 3 years
  • Scenario B: key date near the 3-year threshold
  • Scenario C: key date outside 3 years

7) Export or document your results

If DocketMath provides download/export features, save:

  • the allocation report
  • the input set you used (so you can reproduce results)
  • any flags or notes shown with the calculation

This helps you keep consistent records for internal workflows.

8) Keep the limitation in view (gentle disclaimer)

DocketMath’s calculators can help structure inputs and produce allocation estimates, but they don’t replace legal review. Settlement allocations can have serious downstream consequences depending on the claim, documentation, and applicable law. Use the tool’s outputs as a structured starting point and confirm alignment with your case materials and applicable rules.

Common pitfalls

Settlement allocation work often fails due to mismatched inputs, date errors, or incorrect assumptions about which legal time rules apply. For Montana specifically, the biggest pitfalls tend to look like this:

  • Using the wrong statute time window

    • Montana’s general rule here is 3 years under Montana Code Annotated § 27-2-102(3).
    • Because no claim-type-specific sub-rule was found for this workflow, don’t assume the tool is applying a different SOL period for a specific claim category.
  • Entering inconsistent dates

    • A filing date before an accrual/incident date can cause validation issues or logic flags.
    • Entering dates that don’t correspond to what the tool expects (for example, using a date that isn’t the “key date” referenced in the workflow) can produce misleading results.
  • Forgetting that allocation totals must reconcile

    • If you adjust component buckets without keeping track of totals, you may end up with outputs that don’t cleanly match the settlement total.
    • Always confirm the sum of allocated components reconciles as the tool reports.
  • Treating jurisdiction logic as claim-type logic

    • DocketMath uses jurisdiction-aware rules for US-MT.
    • In this Montana setup, the default SOL used is the general 3-year period; jurisdiction-aware does not automatically mean the tool is selecting claim-type-specific limitations logic.

Warning: Don’t rely on Settlement Allocator output as a definitive legal conclusion about timeliness for a specific cause of action. The calculator can only apply the rules built into the workflow—here, the general/default 3-year SOL referenced in Mont. Code Ann. § 27-2-102(3).

Try it

To test the workflow quickly:

  1. Set jurisdiction to **Montana (US-MT)
  2. Run three calculations using the same settlement total and the same allocation buckets, changing only one variable:
    • Key date within 3 years of the reference point used by the tool
    • Key date near the 3-year boundary
    • Key date beyond 3 years

Then compare:

  • Whether the tool flags an SOL-related condition
  • How the allocated categories shift when the timeline crosses the 3-year general SOL boundary under **Montana Code Annotated § 27-2-102(3)

For an easy internal check, record the inputs for each run:

  • Settlement total: (same in all runs)
  • Allocation buckets: (same in all runs)
  • Date field(s): (the only change)

This gives you a clean “cause and effect” view of what the calculator is reacting to.

Related reading