Common Alimony Child Support mistakes in Arizona
5 min read
Published April 15, 2026 • By DocketMath Team
The top mistakes
Run this scenario in DocketMath using the Alimony Child Support calculator.
If you’re using DocketMath (alimony-child-support) in Arizona (US-AZ), the biggest problems usually aren’t math errors—they’re input and timing mistakes that cause an outcome to look “wrong” or to miss a deadline. Below are common issues people run into when calculating or comparing alimony (spousal maintenance) and child support expectations in Arizona.
Pitfall: Arizona’s timelines and enforcement rules have real consequences. This post focuses on common calculation and process mistakes—not legal advice.
1) Using the wrong “start date” for support calculations
Support calculations depend heavily on which date you treat as the beginning of the obligation (for example, the filing date, service-related timing, or the date an order was entered). If the start date is off by even a month, totals can swing due to how payments are prorated.
What goes wrong
- You enter a start date that doesn’t match the operative order or agreement.
- You assume “filing date = obligation date” without checking the document controlling payment.
2) Confusing spousal maintenance with child support
In Arizona, spousal maintenance and child support are different obligations with different purposes and mechanics. Even if DocketMath helps you model both, mixing up categories (for example, treating spousal maintenance inputs as if they were child support, or vice versa) can distort your monthly picture.
What goes wrong
- You apply child-support-style thinking to maintenance totals (or the reverse).
- You use one obligation’s assumptions to calibrate the other.
3) Overstating income by double-counting deductions or income sources
DocketMath-style calculators are only as accurate as the income inputs. Common mistakes include:
- Counting the same income stream twice (for example, entering base salary and then separately entering a bonus/variable income that is already included in the salary figure you used).
- Treating deductions inconsistently—e.g., assuming they reduce income in the same way across inputs when the tool’s modeling approach is different.
Quick check
- Do your inputs match how you document income (pay stubs, tax returns, schedules)?
- Are any items represented in more than one place in the same scenario?
4) Leaving child-related numbers blank or using rounded estimates
Child-related variables often matter:
- Number of children you’re modeling
- Any adjustments tied to custody/time-sharing assumptions (when applicable in your situation)
When you round income and also leave child variables at defaults, the compounded effect can be large.
What goes wrong
- Using “about $X” for multiple inputs at the same time.
- Relying on defaults even though your facts differ (for example, different child count).
5) Ignoring enforcement-related risk tied to deadlines (SOL)
Some people focus only on the calculation and forget that claims must be brought within limitation periods. Arizona has a general statute of limitations of 2 years under A.R.S. § 13-107(A).
Clear baseline
- The 2-year period described in A.R.S. § 13-107(A) is the general/default rule.
- No claim-type-specific sub-rule was identified here, so don’t assume every scenario automatically fits neatly into that same bucket without reviewing the controlling legal theory for your situation.
Note: This SOL citation is included because deadlines frequently affect what can be pursued later—even if your monthly computation is otherwise reasonable. This is not guidance that any specific support dispute is governed by that exact rule.
How to avoid them
You can reduce mistakes quickly by treating DocketMath as a structured data workflow, not a one-shot answer. The goal is to make inputs auditable and to understand how output changes. Start with the tool here: /tools/alimony-child-support.
Step 1: Align your timeline before you touch any numbers
Before entering income or expenses, confirm which date range your scenario is intended to represent.
Use this checklist:
Why it matters in DocketMath outputs
- If the calculator prorates by months, an off-by-one month error can change totals even when the monthly figure is correct.
Step 2: Separate spousal maintenance inputs from child support inputs
In practice, treat them as two scenarios:
- Scenario A: “maintenance”
- Scenario B: “child support”
Then compare totals side-by-side rather than rolling them into a single bucket.
DocketMath workflow tip
- Run two passes (one for each obligation) and label the outputs.
- Don’t reuse the same income assumptions without checking whether they apply to both.
Step 3: Use “one income source, one input,” then reconcile
Take the time to prevent duplication:
- historical average,
- last-year total spread across months, or
- a documented recurring amount.
Output sensitivity
- Income errors typically have the largest effect on outputs.
- If you’re uncertain, test a small range (for example, ±5% on income) and observe whether the result changes drastically.
Step 4: Don’t leave child parameters at defaults when facts differ
Child-related modeling is sensitive to the inputs that drive the obligation.
Step 5: Use the SOL deadline as a “risk check,” not an afterthought
Even if you’re primarily trying to forecast monthly numbers, remember deadlines can affect what becomes actionable later.
- Arizona’s general/default 2-year statute of limitations is cited at A.R.S. § 13-107(A).
- This is a baseline rule referenced as the general SOL period—not a promise that every support claim maps to it.
Practical risk check