Worked example: Alimony Child Support in Kansas

6 min read

Published April 15, 2026 • By DocketMath Team

Example inputs

This worked example shows how DocketMath calculates a Kansas-style “alimony + child support” worksheet using jurisdiction-aware rules. It’s a demonstration of the workflow and the math—not legal advice.

Because your jurisdiction data provided only a general/default period rule (and explicitly no claim-type-specific sub-rule), we treat the general rule as the applicable default for the referenced “general SOL period” item:

Note: No claim-type-specific sub-rule was found, so the general/default period applies in this example.

Scenario (Kansas, US-KS)

Assume the following facts for a monthly worksheet:

Parties’ income

  • Payor gross monthly income: $6,500
  • Payee gross monthly income: $4,200

Parenting / children

  • Number of children: 2
  • Overnight parenting days for payor: 146 (about half the year)

**Spousal support (alimony) input (worksheet-based)

  • Requested spousal support: $650/month
  • Basis: using the calculator’s inputs to model “alimony + child support” together

DocketMath settings

  • Jurisdiction: **US-KS (Kansas)
  • Calculator module: alimony-child-support

Worksheet assumptions you can change

To make this example useful, here are the inputs that typically move the result the most:

  • Income levels (payor vs. payee)
  • Number of children
  • Parenting time split
  • Requested alimony amount (if you’re modeling a proposed figure)

In Kansas, the general statute citation provided for the “general SOL period” item is:

You’ll see that reflected later in the sensitivity check as an “out-of-month” timing variable—not in the core monthly support arithmetic.

Example run

Use DocketMath’s alimony-child-support tool here: /tools/alimony-child-support

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.

Step-by-step (what you enter)

Check these items in the tool:

Then click calculate.

Example output (illustrative worksheet math)

When DocketMath runs, it produces a combined monthly figure broken into components.

Because different DocketMath jurisdictions can structure outputs differently, this example describes the output using a common “worksheet component” format:

ComponentExample valueWhat it represents
Child support (monthly)$1,380Monthly child support component based on inputs
Alimony / spousal support$650Monthly modeled spousal support figure
Combined monthly total$2,030Total “alimony + child support” output

How Kansas-specific timing is handled (SOL “general/default” rule)

Your jurisdiction data specifies a General SOL Period: 0.5 years and cites K.S.A. § 21-6701 as the general/default reference, with no claim-type-specific sub-rule identified.

In practice, that means if the calculator or worksheet is also tracking a timing window for some downstream step (for example, a “general timing” control), it will use:

  • 0.5 years (default period)
  • governed by the general reference K.S.A. § 21-6701

Here’s the direct mapping from your provided data:

Timing controlDefault usedSource
General SOL period0.5 yearsProvided jurisdiction data
Statutory referenceK.S.A. § 21-6701https://www.kslegislature.gov/li/s/statute/021_000_0000_chapter/021_067_0000_article/021_067_0001_section/021_067_0001_k.pdf?utm_source=openai

Warning: A “general SOL period” is not the same thing as a monthly support amount. Even if the tool uses the SOL timing as a separate control, you should keep track of what is being timed versus what is being calculated monthly.

Combined monthly total

From the table above, the worked example yields:

  • Combined monthly total: $2,030/month

If you later adjust alimony or child support drivers, this number changes immediately while the timing control remains governed by the general/default SOL reference unless the tool surfaces a claim-type-specific rule (none was identified in your provided data).

Sensitivity check

Change one input at a time to see what moves the combined total.

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.

1) Change alimony amount by $250

Keep everything else the same, but set:

  • Alimony modeled: $900/month (instead of $650)

Expected effect (simplified for this sensitivity test):

  • Child support component stays $1,380
  • Combined total becomes: $1,380 + $900 = $2,280/month

Result shift

  • Increase: +$250/month
  • Combined total: $2,030 → $2,280

Checklist:

  • Parenting time unchanged
  • Income unchanged
  • Children unchanged
  • Only alimony changed

2) Change number of children (2 → 3)

Assume:

  • Children: 3
  • Parenting time: unchanged
  • Income: unchanged
  • Alimony: $650

In many support formulas, adding a child increases the child support component. For this sensitivity demonstration, suppose the calculator returns:

  • Child support (monthly): $1,900
  • Alimony: $650

Then:

  • Combined total: $2,550/month

Result shift

  • Increase: +$520/month
  • Combined total: $2,030 → $2,550

Checklist:

  • Alimony unchanged
  • Parenting time unchanged
  • Income unchanged
  • Children changed

3) Income sensitivity (payor income down by 10%)

Reset to the baseline scenario (2 children; 146 days; alimony $650), then change:

  • Payor income: $6,500 → $5,850 (10% decrease)

If DocketMath recalculates child support to (illustratively):

  • Child support (monthly): $1,120
  • Alimony: $650

Then:

  • Combined total: $1,770/month

Result shift

  • Decrease: -$260/month
  • Combined total: $2,030 → $1,770

4) Timing sensitivity: SOL “general/default” stays fixed

Even if monthly numbers move with income/children, the provided SOL timing control stays:

  • 0.5 years
  • K.S.A. § 21-6701
  • no claim-type-specific sub-rule identified in the jurisdiction data

So in this example, changing monthly support inputs does not alter the SOL timing setting—because it’s a separate “general/default period” control.

Pitfall: Mixing timing and amount. A worksheet might show both (1) a monthly support number and (2) a timing parameter such as a general limitations window. The former responds to income/children; the latter responds to the statutory rule selection, not the monthly support inputs.

Related reading