Worked example: Alimony Child Support in Georgia

Example inputs

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

This worked example shows how DocketMath can help you run an alimony + child support calculation flow for Georgia (US-GA) using jurisdiction-aware rules. It’s meant to be practical and actionable, but it’s not legal advice and it’s not a promise of how a court will rule.

Scenario assumptions (invented for illustration)

You’ll need a fact pattern to enter numbers. For this example:

• Filing/processing jurisdiction: Georgia (US-GA)
• Case posture: calculation inputs only (not an order)
• **Income (annual)

  • Payor gross income: $90,000
  • Payee gross income: $45,000
• Children

  • Number of children: 2
  • Shared custody: 0 nights for the payor (so, for this example, the payor is treated as the “non-custodial” parent)
• Deductions / adjustments

  • Healthcare / other adjustments: 0 (kept simple)
• **Alimony type (how to think about it)

  • Georgia judges have authority to award alimony based on statutory criteria. Because this is a tool run, the main goal here is to show how input choices flow through the tool—not to predict an outcome.

Tool inputs you would enter in the calculator

Start from the tool page here: /tools/alimony-child-support.

In a typical DocketMath workflow, you provide inputs such as:

• Payor income
• Payee income
• Number of children
• Parenting time / custody-related timing inputs
• Any toggles or fields for adjustments

Because exact UI labels can vary by calculator configuration, treat the table below as the conceptual inputs for this worked example:

Example run

Below is a walk-through of a single DocketMath run using the Georgia jurisdiction code US-GA.

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 1: Confirm the jurisdiction rules pack

DocketMath uses the jurisdiction selection to apply jurisdiction-aware logic. For this example:

• Jurisdiction code: **US-GA (Georgia)
• Jurisdiction data note: No claim-type-specific sub-rule was found in the provided dataset, so the tool uses the general/default rule for the cited time limitation.

Step 2: Run the combined flow (child support + alimony)

Conceptually, DocketMath will:

1. Compute the child support component using the custody/children inputs and income figures.
2. Compute the alimony component using the alimony-related inputs and the income assumptions.
3. Output a combined monthly figure, and typically a breakdown.

Since exact internal outputs depend on how the calculator’s configured formula set maps to the inputs you enter, the most useful way to read this worked example is by focusing on the relationship between what you change and what the tool moves.

Example results (replace with your actual run)

Because this is a worked example, your actual numbers will depend on the calculator’s current configuration and exactly how it interprets each field you enter. A common illustrative structure looks like:

• Estimated child support (monthly): $X
• Estimated alimony (monthly): $Y
• Total support (monthly): $X + $Y

If DocketMath shows specific numeric amounts, copy them into the sensitivity check tables below so you can compare movements precisely.

Step 3: Time-limitation awareness (Georgia general SOL)

This example also highlights a jurisdiction-awareness detail: Georgia’s general statute of limitations uses the general/default period, because no claim-type-specific sub-rule was found.

• General SOL period: 1 year
• General statute: O.C.G.A. § 17-3-1
• Source: https://law.justia.com/codes/georgia/2021/title-17/chapter-3/section-17-3-1/?utm_source=openai

Important clarity: The 1-year figure above is the general/default period from the jurisdiction data provided. It is not claim-type-specific here, because no claim-type-specific sub-rule was identified in the input set.

Sensitivity check

After you get a baseline run, the fastest way to understand how DocketMath is responding is to change one input at a time and observe which component moves: child support, alimony, or both.

Below are three practical sensitivity checks. For each test, keep everything else the same and only change the highlighted input.

Sensitivity check A: Change payor income by 10%

Why: both child support and alimony computations often respond to income levels.

• Baseline: payor income $90,000
• Test: increase to $99,000 (+10%)

What to look for in the DocketMath output

• Child support may increase if the calculator uses income to compute support obligations.
• Alimony may increase depending on how the tool translates income ratios and alimony thresholds.

Checklist

Sensitivity check B: Change the number of children (2 → 3)

Why: child support is directly tied to children count in most guideline-based frameworks.

• Baseline: 2 children
• Test: 3 children

What to look for

• Expect the child support portion to change more than the alimony portion (alimony may be driven by financial circumstances rather than a strict per-child increment, depending on the tool’s logic).

Checklist

Sensitivity check C: Adjust parenting time (0 nights → 30 nights)

Why: parenting time often changes the basis for the support calculation.

• Baseline: payor parenting time 0 nights
• Test: payor parenting time 30 nights

What to look for

• Child support could decrease if the tool treats the payor as bearing more of the child’s direct time-related costs.
• Alimony may shift slightly (or not), depending on how the tool treats parenting time.

Checklist

Mini interpretive table (fill in with your DocketMath output)

Related reading

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