Spreadsheet checks before running Damages Allocation in New Hampshire
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Damages Allocation calculator.
Before you run Damages Allocation in New Hampshire with DocketMath, a spreadsheet-style checker can prevent common—and expensive—calculation errors. This matters in NH because the general civil limitations period is 3 years under RSA 508:4, and allocation workflows often rely on timing inputs (dates and intervals) that drive downstream assumptions about what gets included and how it is prorated.
Common spreadsheet issues the checker flags (US-NH)
| Check | What it looks for | Why it matters for damages allocation |
|---|---|---|
| Date sanity | Missing dates, future “event” dates, inconsistent timeline ordering | Many damage schedules effectively depend on “from/to” periods; bad ordering can distort allocated totals |
| Unit mismatches | Dollars mixed with thousands, percentage treated as dollars | Mis-scaled inputs can systematically over/under-allocate every row |
| Arithmetic integrity | Totals that don’t reconcile to line-items | Allocation results become unreliable even if each row appears “plausible” |
| Negative values | Unexpected negatives for charges, payments, or credits | Negative values often mean sign flips or mistaken direction (charge vs. credit) |
| Row alignment | Misaligned columns (e.g., dates shifted one column right) | One shifted column can make the entire allocation wrong while still staying internally consistent |
| Missing category keys | Blank damage type/category fields | Some allocation logic relies on categorization to bucket totals correctly |
| Partial-year proration issues | Uneven proration factors across overlapping intervals | Overlaps and gaps can double count or omit periods |
Pitfall: A spreadsheet can “look consistent” while producing incorrect allocations—especially when dates are shifted by one column. Reconciliation checks help catch this faster than reviewing every row manually.
Jurisdiction-aware guardrails (New Hampshire)
New Hampshire’s general civil statute of limitations is 3 years under RSA 508:4. In this content, there is no claim-type-specific sub-rule found—so you should treat RSA 508:4’s general/default period as the baseline for timing checks.
How the checker uses this rule in practice: it validates whether your modeling timeline appears to fit within a 3-year window based on the accrual/event anchor you specify (the date the timeline is anchored to). If your allocation inputs rely on periods that appear wholly outside that baseline, the checker flags those rows so you can investigate before running the allocation.
Source for the 3-year general period: https://www.thelaw.com/law/new-hampshire-statute-of-limitations-civil-actions.391/?utm_source=openai
When to run it
Run the checker at three points in your Damages Allocation workflow. This sequence is designed to catch spreadsheet problems early—before you generate numbers you might later need to unwind.
Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
1) Before importing data into DocketMath
Use the checker to confirm your spreadsheet inputs are coherent before they enter the calculator. This is where you catch the highest-impact issues:
- swapped columns
- missing dates
- sign errors (charges vs. credits)
- totals not matching line items
2) Immediately after setting your “allocation window”
If your model uses “from/to” periods (for example, a damages start date through an allocation end date), run the checker after you set those boundaries.
Because NH’s baseline is the 3-year general period under RSA 508:4, boundary validation is especially useful.
Checklist:
3) After the output is generated—before you finalize reporting
Finally, run the checker on the populated output tables (even if you trust the math engine). Spreadsheet integrity issues can still happen after transformation, rounding, or copy/paste steps.
Checklist:
Warning: If you skip the “after output” check, you can end up with a table where totals reconcile—but the allocation is still wrong due to mis-bucketed categories (for example, incorrect damage type mapping).
Try the checker
You can run the Damages Allocation workflow in DocketMath here:
- Primary CTA: /tools/damages-allocation
To make the checker most useful, prepare these inputs in your spreadsheet (or in DocketMath’s expected fields):
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Spreadsheet inputs to validate (US-NH)
| Input | What to enter | What the checker will do |
|---|---|---|
| Accrual/event anchor | The date you’re treating as the starting reference | Validates timeline logic; flags allocations that rely on periods outside the 3-year general baseline |
| Allocation start & end | Date range(s) for damages modeling | Checks ordering and whether intervals appear to fall beyond the RSA 508:4 general limitation period |
| Damage line items | Charges, payments, credits, or components | Detects sign issues and arithmetic mismatches |
| Category/type mapping | Your damage categories (even if simplified) | Flags blank/invalid categories and helps ensure totals aggregate correctly |
| Reconciliation totals | Optional but recommended totals | Confirms that line items roll up exactly to the summary totals |
How outputs should change when inputs are corrected
- If you fix date ordering, the allocation engine may reassign which intervals receive proration—so totals can shift even when line-item amounts stay the same.
- If you correct units (e.g., $ vs. thousands), totals should change proportionally across affected rows and categories.
- If you resolve sign errors, you’ll typically observe large changes in net totals (especially where credits or offsets are involved).
- If you fill missing category keys, totals should move out of “unbucketed/blank” areas and into the intended categories.
Note: This is a practical data-quality checklist, not legal advice. Timing issues can be fact-specific, and limitations analysis may require a qualified attorney.