Spreadsheet checks before running Alimony Child Support in Nevada
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Before you calculate alimony or child support amounts in Nevada with DocketMath, add a “pre-flight” spreadsheet layer that prevents avoidable mistakes. DocketMath can run the alimony-child-support calculator, but your spreadsheet decides whether the dates and assumptions you feed it are valid, time-consistent, and aligned with Nevada’s general timelines.
This checker focuses on one jurisdiction-aware risk: late filing / stale claims issues tied to Nevada’s general statute of limitations for certain actions.
Nevada limitations rule used (general/default)
Using the Nevada general limitations rule you provided, the default period is:
- 2 years (general rule)
- NRS § 11.190(3)(d)
Important clarity: the jurisdiction data you provided notes that no claim-type-specific sub-rule was found. That means this spreadsheet check uses the general/default 2-year period only—it does not try to split the limitations analysis by specific claim categories.
Common spreadsheet problems it catches
Use your spreadsheet checker to validate (at minimum) these items:
Date integrity
- Receipt date vs. filing date vs. “calculation start” date
- Missing or swapped month/day/year values
- Dates stored as text (which can break day counts and comparisons)
**Solvable timing (limitations-window flag)
- Whether the relevant event dates fall within the 2-year window under NRS § 11.190(3)(d) (using the general/default rule above)
Consistency across rows
- One row says “start date = 1/1/2023,” another says “start date = 12/31/2022”
- One tab uses different date inputs than another tab
Output sanity checks
- Payments jumping dramatically because a single input date shifted by ~30–365 days
- “Correct” formatting with incorrect inputs (this is common when dates are re-typed)
Jurisdiction tag mismatch
- Spreadsheet labeled “US-NV,” but formulas or references were copied from another state’s logic (even if the numbers look reasonable)
Pitfall: If you feed DocketMath dates that fall outside Nevada’s general 2-year limitations window under NRS § 11.190(3)(d), you may produce a clean-looking payment estimate that could be inconsistent with what may be recoverable for the relevant time period. This checker helps you catch the mismatch early.
“Check” logic you can implement in columns
A practical spreadsheet structure looks like this:
| Column | Example input | Checker rule |
|---|---|---|
| A: Event date | 2024-03-15 | Must be a real date (not blank/text) |
| B: Filing date | 2026-01-10 | Must be ≥ event date |
| C: Days between | 672 | Compute automatically |
| D: In limitations window? | TRUE/FALSE | Check uses the 2-year general period under NRS § 11.190(3)(d) |
| E: Flag | blank / “Outside window” | Conditional formatting + clear labels |
Note on implementation: A day-count proxy (for example, “≤ 730 days”) can be a convenient spreadsheet shortcut, but it’s not the same thing as legal timing in every scenario. In spreadsheet terms, this is meant to catch obvious timing mismatches and input errors, not to replace detailed legal analysis.
When to run it
Timing your spreadsheet checker matters. Run it twice: once before you enter inputs into DocketMath, and again after you generate outputs.
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.
Run #1: Right before you launch DocketMath
Do this step while your spreadsheet is still editable:
- Confirm the spreadsheet is set to Nevada (US-NV) logic
- Validate every date field used for the calculation period
- Apply the limitations-window flag tied to NRS § 11.190(3)(d)’s general 2-year period
- If your spreadsheet flags “outside window,” pause and correct the date inputs first
Goal: ensure your timeline is internally consistent and aligned with Nevada’s general/default limitations period before you calculate.
Run #2: Immediately after calculations change
After DocketMath generates outputs, re-check:
- Which inputs drove the highest sensitivity
- Whether a revised date range changed the result more than expected
- Whether any conditional formatting flags you previously ignored are still present
A lightweight approach:
- Add an Input Version field (e.g.,
v1,v2) - Store computed outputs by version
- Compare outputs only after you clear any date integrity warnings
Warning: Updating dates can “fix” one issue while creating another. Treat the 2-year window logic as something you re-validate every time you change start/end dates.
What the checker relies on (Nevada default)
This checker uses the general/default period:
- 2 years under **NRS § 11.190(3)(d)
- No claim-type-specific sub-rule is used because none was found in your jurisdiction data
Try the checker
You can make these checks part of your normal DocketMath workflow.
- Open the DocketMath calculator: **alimony-child-support
- In your spreadsheet, add:
- Event date, start date, filing date (or the relevant timeline dates you’re using)
- A computed “within 2 years?” flag referencing the general NRS § 11.190(3)(d) period
- Feed only verified date ranges into DocketMath
To keep it practical, use a short checklist before you click calculate:
If the checker flags “outside window,” treat it as a signal to correct spreadsheet dates first. Often, the most likely problems are data-entry issues—not “real-world” timing surprises.
Gentle disclaimer: This checker is designed to help you catch spreadsheet errors and obvious timing mismatches. It’s not legal advice and can’t determine case-specific legal outcomes.
