Worked example: Alimony Child Support in Tennessee

Example inputs

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

This worked example shows how DocketMath can help you model alimony and child support obligations in Tennessee using jurisdiction-aware timing assumptions. This is not legal advice—it’s a practical walkthrough of what the tool does with common inputs, so you can sanity-check scenarios and ask better questions.

Scenario summary (Tennessee)

We’ll model a monthly obligation profile for a hypothetical Tennessee case with the following assumptions:

• Filing/start reference date: 2026-01-15
• Obligor (paying parent/spouse) gross monthly income: $6,500
• Obligee (receiving parent/spouse) gross monthly income: $4,000
• Number of children: 2
• Child-related input (typical): primary custody split modeled as “standard” for illustration
• Alimony type (modeled as a combined alimony/spousal support figure): included as a monthly amount scenario

Jurisdiction-aware timing assumption used in this example

No claim-type-specific sub-rule was found in the brief you provided, so this example uses the general/default limitations period you listed as the applicable rule throughout the model.

• General SOL Period: 1 year
• General statute cited: Tennessee Code Annotated § 40-35-111(e)(2)
• Source: https://law.justia.com/codes/tennessee/title-40/chapter-35/part-1/section-40-35-111/

Why this matters: DocketMath may label or flag modeled items based on whether they fall inside or outside a timing window (for example, “within” a limitations period). Since this example uses the general 1-year period (not a claim-type-specific period), the tool should consistently apply that general/default 1-year SOL constraint across the runs below.

Inputs you’d enter in DocketMath (illustrative)

In /tools/alimony-child-support, enter inputs like these (the names may vary slightly depending on the UI):

• Monthly gross income (Obligor): $6,500
• Monthly gross income (Obligee): $4,000
• Children: 2
• Alimony model monthly amount (scenario input, if supported):

  • Example alimony monthly amount: $800
• Start/reference date for the modeled obligation: 2026-01-15
• Jurisdiction: US-TN

To keep the setup consistent, use this checklist during data entry:

• Tennessee selected (US-TN)
• 2 children
• Both parties’ monthly gross income entered
• Reference date entered (2026-01-15)
• Alimony scenario monthly amount included ($800)

Example run

Here’s what to expect when you run the tool for this Tennessee scenario.

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 combines

A practical alimony + child support model usually includes:

1. Child support amount driven by the income inputs and the number of children (and any custody/parenting-time modeling inputs the tool allows).
2. Alimony amount either:

   • provided as a monthly scenario input (if the tool supports it this way), or
   • computed based on a selected alimony approach (depending on the tool’s configuration).

For this worked example, assume the run is configured to:

• compute a child support component, and
• include alimony as a monthly scenario input (since the goal here is to show a worked workflow rather than to recreate a single specific statutory numeric schedule).

Modeled limitations timing window (Tennessee)

Using the jurisdiction data provided, DocketMath applies:

• General SOL period: 1 year
• Statute: **Tennessee Code Annotated § 40-35-111(e)(2)
• Default application rule: because no claim-type-specific sub-rule was found, the tool uses the general/default 1-year period consistently across the model.

With a reference date of 2026-01-15, a general one-year window ends approximately:

• 2027-01-15

How to use this in the results: In DocketMath’s output, look for a time-window or an “applicability” label tied to the general limitations assumption. If you see different labels tied to a special claim type and your brief indicates none should be used, treat that as a sign to double-check your settings and assumptions for this scenario.

Example output structure (what you’ll typically see)

When you run the scenario, DocketMath commonly presents the results in component form, such as:

Even if the tool’s UI formats these differently, the key practical goal is the same: confirm that child support responds to income/children changes and that alimony responds to the alimony scenario input.

Sanity check on magnitude

Without hard-coding a statutory numeric schedule into the article itself, your “sanity check” is to verify consistency:

• If the obligor’s income increases, child support should not decrease (all else equal).
• If the number of children increases, child support should not decrease (all else equal).
• If you change the alimony scenario from $800 → $900, the total should typically rise by about $100/month, unless the tool uses interactions, caps, or rounding rules.

Sensitivity check

Use sensitivity checks to see how the results move when you change one input at a time. This is especially useful for validating that DocketMath is treating the variables the way you expect.

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 test A: Increase obligor income by $500/month

Change only:

• Obligor monthly gross income: $6,500 → $7,000
• Everything else stays the same (2 children, obligee income $4,000, alimony $800)

Expected directional outcome:

• Child support should increase (payor income increased).
• Total monthly obligation should increase.
• The general SOL timing window should not change because you did not change the reference date.

Quick checklist:

• Input changed only: obligor income (+$500)

Sensitivity test B: Change alimony scenario by $200/month

Change only:

• Alimony scenario: $800 → $1,000
• Income inputs and children unchanged

Expected directional outcome:

• Total monthly obligation should increase by about $200/month.
• The child support component should stay the same if the tool treats child support and alimony as separate lines without coupling.

Why this is useful:

• It confirms whether you should expect any blending or interaction between the two components in the tool’s modeling logic.

Timing sensitivity (SOL window) test: Move the reference date

Change only:

• Reference date: 2026-01-15 → 2026-07-15

Expected directional outcome:

• The end of the general 1-year window should move from about 2027-01-15 to about 2028-07-15.
• The monthly dollar amounts for alimony and child support should not change just because the date changed—unless the tool explicitly models date-dependent effects (e.g., proration or enforcement-window annotations).

Pitfall to avoid:

• People often accidentally change income and reference date together. Keep changes isolated so you can tell whether the output change is math-driven (income/alimony/children) or time-window driven (SOL label/window).

DocketMath workflow tip

If you’re running this interactively:

• Run the baseline scenario once.
• Duplicate the run for each sensitivity test (or re-enter inputs carefully).
• Record the deltas you observe:

  • Δ child support
  • Δ alimony
  • Δ total
  • any change to the timing label/window

When the tool’s timing labels reference the general 1-year period tied to Tenn. Code Ann. § 40-35-111(e)(2), the labels should remain consistent when you change income—but shift when you change only the reference date.

Related reading

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