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:

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:

ColumnExample inputChecker rule
A: Event date2024-03-15Must be a real date (not blank/text)
B: Filing date2026-01-10Must be ≥ event date
C: Days between672Compute automatically
D: In limitations window?TRUE/FALSECheck uses the 2-year general period under NRS § 11.190(3)(d)
E: Flagblank / “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.

  1. Open the DocketMath calculator: **alimony-child-support
  2. 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
  3. 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.

Related reading