Spreadsheet checks before running Alimony Child Support in New Hampshire

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

DocketMath’s Alimony Child Support calculator for New Hampshire (US-NH) includes a spreadsheet pre-check designed to help you sanity-check the numbers before you run the full calculation workflow. In real use, spreadsheet “silent failures” usually come from timing and date handling—especially when filings, modifications, or payment histories span multiple months.

This checker focuses on one jurisdiction-aware guardrail up front: New Hampshire’s general statute of limitations (SOL) for civil actions. The general/default limitation period is 3 years under RSA 508:4.
Because the brief notes that no claim-type-specific sub-rule was found, the checker treats the 3-year SOL as the default baseline for timing rules (rather than applying different periods by support subtype).

Here’s what the checker typically catches in your spreadsheet before you calculate:

  • Missing or inconsistent “as-of” dates

    • Example: one column uses “today,” another uses the filing date, and a third uses last payment date.
    • Likely result: totals can look plausible while the underlying time windows are inconsistent.
  • Payments or transactions outside the 3-year window baseline

    • If your spreadsheet is set to include amounts older than the 3-year SOL baseline, the checker flags those line items as potentially outside the timing window you’re implicitly analyzing.
    • Practical effect: your “eligible” or “within window” totals may not match what the spreadsheet suggests once the time window is applied consistently.
  • Date parsing errors

    • Common spreadsheet issue: “01/02/2024” interpreted differently depending on regional date settings (Jan 2 vs. Feb 1).
    • Practical effect: month-by-month results can shift by an entire month, changing totals even though the sheet “looks right.”
  • Inconsistent time granularity

    • Some rows may be monthly, others weekly, or irregular, but the rest of the sheet assumes one unit.
    • Practical effect: the checker highlights mismatches so your output isn’t mixing units (which can inflate or deflate totals).
  • Double-counted months from overlapping rows

    • Adjustments (modifications, credits, arrears catch-ups) can overlap the same month.
    • Practical effect: a month’s calculation may be repeated unintentionally; the checker flags overlap based on your date ranges.

Pitfall to avoid: A spreadsheet can produce a smooth-looking chart while still using the wrong date window. These timing checks help prevent “pretty but wrong” outputs.

Jurisdiction-aware rule the checker uses (US-NH)

The checker applies this as the general/default baseline (because no claim-type-specific sub-rule was found). That means the checker is primarily about how far back your spreadsheet reaches, not about automatically classifying every possible category of obligation.

When to run it

Run the checker before you commit to any final calculation pass in DocketMath—especially after importing data from PDFs, hearing summaries, or payment history exports.

Use this timing checklist:

  1. Before first calculation

    • Run it after you enter or import dates and amounts, but before you generate totals.
  2. After any change to the date range

    • If you edit any of the following, rerun immediately:
      • “start date”
      • “end date” / “as-of date”
      • “arrears start”
      • “modification date”
    • Even a small shift can move transactions into or out of the 3-year baseline window.
  3. After adding credits, lump sums, or catch-up rows

    • Retroactive edits can create accidental duplicates.
    • Rerun to confirm month coverage isn’t being repeated or extended beyond the baseline window.
  4. Before exporting or finalizing results

    • Do a last run before you produce a submission packet or internal review output to catch spreadsheet drift.

Inputs the checker is most sensitive to

  • Transaction/payment date
  • The spreadsheet’s analysis start date
  • The spreadsheet’s analysis end/as-of date
  • Any range-based rows (for example, rows that apply “effective from” a certain date)
  • Assumptions about whether data is treated as monthly vs. weekly/irregular

What the output typically looks like

After running the checker, you’ll generally see one of these outcomes:

  • No flags: the time window and date handling don’t show obvious issues—so you can proceed with DocketMath calculations more confidently.
  • Flags on aged/excluded items: the checker may mark older items for review or highlight how your “eligible” totals may differ once the 3-year baseline is applied.
  • Flags on parsing or overlaps: you’ll get guidance about which rows are likely causing incorrect month assignment (for example, date format problems or overlapping ranges).

Friendly note: This is a spreadsheet timing sanity check, not legal advice. Use it to reduce mistakes and confirm your assumptions about the time window and date inputs.

Try the checker

You can run DocketMath’s spreadsheet checks for US-NH and validate your timing assumptions against the 3-year general SOL baseline in RSA 508:4.

Primary CTA: /tools/alimony-child-support

To get the most value out of the checker, structure your spreadsheet so each transaction row includes:

  • A clear payment/transaction date
  • The amount
  • A label/notes field for adjustments (optional, but helpful)
  • Consistent date formatting (avoid mixing formats like MM/DD/YYYY and DD/MM/YYYY)

After you run the checker, review any flagged rows and consider fixes such as:

  • Normalize date formats so they parse the same way across your sheet
  • Adjust your analysis start date to match the window you intended to test
  • Remove duplicates where overlapping ranges cause repeated months
  • Confirm granularity consistency (don’t mix monthly and weekly rows without converting)

Warning: If your spreadsheet includes transactions far older than 3 years, the checker will likely flag them under the RSA 508:4 general SOL baseline. That doesn’t automatically decide eligibility for any specific claim—it helps you prevent time-window errors from contaminating your calculations.

Related reading