Common Alimony Child Support mistakes in Virginia

The top mistakes

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

These are common alimony and child support mistakes we see in Virginia—especially when people use a calculator, draft forms, or rely on a draft order built from incomplete facts. DocketMath can help you model outcomes, but the math only matches your situation if your inputs are accurate.

1) Using the wrong income figures (or missing required income)

Virginia support calculations usually depend on effective income, not just what appears on one paycheck. Typical input errors include:

• Using gross pay when the method you’re modeling assumes a consistent income base
• Forgetting recurring amounts such as bonuses, overtime, commissions, or regular benefits
• Missing a second job or using an average that doesn’t reflect how income actually changed
• Not updating figures after a job change, layoff, or reduced earning capacity

Why it matters in DocketMath: Your income inputs drive the support numbers. Overstated or understated income can shift the output substantially.

2) Incorrect health insurance / medical coverage assumptions

A frequent issue is how medical costs are treated in the support math. People often:

• Enter a monthly premium that doesn’t match the figure used in the worksheet/model structure they’re trying to mirror
• Use coverage cost for only one child when coverage applies to multiple children
• Omit regular, child-attributable medical expenses when their model includes them

Output impact: If coverage costs are included (and categorized correctly), DocketMath results can change due to how medical costs are allocated.

3) Miscounting parenting time and choosing the wrong schedule category

Parenting-time inputs can determine which worksheet scenario applies. Common problems include:

• Entering the number of overnights incorrectly
• Confusing weekends/holidays with regular overnights
• Using a schedule that changed (including seasonal changes) but entering the old pattern

DocketMath angle: If parenting-time variables are part of the model, even small counting errors can move the recommendation.

4) Skipping the correct child count (or missing eligibility changes)

Two related errors happen often:

• Using the wrong number of eligible children for the period being modeled
• Failing to update when eligibility changes, such as when a child turns 18 or when a child’s status changes in a way that affects eligibility

Impact: The child-support portion can change materially when eligibility changes by child over time.

5) Treating “alimony” and “child support” as if one payment covers both

In Virginia, alimony and child support are separate obligations. Mistakes include:

• Assuming one replaces the other (e.g., “If I pay support, I don’t also owe alimony”)
• Comparing only a combined monthly number without separating categories
• Modeling an informal agreement as if it were a formal order structure

How DocketMath helps: Using a calculator that separates categories can make it easier to see how changes to income, parenting time, and insurance affect each obligation.

6) Modeling arrears or temporary orders using final-order assumptions

Another common problem is timeline mismatch. For example, people may:

• Use a permanent order model while the case history is actually temporary
• Apply a final-order assumption to a period involving partial payments or retroactive amounts

Outcome impact: Even when DocketMath produces a correct “monthly” estimate, totals can be wrong if you assume it applies to the entire timeline.

7) Ignoring how tax/benefits assumptions affect scenario comparisons

You don’t need tax advice to avoid a modeling mismatch. But it helps to recognize that comparisons can go sideways when you assume the wrong budget effect. Common examples:

• Treating alimony/support effects as the same as wage replacement without checking alignment with the model you’re using
• Using income figures that don’t reflect stability (which can change how scenarios should be compared)
• Overlooking that the real-world impact can differ when benefits eligibility changes as income/support changes

Practical takeaway: Use DocketMath outputs as model numbers tied to your inputs—then sanity-check them against your actual payment history and budget.

How to avoid them

Use a process that improves input quality before relying on outputs. This checklist is designed for using DocketMath to model Virginia alimony and child support (and to catch input issues early).

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step-by-step input quality checklist (before you hit calculate)

Validate outputs with “change tests”

After you run a baseline, do quick sensitivity checks. If the result doesn’t move the way the model suggests, revisit inputs.

Use DocketMath as a modeling tool—not a substitute for your order’s structure

A common failure mode is treating a calculator output as the final court number. Instead:

• Compare DocketMath’s result to the structure of your existing worksheet/order language (categories, inputs, and definitions)
• Ensure your calculator inputs match the order’s definitions for parenting time and coverage

Keep documentation tight to prevent “input drift”

When anything changes, you’ll rerun the calculator—so keep a simple input log:

• Income documents (pay stubs, bonus statements, benefits summaries)
• Insurance premium invoices or portal screenshots
• Parenting-time calendar screenshot or written schedule
• Child information affecting eligibility during the modeled period

This reduces repeated errors where you unknowingly carry forward outdated numbers.

If you want to model scenarios, start here: /tools/alimony-child-support.

Related reading

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