How to run Alimony Child Support in DocketMath for Minnesota

Step-by-step

Below is a jurisdiction-aware workflow for running Alimony (maintenance) and Child Support together in DocketMath for Minnesota (US-MN) using the DocketMath Alimony Child Support calculator.

Gentle note: This is a practical walkthrough of the tool’s inputs/outputs. It’s not legal advice.

Before you touch the calculator, collect these items:

• Minnesota jurisdiction selected (US-MN)
• Each adult’s income entered (as prompted for the scenario)
• Children counted correctly (make sure the count you enter matches who the support order is intended to cover)
• Marriage duration entered for maintenance modeling
• Maintenance posture selected/indicated as temporary / rehabilitative / permanent (the tool’s maintenance portion is modeled to reflect Minnesota’s discretionary structure)

1) Open the Minnesota calculator

1. Go to DocketMath: /tools/alimony-child-support
2. Confirm the jurisdiction is set to Minnesota (US-MN) so the calculator applies Minnesota-specific child support schedule logic and maintenance modeling.

2) Enter income inputs (child support portion)

In the calculator, you’ll enter each parent’s income and the number of children.

For the child support side, Minnesota uses the framework in Minn. Stat. § 518A.34, and the calculator matches your inputs to a schedule using combined monthly net tiers.

What to watch for in the tool’s outputs: child support changes are often driven by which combined monthly net tier your inputs land in (small income changes can shift the tier).

3) Understand how the Minnesota schedule “tiering” affects the output

After you enter incomes and children, DocketMath will compute the child support component using Minnesota’s schedule bracket behavior based on combined monthly net.

In the Minnesota configuration used by the tool, you’ll see schedule tiers with combined monthly net values such as:

• 1399, 1499
• 3999, 4499, 4999
• 5499, 5999
• 6099, 6999, 7999, 8999, 9999
• …up through 20000 (with schedule-capping behavior reflected by the tool’s settings)

The tool is also configured with:

• rules.schedule_table.*.combined_monthly_net tiers up to 20000
• a schedule cap setting: sub_rules.0.schedule_cap_combined_monthly_pics: 20000

Practical takeaway: if your calculated child support seems “jumpy” between reruns, it’s frequently because you crossed into a different combined monthly net tier.

4) Enter maintenance (alimony) scenario details

Maintenance in Minnesota is handled under Minn. Stat. § 518.552 and uses eight discretionary factors (meaning there isn’t a single statutory formula the way the child support schedule works).

In DocketMath, provide the maintenance-related inputs so the tool can place you in the appropriate modeled duration logic:

• Marriage duration (used for the maintenance duration tiers)
• Maintenance posture: temporary / rehabilitative / permanent

The maintenance modeling includes duration tier behavior such as:

• Long tier: minimum 20 years
• Mid tier: minimum 10 years and maximum 20 years
• Short tier: maximum 10 years

Practical interpretation: treat the maintenance number as a structured estimate based on the tool’s Minnesota model and scenario posture—especially because Minnesota maintenance is discretionary under Minn. Stat. § 518.552.

5) Confirm the minimum-order behavior

DocketMath applies a Minnesota minimum support order constraint:

• rules.minimum_support_order: 50

So if the child support portion of the estimate would otherwise come out extremely low based on your inputs, the output may reflect that minimum.

6) Review the combined outputs in DocketMath

After submission, review each portion:

• Child support (schedule-based behavior tied to Minn. Stat. § 518A.34)
• Maintenance (modeled using Minn. Stat. § 518.552’s discretionary structure)
• Whether DocketMath shows them separately or in a combined summary

If results feel inconsistent with your expectations, don’t change everything at once—use the focused adjustment approach below.

7) Adjust inputs with targeted changes (best debugging approach)

Use DocketMath’s UI to make one change at a time and observe which part moves.

High-leverage changes:

• Change income slightly → often shifts the child support output by moving you across a combined monthly net tier boundary.
• Change marriage duration tier or posture → typically shifts the maintenance output more than child support.

A good practice is to run:

• Scenario A (baseline): record child support and maintenance
• Scenario B (only one change): adjust only one lever (income or marriage duration or posture), then record what changed

This quickly tells you whether the difference you see is coming from the child support schedule logic or from the maintenance duration/posture modeling.

Common pitfalls

Avoid these Minnesota-specific mistakes when running Alimony Child Support in DocketMath:

• Mismatched jurisdiction

  • If you run under the wrong jurisdiction, DocketMath may use the wrong child support schedule logic. Minnesota schedule behavior is tied to Minn. Stat. § 518A.34.

• Assuming maintenance is formula-driven

  • Minnesota maintenance is governed by Minn. Stat. § 518.552 and is discretionary (it’s modeled using scenario inputs rather than a single deterministic formula).
  • The tool can still generate a modeled estimate, but it won’t behave like a pure “solve-for” equation.

• Crossing child support schedule tiers unintentionally

  • Child support is sensitive to combined monthly net tier placement (examples in the tool include 1399 → 1499 and other nearby brackets).
  • Small input changes can cause a noticeable jump.

• Forgetting the minimum-order constraint

  • If your computed child support is low, the tool uses a minimum support order of 50 (rules.minimum_support_order: 50), which can make results appear higher than expected relative to your intuition.

• Not aligning maintenance posture with the story you’re modeling

  • DocketMath’s maintenance modeling reflects that maintenance may be temporary, rehabilitative, or permanent (sub_rules.2.duration_limitations), consistent with Minnesota’s discretionary structure under Minn. Stat. § 518.552.
  • If you pick a duration posture that doesn’t match your intended scenario, maintenance output may not match your expectation.

Try it

Use this quick “sanity check” workflow in DocketMath:

1. Run one baseline scenario

   • Record the child support result and the maintenance result separately.
2. Increase only one parent’s income

   • Re-run and confirm:

     • child support shifts in a schedule-aware way (tier behavior based on combined monthly net)
     • maintenance may change only if your scenario posture/duration inputs changed (otherwise it should remain driven primarily by maintenance-specific inputs)
3. Run a second scenario with marriage duration only

   • Keep incomes the same
   • Adjust marriage duration (move between short/mid/long as your scenario requires)
   • Confirm maintenance changes while child support remains stable (unless you accidentally modified income or the number of children)

When you compare outputs side-by-side, you’re looking for consistency patterns:

• Child support should track combined-net tier changes.
• Maintenance should track your duration tier/posture modeling.

Primary CTA: Start with the Minnesota calculator here: /tools/alimony-child-support

Related reading

• How Alimony Child Support rules vary in New York — What varies by jurisdiction
• How to calculate Alimony Child Support in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Alimony Child Support in Philippines — Worked example with real statute citations