Common Alimony Child Support mistakes in New Hampshire

7 min read

Published April 15, 2026 • By DocketMath Team

The top mistakes

Run this scenario in DocketMath using the Alimony Child Support calculator.

If you’re calculating or tracking alimony and child support in New Hampshire, the quickest way to lose time (or money) is to make avoidable mistakes with dates, documentation, and assumptions. This section highlights the most common errors we see when people use DocketMath with the alimony-child-support calculator and then compare results against real-world obligations in US-NH.

Note: This post is practical education, not legal advice. Support and alimony obligations are fact-specific, and court orders control.

1) Using the wrong timeline (and then assuming the result is “close enough”)

Many people enter effective dates loosely—e.g., “around the order date”—and expect the calculator to “average it out.” In practice, even small date shifts can change which months count, and that can meaningfully change totals.

What to watch in DocketMath

  • Confirm you input the correct start date for the obligation and the correct end/termination date (if you’re using a payoff or ending date).
  • If your result seems “off” by an exact multiple of a monthly amount, it’s often a sign a date boundary was placed incorrectly.

2) Forgetting New Hampshire’s general statute of limitations is 3 years

A frequent downstream error: people miss timing deadlines to bring or correct claims about older payment issues, then assume they can address them anytime.

New Hampshire’s general statute of limitations for civil actions is 3 years under RSA 508:4. This is the default/general period—no claim-type-specific sub-rule is identified in the brief for this topic—so treat this as the baseline timing rule, not a tailored rule for every family-law category.

Practical effect

  • If a dispute involves amounts you believe were due (or overpaid) more than 3 years ago, you may face timing obstacles even if your underlying concerns are legitimate.
  • If you’re reviewing payment history, consider reconciling the most recent 36 months first, unless you have a specific reason to believe a different rule applies.

3) Mixing “order terms” with “life changes” without recording the triggering event date

Support obligations often change when certain events occur (commonly employment/income changes, income changes generally, or parenting schedule changes). A common error is updating the calculator with new facts but not documenting the effective date of the change.

Example of the error pattern

  • You update income in DocketMath today, but the order (or modification basis) became effective last month.
  • Result: your output can consistently run too high or too low because the timeline segments don’t match when the change legally took effect.

4) Relying on rough income estimates instead of the numbers reflected in the order

DocketMath can’t infer what a court used. If your order is based on specific income figures (or a defined calculation method), entering rounded or outdated numbers can distort outcomes.

Checklist before running DocketMath

  • Use the same income amounts shown in the order (or the modification paperwork), not a different snapshot you remember.
  • If income is variable (bonus/commission/overtime), check what portion the order includes and use consistent assumptions across the months you’re calculating.

5) Not cross-checking the output structure (monthly vs. totals)

Some users focus on the monthly number and stop there. Others compare totals but skip reconciling intermediate steps.

Quick cross-checks

  • If the result seems plausible but doesn’t match your records, calculate the implied monthly payment and confirm it lines up with what you expected.
  • Watch for off-by-one-month issues caused by start/end date boundaries.
  • Confirm whether you’re inputting annual vs. monthly values where DocketMath expects one or the other.

6) Assuming a calculated number settles enforceability

DocketMath is a calculation tool. It can help you quantify what inputs produce, but it doesn’t determine what a court will enforce, interpret, or allow.

Warning: A “calculated amount” does not automatically mean it is legally owed for enforcement purposes. Court interpretation, order language, and procedural posture matter.

You can use the calculator to organize your questions, but treat the order as the source of what controls—then align your calculations to the order.

How to avoid them

Use a workflow that reduces ambiguity and creates an audit trail. Below is a practical method you can run alongside DocketMath to improve accuracy for US-NH.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Build a date map before you run any calculations

Create a simple table of the dates that govern the obligation.

ItemDateSource you should rely on
Order effective dateYYYY-MM-DDCourt order
Any modification effective date(s)YYYY-MM-DDModification order
Any termination/ceasing date (if applicable)YYYY-MM-DDTermination language / order

Then run DocketMath using those exact dates. If you later discover a date was wrong, rerun the calculation instead of trying to adjust the difference manually.

Step 2: Reconcile within New Hampshire’s 3-year general window (baseline)

Because RSA 508:4 sets a general 3-year statute of limitations for civil actions (default baseline), it’s often efficient to reconcile payment records within the last 36 months first.

Action items:

  • Gather payment history covering the most recent 3 years.
  • Compare ledger totals month-by-month (or the unit DocketMath uses) and flag discrepancies.

If the discrepancy involves older amounts, treat that as a separate review track—don’t bundle everything into a single “overall correction” plan.

Step 3: Match inputs to the order’s terms (not your recollection)

Before you enter numbers into DocketMath:

  • Pull the income figures used in the order (or modification paperwork).
  • Confirm whether amounts are presented as net/gross, annual/monthly, and whether the order includes adjustments.

Quick rule of thumb

  • If your order specifies a method, apply that method consistently in the calculator.
  • If you must estimate, keep estimated fields isolated and label them as assumptions so you can update them later.

Step 4: Track every change as “fact + effective date”

For any event that could alter support/alimony:

  • Identify the fact (income change, schedule change, status change).
  • Record the effective date tied to the court order or documented change basis.

In DocketMath terms, that means you don’t just change numbers—you change the timeline segments that correspond to the change.

Step 5: Use DocketMath outputs as a reality check, not the final authority

When you see a mismatch:

  • Don’t assume the tool is wrong.
  • Check dates, units (annual vs. monthly), and input consistency.
  • After verifying inputs, then consider whether the order’s interpretation differs from your understanding.

Common pitfall: updating only one variable (for example, income) while leaving the dates unchanged can create misleading results that look like “tool error,” even when DocketMath is accurately calculating from your inputs.

If you’re trying the calculator for the first time, consider starting with a narrow range (e.g., the most recent 6–12 months) so you can validate outputs before expanding the timeline.

Related reading