Spreadsheet checks before running Alimony Child Support in Connecticut

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.

Before you run an alimony or child support calculation in Connecticut with DocketMath, your spreadsheet should sanity-check dates that can quietly determine whether a claim is time-barred. DocketMath includes a jurisdiction-aware “spreadsheet checker” workflow for US-CT that focuses on one key risk area: Connecticut’s general statute of limitations.

The key limitation to model (Connecticut default)

Connecticut’s general civil statute of limitations is 3 years under Conn. Gen. Stat. § 52-577a. The checker treats this as the default/general period for spreadsheet checks—no claim-type-specific sub-rule was found in the provided jurisdiction data, so you should rely on this general 3-year rule for the checker.

  • Statute: Conn. Gen. Stat. § 52-577a
  • General SOL period: 3 years
  • How it shows up in your spreadsheet: the checker compares when the obligation-related events occurred to the date you’re effectively asserting or filing the matter (based on the date you input into DocketMath).

Spreadsheet errors the checker is designed to flag

Use this as your pre-flight checklist. The checker typically catches patterns like:

  • Date order problems
    • Example: the “claim asserted” (or assertion reference) date is earlier than the event date(s).
  • Off-by-one year mistakes
    • Example: entering “2021” when the underlying event was “2020,” which can push the timeline across the 3-year boundary.
  • Mixed-up date meanings
    • Example: entering a payment date where the worksheet expects an event/assertion reference date for the timing comparison.
  • Missing reference date
    • Example: leaving the spreadsheet without the date needed to compare against the 3-year general SOL.
  • Unintended blank rows
    • Example: a row that looks blank being interpreted as a zero or a null date, shifting how the worksheet evaluates the timeline.

Warning: Even if your payment math model is correct, the spreadsheet can still produce a misleading “best-case” outcome if the underlying dates trigger Connecticut’s 3-year general limitations period under Conn. Gen. Stat. § 52-577a.

Why this matters for your spreadsheet output

DocketMath’s alimony-child-support calculator depends on your inputs. If the checker identifies an inconsistency (or a missing key date), your output can become unreliable—not because the formulas are necessarily wrong, but because the worksheet may be answering the question using the wrong timing assumptions.

A practical way to think about it:

Spreadsheet date inputCommon errorChecker effect
Event date (or obligation trigger date)Entering the payment dateTimeline comparison becomes inaccurate
Filing/assertion reference dateEntering “today” instead of the relevant reference dateMay incorrectly extend or shorten the 3-year window
Several event rowsOne row typed with an incorrect yearA single error can flip whether a 3-year boundary is crossed

When to run it

Run the checker before you calculate—ideally as the first step in your workflow—so you don’t invest time in numbers built on inconsistent timing inputs.

Here’s a practical sequence:

  1. Collect core dates
    • Event/trigger dates relevant to the support/alimony period you’re modeling
    • The date you plan to use as your assertion reference in DocketMath
  2. Fill the spreadsheet rows
    • Ensure every event row has a valid date (avoid blanks and avoid date text that can be misread, like “March 5” without a year)
  3. Run DocketMath’s spreadsheet checker
    • Confirm it passes the US-CT timing checks based on the 3-year general SOL under Conn. Gen. Stat. § 52-577a
  4. Only then run the alimony-child-support calculator
    • Use results to stress-test scenarios by adjusting dates and amounts, not just amounts

Best time to re-run

Re-run the checker anytime you change any of the following:

  • The assertion reference date you used (even if you only move it by a few days)
  • The event/trigger date range
  • Any row that marks the start of a modeled support period
  • The jurisdiction setting (keep it consistent with US-CT)

Pitfall: If you update monthly amounts but forget to re-check the dates after revising the timeline, you can end up with one spreadsheet containing correct amounts and a second containing correct dates. The checker helps you keep date logic aligned before relying on calculator outputs.

Try the checker

To use DocketMath, start at the calculator entry point:

  • /tools/alimony-child-support

If you’re building a workflow, open /tools/alimony-child-support and follow the checklist prompts as you enter your dates.

To make the next run smooth, prepare your spreadsheet like this:

  • Use a dedicated column for Event/trigger date
  • Use a single dedicated cell for Assertion reference date (the comparison point your worksheet uses)
  • Keep date formatting consistent
    • If your spreadsheet allows it, prefer YYYY-MM-DD formatting

As you run the checker, watch for:

  • Date order issues (event date after reference date)
  • Missing date issues (blank or invalid date)
  • Boundary-crossing warnings or implied flags based on the 3-year general rule under Conn. Gen. Stat. § 52-577a

Finally, keep the limitation framing clear:

  • This timing check uses the general 3-year SOL provided for Conn. Gen. Stat. § 52-577a.
  • Because the jurisdiction data did not include a claim-type-specific sub-rule, treat this as the default/general period for spreadsheet checking.

Gentle reminder: This tool supports date sanity-checking and workflow organization, but it’s not legal advice. If deadlines or claim details are complex, consider consulting a qualified attorney in Connecticut.

Related reading