Worked example: Alimony Child Support in Montana
6 min read
Published April 15, 2026 • By DocketMath Team
Example inputs
Run this scenario in DocketMath using the Alimony Child Support calculator.
This worked example shows how DocketMath could estimate alimony and child support in Montana (US-MT). It’s meant for understanding the workflow and jurisdiction-aware rule handling—not legal advice.
Scenario (fictional facts)
Assume the court must consider both:
- Child support for 2 children, and
- Alimony (spousal support) in addition to child support.
Inputs you would enter in DocketMath (US-MT)
In /tools/alimony-child-support, select jurisdiction US-MT, then fill in the inputs that match your facts. If the tool’s UI has additional fields, you can leave them blank if they aren’t relevant to this scenario.
- Payor (parent/spouse) gross monthly income: $5,800
- Payor (parent/spouse) health insurance premium (monthly): $200
- Payor monthly work-related childcare: $350
- Payee gross monthly income: $3,900
- Number of children: 2
- Shared/overnights arrangement: “Standard” (choose the closest option in the tool)
- Requested alimony term (if applicable): “Ongoing/indefinite” (choose the closest matching option in the tool)
- Any existing support orders: $0
- Any other documented monthly income adjustments: $0
Jurisdiction-aware timing rule (general limitations concept)
This example also demonstrates how DocketMath may display jurisdiction-aware timing language in a case-planning context that relies on statutory deadlines.
For Montana, the general/default statute of limitations period is:
- General SOL period: 3 years
- General Statute: Montana Code Annotated § 27-2-102(3)
Important scope note: The brief you provided indicates that no claim-type-specific sub-rule was found. So this post treats § 27-2-102(3) as the general/default period—not as a specialized deadline for support-related claims.
Note: For limitations/statute-of-limitations timing, the calculator’s output is for planning and illustration only. Deadlines can vary based on claim type, procedural posture, and the specific statute that governs. Confirm the controlling authority for your situation.
Example run
- Open DocketMath: /tools/alimony-child-support
- Select jurisdiction: US-MT
- Enter the Example inputs listed above
- Run the calculation
Run the Alimony Child Support calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.
What DocketMath returns in this run (illustrative output)
Because the tool is designed to apply jurisdiction-aware logic and uses the values you enter, the results should change when you adjust income, number of children, and deductions/credits like insurance and childcare.
For this example set of inputs, assume DocketMath produces an output structure like:
| Output category | Estimated monthly amount |
|---|---|
| Child support (2 children) | $1,250 |
| Alimony (spousal support) | $650 |
| Total estimated support | $1,900 |
If the tool provides a assumptions/breakdown section, look for details such as:
- how it treated health insurance ($200/mo),
- how it treated childcare ($350/mo),
- how it accounted for the income difference between payor ($5,800) and payee ($3,900),
- and how the overnights/placement setting (“standard”) was used.
Quick check: why these numbers move
In many support models, the most influential inputs are:
- Income difference (payor vs. payee),
- child count (here, 2),
- time allocation (overnights/placement—here, “standard”),
- and adjustments (health insurance and childcare).
A common pattern in these estimates:
- Child support often represents the larger share because it scales with children and time allocation.
- Alimony may then add an additional monthly amount based on the tool’s alimony logic and the selected term option.
Pitfall to avoid: If any field in the tool asks for monthly income, don’t enter annual income unless the UI explicitly says it converts. Monthly vs. annual mistakes can cause results that look reasonable but are off by a factor of 12.
Sensitivity check
The goal of a sensitivity check is to identify which factual changes most affect the estimate. Try changing one input at a time to see the direction and approximate magnitude of the change.
To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.
Sensitivity A: Increase payor income by $500/month
Change only:
- Payor gross monthly income: $5,300 → $5,800 (+$500)
Expected change:
- Child support likely increases because the payor has more ability to pay.
- Alimony may also increase, depending on how the tool models income disparity and support purpose.
Illustrative result pattern:
- Child support: $1,250 → $1,320 (+$70)
- Alimony: $650 → $690 (+$40)
- Total: $1,900 → $2,010 (+$110)
Sensitivity B: Add one more child (from 2 to 3)
Change only:
- Number of children: 2 → 3
Expected change:
- Child support typically increases more than alimony because child support is tied directly to eligible children and the time allocation setting.
Illustrative result pattern:
- Child support: $1,250 → $1,600 (+$350)
- Alimony: $650 → $700 (+$50)
- Total: $1,900 → $2,300 (+$400)
Sensitivity C: Reduce childcare expense by $200/month
Change only:
- Work-related childcare: $350 → $150 (−$200)
Expected change:
- Child support may decrease if the tool credits/allocates childcare expense in the relevant calculation steps.
- Alimony could also shift, depending on whether the tool incorporates those expenses in its model.
Illustrative result pattern:
- Child support: $1,250 → $1,200 (−$50)
- Alimony: $650 → $640 (−$10)
- Total: $1,900 → $1,840 (−$60)
Jurisdiction-aware timing context (Montana general SOL concept)
If you’re using a broader case-management workflow to think about deadlines, Montana’s general limitations period is:
- 3 years under Montana Code Annotated § 27-2-102(3)
Default limitation timeframe used for planning (general only):
- 3 years from the relevant triggering event (you must identify the triggering event for your case)
Key limitation: This is the general/default period. It does not claim a specialized deadline for a particular category of claim because no claim-type-specific sub-rule was provided in the brief.
Warning: A general SOL period can’t automatically be applied to every dispute type. Filing deadlines often depend on the cause of action and the specific statutory framework that governs the request.
Practical “input audit” checklist
Before relying on estimates, verify: