Worked example: Alimony Child Support in Florida
6 min read
Published April 15, 2026 • By DocketMath Team
Example inputs
Run this scenario in DocketMath using the Alimony Child Support calculator.
Below is a worked example showing how DocketMath’s alimony-child-support calculator can combine Florida inputs to produce an illustrative “run.” This walkthrough is not legal advice—it’s a practical illustration of how you might model numbers in a jurisdiction-aware tool.
Scenario assumptions (Florida; US-FL)
We’ll assume the following facts for the example:
- Filing date / calculation date: 2026-01-15
- Parent A income (monthly gross): $6,500
- Parent B income (monthly gross): $3,900
- Shared parenting time: 30% / 70% (Parent A / Parent B)
- Children: 2
- Childcare expenses (monthly): $400
- Health insurance (monthly): $150
- Alimony type in the modeling: “Include alimony” (DocketMath selection)
- Custody modifier in the model: apply shared time adjustment
- Any additional support adjustments: $0 (for simplicity in the example)
Note: Florida support law can be nuanced, and courts may consider factors not captured in a single tool run. Use this as a numerical illustration, not a determination of what a court would order.
Statute-related context used in this example
This example also demonstrates how DocketMath can incorporate “general rules” that are not claim-specific. For the general/default time period referenced here, the dataset indicates:
- General SOL period: 4 years
- General statute: Florida Statute § 775.15(2)(d)
The brief also notes:
- No claim-type-specific sub-rule was found.
That means we apply the general/default period above, rather than a specialized limit for a particular claim type.
We’ll use this “general/default period” context in the sensitivity check, because timing assumptions can affect whether a request is modeled as timely.
Example run
Now let’s run the example through DocketMath using the calculator /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.
Inputs entered into DocketMath (example)
- Parent A monthly gross: $6,500
- Parent B monthly gross: $3,900
- Parenting time: 30% / 70%
- Number of children: 2
- Childcare: $400 / month
- Health insurance: $150 / month
- Include alimony: Yes
- Additional adjustments: $0
- Jurisdiction: **Florida (US-FL)
What the run produces (illustrative output structure)
A typical DocketMath output (as a modeling tool) is organized into components. In this example, you’d expect results along these lines:
| Output component | Modeled result |
|---|---|
| Estimated child support (monthly) | $X |
| Estimated alimony (monthly) | $Y |
| Total estimated support (monthly) | $X + $Y |
| Notes/assumptions | Parenting-time adjustment applied; childcare + health costs included as entered |
Because the calculator’s exact numeric formula depends on the tool’s internal logic and any jurisdiction-aware toggles, the key takeaway is the workflow: you provide Florida-specific inputs (income, parenting time, children, and relevant costs), and DocketMath computes modeled obligations for that scenario.
How the Florida context shows up
Two Florida-specific modeling aspects are relevant in this worked example:
Support inputs and cost categories
You’re including monthly childcare and health insurance in the modeling inputs. Those inputs affect the modeled support total because they’re part of the cost bundle.General timing context using Florida Statute § 775.15(2)(d)
The dataset indicates a 4-year general SOL period under Florida Statute § 775.15(2)(d). Importantly, the brief states we did not find a claim-type-specific sub-rule—so we apply the general/default period.
Sensitivity check
Small changes in income, parenting time, or timing assumptions can materially change the modeled support totals. Here are three targeted sensitivity checks you can run in DocketMath—each designed to show what moves the number.
Warning: Sensitivity checks can reveal how sensitive a model is when inputs are estimates. Real-world filings may include additional information (e.g., overtime history, imputed income, or verified expenses) that changes outcomes.
1) Parenting time: shift 10% toward Parent A
Change: Parenting time from 30% / 70% to 40% / 60% (Parent A increases time).
- Everything else unchanged.
- Run again.
Expected directional effect:
Parent A’s share of custodial time increases, which typically changes the modeled child support allocation between households (the direction for each parent can depend on the tool’s structure). Alimony modeling may also shift due to changes in relative economic circumstances that the tool accounts for.
Checklist:
2) Income: increase Parent B by $500/month
Change: Parent B monthly gross from $3,900 → $4,400.
Expected directional effect:
Modeled child support often decreases when the non-primary parent’s (or lower-time parent’s) income increases, because the relative ability-to-pay gap can narrow. Alimony modeling may also shift for the same reason.
Checklist:
3) Timing assumption: test whether a modeled event is within a 4-year general period
This is where Florida Statute § 775.15(2)(d) and the 4-year general SOL matter in the modeling context.
General/default period applied:
- 4 years, based on the general statute reference provided in the dataset
- No claim-type-specific sub-rule was found, so we do not apply a specialized limitation period.
Example timing test:
- Suppose the modeled “trigger” date is 2022-11-01
- Filing/calc date used earlier: 2026-01-15
Compute elapsed time:
- From 2022-11-01 to 2026-01-15 is about 2 years and ~75 days, which is within 4 years.
What to do in DocketMath:
How to interpret the result:
- If elapsed time is ≤ 4 years, timing is modeled as within the general/default period.
- If elapsed time is > 4 years, timing is modeled as outside the general/default window.
Pitfall: If your facts involve a claim with its own specialized limitation period, applying a general/default period can be misleading. In this walkthrough, we explicitly apply the general/default period because no claim-type-specific sub-rule was found in the provided ruleset.
