Spreadsheet checks before running interest in New Hampshire

What the checker catches

Run this scenario in DocketMath using the Interest calculator.

DocketMath’s interest calculator can be a time-saver—but it’s only as reliable as the spreadsheet math feeding it. Before you run interest in New Hampshire, use a spreadsheet sanity-check to catch common issues that can produce the right-looking number for the wrong inputs.

Because New Hampshire’s general civil statute of limitations (SOL) period is 3 years under RSA 508:4, you should also verify that your spreadsheet’s date logic doesn’t accidentally project interest beyond what you intend to calculate. This guide is about spreadsheet hygiene (not legal advice), and it assumes you’re using the general/default 3-year SOL—no claim-type-specific sub-rule was found here.

Here are the most common problems the checker is designed to flag:

• Wrong “start date” for interest

  • Example symptoms: interest begins on the invoice date instead of the demand date, or uses an “entered” date that shifts due to weekends/holidays.
  • Spreadsheet checks:

    • Confirm the start-date column is populated consistently (no blanks, no mixed text like “01/02/2026”).
    • Ensure your dates are true date values (date data type), not stored as plain text.

• Off-by-one day errors

  • Example symptoms: your spreadsheet counts days inclusively when your interest logic expects exclusive counting (or vice versa).
  • Spreadsheet checks:

    • For one sample row, compare end_date - start_date (or your chosen day-count function) against a manual calculation.
    • Validate whether your workflow converts to “days” before applying the rate, or whether it uses “months/years” conversions first (those choices change the output).

• Rate stored as a percentage vs. decimal

  • Example symptoms: entering 8% as 8 when the formula expects 0.08, or entering 0.08 when the formula expects 8.
  • Spreadsheet checks:

    • Confirm the interest function’s expected format (decimal vs. percent).
    • Match your spreadsheet’s rate cell format to the arithmetic used by the calculator and/or your internal formula.

• Accidental compounding

  • Example symptoms: the spreadsheet applies interest on interest (e.g., recalculates principal every period) when you intended simple interest.
  • Spreadsheet checks:

    • Look for loops, repeated “principal += interest” patterns, or re-basing each period.
    • Confirm that the principal input isn’t being overwritten during iterations or copy/paste logic.

• Column alignment / copy-paste drift

  • Example symptoms: each row uses the wrong rate or wrong principal because a formula reference shifted during copying.
  • Spreadsheet checks:

    • Spot-check 3 rows (top, middle, bottom) and verify each one references the correct row’s inputs.
    • Confirm formula references stay within the intended columns and rows.

• Negative or zero day counts

  • Example symptoms: computed day span is negative (start after end/cutoff), or equals 0 when it shouldn’t.
  • Spreadsheet checks:

    • Add a filter to identify rows where days <= 0.
    • Handle missing end/cutoff dates before running DocketMath (otherwise you can get misleading zeros or errors).

When to run it

Timing matters. Run the spreadsheet checker at moments when mistakes are cheapest to fix—before you commit to a dataset and before you trust the output.

Use this sequence:

1. Before you calculate any interest

   • Check data types first (dates and numeric fields).
   • Verify each row includes the required inputs: principal amount, start date, end/cutoff date, and rate.

2. After you import or paste data

   • Any time you pull from invoices, payment logs, or exports (CSV, Excel copy/paste), rerun checks.
   • Imports frequently convert dates into text and can strip number formatting.

3. Right after you change assumptions

   • If you adjust the SOL window logic, rate, day-count method, or simple vs. compound assumptions, rerun the checker immediately.

4. Before final review

   • Do a final spot-check set (for example, 10 representative rows) after everything is wired to output.

New Hampshire context reminder: the workflow here uses the general/default 3-year SOL under RSA 508:4. If your workflow is designed to limit or segment interest by that window, validate your spreadsheet doesn’t accidentally extend interest beyond 3 years when your model intends to stop at the general boundary.

A practical SOL-aware checklist:

Try the checker

You can sanity-check your sheet step-by-step, then run the interest calculation with confidence. Start by isolating one scenario and verifying output sensitivity to inputs.

1. Confirm inputs in one row Pick a single row (not just the first row), and verify:

   • Principal amount: numeric (not “$1,000” stored as text)
   • Start date: real date value
   • End date / cutoff date: real date value
   • Rate: confirm whether DocketMath expects a decimal or percentage format

   Then run the calculation for that row.

2. Change exactly one input and observe the output These quick tests help reveal hidden logic errors:

   • Swap end date by +1 day

     • Expected behavior: interest should change slightly for a day-based calculation.
     • If the output doesn’t change, your spreadsheet may be ignoring day counts.

   • Change principal by +$100

     • Expected behavior: interest should scale proportionally for simple interest.
     • If the scaling is nonlinear, you may have unintended compounding.

   • Change rate from 6% to 7%

     • Expected behavior: interest increases.
     • If the result becomes tiny or explodes, the rate format is likely reversed (e.g., 7 used where 0.07 is expected, or vice versa).

3. Run DocketMath after checks pass When your spreadsheet is consistent on the single-row tests, proceed to calculate the full dataset using DocketMath’s interest tool: /tools/interest.

   While reviewing results, look for patterns:

   • Do different principals produce proportionate interest?
   • Do longer date spans produce larger interest?
   • Are there any rows with zero/negative computed periods?

4. **Sanity-check against the SOL window (general RSA 508:4) Since this workflow is built around the general/default 3-year period, confirm your interest window logic matches that assumption:

Gentle reminder: this is general spreadsheet checking, not legal advice. If your situation involves nuances beyond the general rule, consider consulting a qualified professional.

1. Lock in reconciliation fields Before finalizing, add reconciliation columns so you can debug quickly if a row is off:

This makes it much easier to pinpoint whether an issue is in data typing, date math, rate formatting, or formula references.

Related reading

• Interest rule lens: Maine — The rule in plain language and why it matters
• Common interest mistakes in Rhode Island — Common errors and how to avoid them
• Worked example: interest in Maine — Worked example with real statute citations