Spreadsheet checks before running Alimony Child Support in Missouri

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

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

Before you run an alimony and child support calculator in Missouri with DocketMath (the alimony-child-support calculator), a quick “spreadsheet checks” step can prevent the most common input mistakes that skew results—sometimes dramatically.

DocketMath helps you model support obligations, but your spreadsheet still has to feed the tool clean, jurisdiction-consistent inputs. In this Missouri workflow, the most time-sensitive issue to check is whether your statute of limitations (SOL) logic matches Missouri’s default rule.

Missouri SOL default period (the big one)

Missouri’s general SOL period is 5 years. The relevant general statute is:

Important clarity about claim types: the jurisdiction data provided here identified no claim-type-specific sub-rule, so this content uses the general/default period. That means your spreadsheet logic should treat 5 years as the baseline unless you later confirm that a different, claim-specific SOL applies.

Note: This checker assumes the default 5-year SOL under Mo. Rev. Stat. § 556.037. It does not attempt to swap in a different period for a specific claim type.

Spreadsheet-level errors the checker flags

A strong spreadsheet-checking pass should catch issues like these:

  • Date format inconsistencies

    • Example: 1/5/24 vs 01-05-2024 vs 2024.01.05
    • Output impact: miscomputed lookback windows and wrong SOL-related dates.
  • Wrong “start date” meaning

    • Some sheets treat a “start date” as the filing date; others treat it as the start of the obligation.
    • Output impact: the SOL window can shift by months, which can change whether amounts are included or time-limited.
  • Blank or mis-typed income fields

    • Example: annual income entered where DocketMath (or your spreadsheet) expects monthly (or vice versa).
    • Output impact: inflated or deflated support estimates downstream.
  • Rounding and unit drift

    • Example: entering “$3,500” as “3.5,” or mixing gross vs net when your sheet tracks the other.
    • Output impact: small input errors can compound across multiple line items.
  • Number fields stored as text

    • Example: "2500" with quotes, or commas in values like "2,500.00".
    • Output impact: calculations may silently fail or treat values as zero.

Quick validation table (what to confirm)

Use this checklist before you run the model:

Input fieldWhat to verifyCommon failureQuick fix
Obligation start dateSame definition across all tabsStart date treated as filing date in one placePick one definition and label it clearly
Lookback / SOL windowDefault to 5 yearsUsing 3 years or “unknown”Hardcode 5 years tied to § 556.037 logic
Income amountsCorrect units (monthly vs annual)Annual entered as monthlyConvert upfront, then lock units in your sheet
Child-related inputsConsistent ages / number of childrenOff-by-one child countCross-check row totals
Output displayNo hidden roundingRounding early in the pipelineRound only at the end

When to run it

Run the spreadsheet checks at three practical points—each one prevents a different category of mistakes.

Run the checker before importing a spreadsheet into the Alimony Child Support workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) Before your first model run

If you’re building the spreadsheet from scratch, run the checks first. This prevents “garbage-in/garbage-out” from contaminating every later scenario.

Minimum date sanity tests:

  • Ensure your spreadsheet computes a lookback window anchored to a clearly selected reference date (commonly the date you’re evaluating or modeling from—your sheet should label it).
  • Apply 5 years as the default SOL window consistent with Mo. Rev. Stat. § 556.037 (general/default).

2) Every time you update inputs

Re-run checks immediately when you change inputs, especially:

  • income changes
  • number of children
  • dates (obligation start date, reference date, and any event dates)
  • switching between monthly and annual representations

3) Before you compare scenarios

Scenario comparisons are where subtle data issues become obvious—but only after you’ve done work. Catch them first so Scenario A isn’t actually based on a date-format or unit mismatch.

Warning: Comparing scenarios without rerunning spreadsheet checks can produce differences that look like substantive results but are actually spreadsheet formatting issues.

Try the checker

You can apply these checks as a repeatable pre-flight step before you use the calculator.

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

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

Step-by-step: spreadsheet checks before running DocketMath

  1. Confirm Missouri SOL baseline in your sheet

    • Set your SOL default period to 5 years under Mo. Rev. Stat. § 556.037 (general/default).
    • Avoid claim-type-specific adjustments unless you later verify a different rule applies.
  2. Standardize date fields

    • Convert all dates to one format (for example, ISO YYYY-MM-DD).
    • Ensure any computed date uses the same underlying reference date.
  3. Lock units for income

    • Decide whether your sheet stores monthly or annual income.
    • Convert everything to match what your DocketMath inputs expect.
    • Then keep units consistent across all scenarios.
  4. Recalculate and verify totals

    • Confirm each line item is numeric.
    • Check totals render correctly (not blank, not “0” from failed parsing).
  5. Run the DocketMath model only after checks pass

    • Start with one “baseline” scenario.
    • Then adjust one input at a time to understand how outputs change.

Primary CTA

Use the DocketMath calculator here: /tools/alimony-child-support

What output changes when inputs are corrected

A spreadsheet-checker workflow changes outputs in predictable ways:

  • Fixing date parsing can shift whether amounts fall inside or outside a 5-year default window tied to § 556.037 logic.
  • Fixing income units often causes the largest swings—especially when annual values are accidentally treated as monthly.
  • Fixing child count can change multiple downstream computations at once, so it’s worth verifying before you interpret results.

Disclaimer: This content is for workflow clarity and planning. It isn’t legal advice, and it doesn’t guarantee how your specific facts would be evaluated by a court.

Related reading