Spreadsheet checks before running Alimony Child Support in Alaska

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Running an alimony/child support scenario through a spreadsheet is a common first step—but in Alaska, a few spreadsheet “gotchas” can silently change the meaning of your math. DocketMath’s alimony-child-support checker for US-AK helps you catch those issues before you rely on outputs or share them with anyone else.

Because you’re in Alaska, the checker is anchored to the general statute of limitations (SOL) framework, using:

Important scope note (clear default rule): No claim-type-specific sub-rule was found for this checker checklist. So the checker treats the 2-year window as the general/default period under § 12.10.010(b)(2). That means the tool flags issues that fall outside the general SOL assumption—it is not a substitute for legal analysis of whether a different, claim-specific SOL rule might apply.

Typical issues it catches in a spreadsheet workflow

When the checker runs, it focuses on internal consistency—especially around dates, units, and time windows that determine how much of your timeline the worksheet effectively includes.

Common spreadsheet issues:

  • Date fields that don’t line up

    • Example: using a “filing date” in one column and an “event date” in another, or mixing “obligation start” with “payment received” dates without a consistent definition.
    • Outcome: totals can look plausible, but SOL timing assumptions may not match your timeline intent.
  • Back-dated amounts included without timing clarity

    • Example: including support starting 30 months earlier while the spreadsheet is effectively built around a 2-year general SOL assumption.
    • Outcome: the checker can warn that the included period may exceed the general 2-year SOL window used for the check.
  • Mixing monthly vs. annual inputs

    • Example: entering one figure as “$18,000/year” while another part of the spreadsheet treats it as “$18,000/month.”
    • Outcome: the checker flags unit inconsistency because it can cause arrears-style totals to be overstated or understated.
  • Rounding and partial-month handling

    • Example: treating a partial month as a full month (or vice versa) in different rows.
    • Outcome: worksheet totals may diverge by meaningful amounts; the checker encourages you to standardize partial-month rules.
  • **Sign conventions (directionality)

    • Example: entering payments as negative amounts in one tab but positive amounts in another, or switching between “obligation vs. credit” conventions.
    • Outcome: netting can flip; the checker can flag inconsistent directionality across your sheet.

Note: SOL timing in this checker is based on the general/default 2-year period in Alaska Statutes § 12.10.010(b)(2). The tool checks your spreadsheet’s date logic against that assumption; it’s not a substitute for legal analysis of claim-specific timing rules.

When to run it

Run the checker before you finalize any numbers you plan to use in a narrative, a negotiation email, or a document package. If your sheet is going to be reused or compared, catching timeline and unit issues early saves time later.

In practice, there are two “best moments”:

  1. Immediately after you enter inputs

    • Populate dates (start date, event date, and payment months), income figures, and payment schedules first.
    • Then run the checker so it can validate timing and unit consistency while the sheet is still easy to edit.
  2. After you adjust one variable

    • Any change that touches a date range or monthly/annual conversion can shift SOL-related flags and totals.
    • Examples:
      • Switching from “monthly” to “biweekly” entries
      • Adding or removing months of claimed obligations
      • Changing the assumed start date of support

Quick pre-run checklist

Before running (or re-running) the checker, verify:

If you follow this workflow, the checker acts as a guardrail—not a late-stage surprise.

Try the checker

You can try this workflow directly at: /tools/alimony-child-support (DocketMath).

Here’s a practical way to structure your spreadsheet so the checker has clean inputs.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Suggested input pattern (spreadsheet-friendly)

  • Timeline column

    • One column for each month (or payment period)
    • One shared “date logic” row that explains what each date represents (e.g., “obligation month,” “payment month,” “trigger date”)
  • Amount column

    • Use a single unit: monthly dollars everywhere
    • If you have annual income, convert it once at the top of the sheet, then reference the monthly result
  • Arrears / net calculation column

    • Keep sign conventions consistent (for example: positive = obligation, negative = credits/payments)

What output behavior to expect (US-AK + general 2-year SOL)

When the checker runs under US-AK using Alaska’s general 2-year SOL assumption (AS § 12.10.010(b)(2)), pay attention to warnings tied to:

  • Included months vs. the timing anchor

    • If the included months begin more than about 2 years before the relevant timing anchor you’re implicitly using, expect a SOL timing warning.
    • Why it matters: the general/default 2-year window may not align with the period your sheet is effectively measuring.
  • Monthly vs. annual mismatch

    • If any row mixes units, expect a unit consistency warning.
    • Why it matters: the totals can drift significantly due to a conversion error.
  • Inconsistent date definitions between columns/tabs

    • If “start date,” “event date,” and “payment month” are defined differently across the sheet, expect date logic warnings.
    • Why it matters: the checker can’t reliably interpret your timeline intent when definitions conflict.
  • Partial-month handling inconsistency

    • If partial months are computed differently across rows, expect rounding/period warnings.
    • Why it matters: small differences can compound into larger total discrepancies.

Warning: If you see a SOL-related warning, don’t ignore it just because the spreadsheet totals look “reasonable.” Timing mismatches are a common source of confusion when people later compare worksheets or summarize results.

Quick “sanity test” before re-running

After you fix an issue, do one controlled change:

  1. Change only one thing (e.g., convert annual to monthly, or remove a single month outside the 2-year window).
  2. Re-run the checker.
  3. Confirm the checker’s flags change in the way you expected.

This isolates whether the problem is about math, dates, or unit assumptions.

Related reading