Spreadsheet checks before running Alimony Child Support in New York
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 and/or child support calculation in New York with DocketMath’s alimony-child-support tool, use this spreadsheet checker to catch common “garbage-in” problems—especially those that break results after you export values, copy formulas, or adjust payor/payee columns.
This checker focuses on three practical categories of spreadsheet issues:
Jurisdiction mismatches in a multi-tab workbook
- Example: you copied an input tab from another state, but the “NY” worksheet still points to the wrong cell range.
- What to check in your spreadsheet:
- Make sure the workbook is explicitly labeled with jurisdiction code
US-NY. - Ensure every calculation tab references the same New York jurisdiction inputs (not an older copy that still contains different assumptions).
Time-window errors caused by incorrect date arithmetic
- Alimony/child support worksheets often include start date, modification date, retroactive period, arrears period, or document entry date.
- Run the checker to verify:
- Date ordering: no “end date” earlier than “start date” for any retroactive/arrears window.
- Consistent date formats (for example,
YYYY-MM-DD). - No mixed formats: Excel sometimes stores typed dates as “text,” which makes formulas behave unexpectedly.
Arrears/collection logic conflicts—especially when your time window exceeds New York’s general limitations benchmark
- DocketMath can only compute with what you provide in your inputs; it can’t automatically infer every legal nuance from your spreadsheet.
- If your spreadsheet uses a retroactive or arrears horizon, the checker helps ensure your workflow is aligned with a general/default limitations period of 5 years.
- Jurisdiction data you provided states that the general/default period is 5 years, referencing N.Y. Crim. Proc. Law § 30.10(2)(c):
Important note (based on your jurisdiction data): No claim-type-specific sub-rule was found. That means this checker treats 5 years as the general/default period, not as a claim-type-specific deadline. If your workflow depends on a specialized limitations rule, confirm that separately before relying on any retroactive-range inputs.
A practical checklist (quick pass)
When to run it
Run the spreadsheet checker at three decision points so you catch issues early—before calculation outputs cascade into the tool results.
Before you enter values into DocketMath
- This prevents the fastest failures.
- Common issues caught here: wrong date format, off-by-one month windows, and mislinked cells.
After you revise dates or retroactive/arrears periods
- If you update any of these, rerun the checker:
- agreement/filing date changes
- modification effective date changes
- start/end of arrears window changes
- Spreadsheets can “look right” while formulas still reference an older range—so this step matters even if totals seem unchanged.
Right before you finalize an output for review or sharing
- Treat this as a “preflight” step.
- Goal: confirm the exported inputs still match what the output claims to calculate.
Date-window sanity rules to enforce
Limitations-period alignment (general/default benchmark)
If your spreadsheet includes a retroactive or arrears time horizon, the checker should flag when the window exceeds your general/default 5-year benchmark.
- General/default: 5 years
- Basis (jurisdiction data you supplied): **N.Y. Crim. Proc. Law § 30.10(2)(c)
Warning (workflow-focused, not legal advice): A limitations period is not the same thing as “how long you can calculate arrears” in every context. Your spreadsheet may be doing arithmetic over a longer window, but this checker surfaces whether your window is exceeding a general benchmark so you don’t accidentally present results as time-permitted when you haven’t validated the rule that applies to your situation.
Try the checker
Use DocketMath to run your alimony-child-support workflow, but do it after a spreadsheet preflight.
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Capture the source for each input so another team member can verify the same result quickly.
Step-by-step: spreadsheet checks → tool inputs
Open your spreadsheet and complete the quick pass:
- confirm jurisdiction label US-NY
- validate date ordering and formats
- confirm your “months” fields match the date window
Compare your date window to your single general/default benchmark:
- If you’re using the 5-year general/default period, ensure your retroactive/arrears window doesn’t silently exceed it.
Export or enter the cleaned values into the tool.
- Remember: any output is only as reliable as the inputs you validated.
DocketMath tool call-to-action
Use the calculator here:
- /tools/alimony-child-support
Input → output behavior map (what changes when you fix inputs)
| Spreadsheet fix | What it changes in results | How to spot it fast |
|---|---|---|
| Correct date formats | Retroactive months / duration computations | Output amount changes after a “duration” field recalculates |
| Fix start/end order | Window length (could drop to 0 or expand) | Negative/blank duration turns into a positive number |
| Enforce one jurisdiction tab | Logic/toggles tied to jurisdiction inputs | Output stops “jumping” between versions |
| Recompute months from dates consistently | Amount updates by month-based factors | Differences align closely to month-count changes |
Pitfall: If your spreadsheet mixes “months” and “days” conversions, fixing date formats can shift your computed duration by ~1–2 months. That small change can materially affect totals, even if everything else is correct.
