Common Alimony Child Support mistakes in South Dakota

The top mistakes

Run this scenario in DocketMath using the Alimony Child Support calculator.

If you’re using DocketMath in South Dakota (US-SD) to model an alimony + child support scenario, these are some of the most common mistakes that can create incorrect expectations—especially when you’re working from incomplete records or you’re unsure how specific inputs flow into outputs.

1) Using stale income numbers (or the wrong time window)

Child support and alimony calculations are extremely sensitive to income. A frequent error is plugging in income that doesn’t match the most supportable period, such as:

• outdated pay stubs,
• last-year income when your earnings changed,
• income that includes one-time items (like a bonus received once), or
• income that doesn’t match what you can document.

What goes wrong in your model: DocketMath’s outputs can move materially when income inputs change. If your income number doesn’t match the period you can support with records, the modeled obligation may be very different from what could be argued or ordered.

Checklist:

• Use a consistent window (often recent pay stubs).
• If income is variable, consider base wages separately from variable/irregular items.
• Keep documentation for every income figure you enter.

2) Forgetting that child support and alimony are not interchangeable

Another common error is treating alimony as though it “replaces” child support, or informally netting the two streams together in your mind without testing them separately.

What goes wrong in your model: DocketMath generally separates the assumptions and outputs for alimony and child support. If you collapse them mentally into one bucket, you may:

• misunderstand the total monthly burden, or
• miss how a change affects one stream more than the other.

Quick test: When you run multiple scenarios, confirm you’re comparing:

• “child support only” changes, and
• “alimony only” changes,

rather than only looking at the final combined number.

3) Misreading output timing (monthly vs. annualized assumptions)

People often mix:

• monthly obligations with annual income assumptions, or
• annual costs with monthly support estimates.

What goes wrong in your model: Even with correct numbers, a unit mismatch can skew affordability. For example, if you input monthly income but later interpret outputs as though they’re annual (or vice versa), you can overstate or understate what the numbers represent.

Checklist:

• In DocketMath, verify whether income inputs are treated as monthly or annual.
• Match the unit of comparison: if you enter monthly income, compare monthly totals.

4) Omitting parenting-time details when running scenarios

Parenting-time assumptions can materially affect child support modeling. A frequent problem is running a scenario without the custody/visitation structure you actually have (or the one you’re trying to model).

What goes wrong in your model: If the parenting-time assumption is off, your estimate may be systematically biased—especially when you’re comparing “current arrangement” to a “proposed arrangement.”

Checklist:

• Keep parenting-time structure explicit and accurate for each DocketMath run.
• When changing parenting time, treat it as a major scenario variable, not a minor edit.
• If possible, run separate scenarios rather than averaging expectations.

5) Not tracking deductions and health insurance costs consistently

Medical support can hinge on how health insurance and related costs are handled. Many people model health coverage inconsistently—either including it in one place but not another, or applying it to the wrong category.

What goes wrong in your model: If DocketMath expects a cost to be entered in a specific field/category, putting it in the wrong place can distort the result. Inconsistent insurance assumptions across scenarios can also make it harder to tell which input is driving differences.

Checklist:

• Enter health insurance costs in the correct category/field based on what DocketMath requests.
• Keep the insurance assumption the same across scenarios when you’re measuring the impact of a different variable.
• If your inputs change (e.g., switching plans), record what changed and why.

6) Missing the statute-of-limitations deadline for enforcement issues

When people think about “what can still be pursued,” they sometimes assume timing won’t matter. In South Dakota, a general limitations framework can still be important—especially for enforcement-related questions.

South Dakota provides a general statute of limitations (SOL) period of 3 years under SDCL 22-14-1. No claim-type-specific sub-rule was found in the provided jurisdiction data for a different limitations period—so the 3-year general/default period is the baseline referenced here.

What goes wrong in your model: Even if the math looks favorable, an action can fail if it’s not brought within the relevant timing limits.

If you’re starting from the tool itself, you can use DocketMath here: /tools/alimony-child-support.

How to avoid them

Use DocketMath like a structured worksheet: prioritize accurate inputs, consistent assumptions, and careful scenario comparisons. Below are practical steps tailored to South Dakota (US-SD) modeling.

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: Build a single source-of-truth income packet

Before running scenarios, create a mini “income dossier,” such as:

• the last 3–6 months of pay stubs (or the closest consistent window),
• relevant tax return pages you plan to rely on (if applicable),
• documentation for variable income components (overtime, commissions, bonuses, etc.).

Then, in DocketMath:

• enter income using consistent time windows across scenarios,
• if income changes, run separate scenarios labeled clearly (for example: “current earnings” vs. “projected income”).

Step 2: Keep parenting-time assumptions explicit

For each DocketMath run:

• confirm the schedule assumption matches the arrangement you want to model,
• when comparing “before vs. after,” run separate scenarios rather than blending assumptions,
• treat parenting time as a key driver rather than a minor detail.

Step 3: Normalize units and compare like-to-like

Before comparing results across scenarios:

• confirm monthly vs. annual income inputs,
• confirm monthly vs. annual cost inputs (including insurance),
• ensure you’re comparing outputs in the same timeframe (e.g., monthly totals to monthly totals).

A practical method:

• In each scenario pair, change only one input (such as health insurance amount) and verify that the output difference aligns with that change.

Step 4: Audit categories—especially health insurance and recurring deductions

Do a quick, consistent audit after each run:

• “Where did health insurance go in the tool?”
• “Is it the same in every scenario I’m comparing?”
• “Did I enter it into the field/category the tool is designed to treat that way?”

This helps prevent accidental distortions caused by inconsistent categorization.

Step 5: Use the SOL baseline when planning enforcement timing

If your question involves timing (for example, whether something can still be enforced or challenged), anchor your planning to the baseline that’s supported by the jurisdiction data you have:

• SDCL 22-14-1 provides the general 3-year limitations period
• Based on the provided jurisdiction data, no alternate claim-type-specific period is identified here, so 3 years is the general/default baseline referenced.

Reminder: This is a general planning reference and not legal advice. If timing is critical, consider consulting a qualified attorney.

Related reading

• Alimony & Child Support Estimator Guide for Alabama
• Alimony & Child Support Estimator Guide for Arizona
• Alimony & Child Support Estimator Guide for Colorado