Spreadsheet checks before running Alimony Child Support in Arizona

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

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

DocketMath’s Alimony Child Support calculator for Arizona (US-AZ) is only as reliable as the numbers you feed it. Before you run calculations, a spreadsheet checker helps you catch data issues that commonly distort results—especially when you’re modeling spousal maintenance (alimony) and child support together.

This page is about spreadsheet quality checks, not legal advice. Think of these checkpoints as data integrity steps you can do before using DocketMath.

Here are the most common problems the checker targets:

  • Missing dates

    • Empty “start date” / “effective date” fields can cause the calculator to apply the wrong time window.
    • If you don’t know the effective date, the checker can flag that your timeline is incomplete—an issue that can affect any retroactive or lookback modeling you’re trying to represent.
  • Inconsistent time periods

    • Mixing monthly and weekly amounts in the same column can inflate or deflate totals.
    • Typical examples the checker looks for:
      • Child-related amounts entered as weekly while other fields are monthly
      • Payment schedules that don’t align with the month-by-month projection the model is using
  • Conflicting income inputs

    • For maintenance/support calculations, income fields often drive the output—so small input problems can create big output changes.
    • Checks may include:
      • Negative income entries (often a data entry error)
      • Unusually large spikes that look like typos (for example, 6,000 entered instead of 600)
      • Employer/returning-income mismatches across rows (for example, dates showing one job but amounts belonging to another)
  • Boolean logic errors

    • Checkbox-style fields (“Yes/No” assumptions like health insurance responsibility) can sometimes be inverted or misinterpreted.
    • A frequent spreadsheet bug is using values like "Yes"/"No" as text that don’t map to what the checker expects. The checker flags unrecognized values so you can fix them before running the calculator.
  • Rounding and formatting glitches

    • Cells formatted as currency but stored as text may not compute correctly.
    • Common issues the checker can identify:
      • Numbers stored like "1,200.00" (text) instead of 1200.00 (numeric)
      • Percent fields entered as 25 instead of 0.25 (or the reverse), depending on how the tool expects the value
  • **Statute-of-limitations awareness (for collection-oriented timelines)

    • If your spreadsheet includes “lookback” or retroactive modeling, the checker can help you validate your assumptions against Arizona’s general baseline.
    • In Arizona, the general statute period referenced here is two years under A.R.S. § 13-107(A) (see the source link below).
    • Important clarity: the two-year period above is the general/default period, and no claim-type-specific sub-rule was found for this checker context. That means the checker can validate only against the general baseline, not a specialized carve-out.

Pitfall to avoid: If you enter a longer lookback period than your dataset supports, your projection may reflect a timeline that isn’t consistent with the general baseline from A.R.S. § 13-107(A). Even when spreadsheets are “what-if” models, timeline mismatch is a major driver of confusion.

When to run it

Run the spreadsheet checker right before you launch the DocketMath alimony-child-support calculator. Also run it any time you change inputs that affect amounts or timing.

A practical trigger list:

  • Before the first run

    • Use it immediately after you paste or import data into your spreadsheet.
    • This catches formatting errors that might otherwise fail silently.
  • After any timeline change

    • Updating:
      • effective dates
      • start/end dates
      • payment frequency
    • …should always be followed by a checker pass, because timeline mismatches can compound across months.
  • After any income update

    • If you revise wages, bonuses, overtime, or other income lines, rerun the check.
    • Income values are a common root cause for large output swings.
  • After changing any “toggle” assumptions

    • Example toggles:
      • health insurance responsibility
      • childcare expense assumptions
      • other yes/no inputs
    • Any change can flip downstream logic.
  • Before copying results into a narrative summary

    • If you plan to paste outputs into a motion draft, declaration, or case notes, run the checker once more to confirm the spreadsheet still matches the latest numbers.

Quick checklist you can complete in 5–10 minutes:

Try the checker

Use DocketMath to streamline the workflow:

  1. Open the tool: /tools/alimony-child-support
  2. Paste or enter your spreadsheet inputs.
  3. Run the spreadsheet checker step before generating results.
  4. Review the flags, correct inputs, and re-run until you get a clean check.

When you test scenarios, vary one input at a time so you can see how output changes. A simple Arizona-focused test plan:

  • Scenario A: Baseline
    • Run with your current best estimates.
  • Scenario B: Income correction
    • Change one income field (for example, monthly gross wages from 6,000 to 6,200) and rerun.
  • Scenario C: Timeline correction
    • Adjust the effective date by 1 month and rerun.
  • Scenario D: Formatting correction
    • Fix one currency/text conversion issue and rerun.

If the checker is working properly, you’ll observe:

  • Output changes when you intentionally change a key input
  • Output doesn’t change drastically when you only fix formatting that previously prevented correct computation

Warning: Even if the calculator returns a number, treat it as a model output until your spreadsheet passes the checker. One misformatted cell can change totals without producing an obvious error.

For statute-related timeline assumptions used in your sheet:

  • Arizona’s general baseline referenced here is two years under A.R.S. § 13-107(A) (link below).
  • Again, this is the general/default period, and no claim-type-specific sub-rule was identified for this worksheet-checking workflow.

Related reading