Spreadsheet checks before running Damages Allocation in Hawaii
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Before you run a Damages Allocation calculation in Hawaii (US-HI) with DocketMath, run the spreadsheet-checker first. The goal isn’t to “solve” liability—it’s to prevent spreadsheet errors that can silently skew results, especially when you later validate numbers against time limits (statutes of limitation) and allocation inputs.
This checker is designed to catch issues in three buckets:
1) Date problems that can invalidate the dataset
Hawaii’s general statute of limitations for actions tied to “injury to the person or … property” is 5 years under HRS § 701-108(2)(d). Because no claim-type-specific sub-rule was found in your configuration, the checker uses that general/default period.
The spreadsheet-checker flags:
- Missing or blank event/occurrence date (e.g., accident date, breach date)
- Missing demand/filing date (e.g., complaint filing date or other reference date)
- Dates entered as text (common when copied from PDFs or emails)
- Inverted chronology (filing date earlier than occurrence date)
- Misaligned date columns (e.g., one row uses “Date of Injury” while another uses “Date of Service”)
Note: The checker uses the general 5-year rule from HRS § 701-108(2)(d) because your setup did not identify a narrower claim-specific limitations sub-rule.
2) Allocation math issues that can distort outcomes
Damages allocation spreadsheets typically include inputs like totals, categories, percentages, or components. The checker catches:
- Percentages that don’t sum to 100% (or that sum due to rounding drift beyond a tolerance)
- Totals that don’t equal the sum of line items
- Negative values where only positive values make sense (e.g., “past medical” entered as -1200)
- Unit mismatches (days vs. months; dollars vs. thousands)
- Row-level inconsistencies (e.g., Category A’s amount is computed from one column set while Category B uses another)
3) Court-ready consistency checks (format and structure)
These are spreadsheet hygiene checks that reduce downstream friction:
- Unexpected blank rows inside the calculation range
- Duplicate line items with the same description and identical amounts
- Mixed formatting that breaks formula ranges (e.g., numbers stored as “$1,200.00” strings)
- Column order changes that cause DocketMath to read the wrong fields
A simple way to think about it: the checker tries to confirm that (a) your dates are coherent, (b) your allocations reconcile, and (c) your sheet structure matches what DocketMath expects before you compute.
When to run it
Run the spreadsheet-checker immediately before you use /tools/damages-allocation—ideally at three specific moments:
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) After importing or pasting data
If you copy from another system (case management, settlement tracker, discovery log), do this right away. Data imports are where date parsing and formatting bugs are most likely.
2) After any edits to date fields
Change the occurrence date, filing date, or demand date? Re-run the checker. Even one corrected date can move an item across the 5-year window governed by HRS § 701-108(2)(d).
3) After editing allocation lines (percentages, totals, or component values)
If you adjust “medical,” “lost wages,” “property damage,” or allocate using a percentage approach, re-run the checker to confirm:
- category sums match totals (within a rounding tolerance),
- percentages sum properly,
- no row is missing a required numeric value.
Warning: The limitation window check is only as accurate as your date inputs. If your spreadsheet uses the wrong “reference date” (for example, “service date” instead of “occurrence date”), the checker may flag records incorrectly—or fail to flag them.
Try the checker
You can test the workflow directly with DocketMath:
- Open the Damages Allocation tool: ** /tools/damages-allocation
- Before running the allocation calculation, use the spreadsheet-checker step.
- Feed your worksheet data, then review the checker output.
To make this practical, use this “minimal success criteria” checklist for your inputs:
Spreadsheet setup checklist (Hawaii-aware)
How outputs change when inputs are wrong
Use these common examples to predict what you’ll see:
| Input issue | What the checker flags | Effect on allocation run |
|---|---|---|
| Missing occurrence date | “Date missing” warning | Allocation may still compute totals, but time-window flags will be unreliable |
| Dates entered as text | “Unrecognized date” warning | Allocation may mishandle filtering/validation tied to dates |
| Percentages total 98% | “Percent sum mismatch” | Category totals may not align with expected breakdown |
| Totals don’t equal sum of components | “Reconciliation failure” | DocketMath may allocate based on a wrong basis or expose inconsistencies |
Pitfall: A spreadsheet can look mathematically consistent while still failing date logic. For example, all allocations may reconcile perfectly, but if the occurrence date is later than the filing date, the limitations window logic tied to HRS § 701-108(2)(d) will be internally inconsistent.
Hawaii limitations rule used in the checker
- General/default limitations period: 5 years
- Statute: **HRS § 701-108(2)(d)
- Configuration note: No claim-type-specific sub-rule was found in your setup, so the checker applies the general period as the default.
Gentle disclaimer: This tool-assisted check is for spreadsheet quality and consistency. It’s not legal advice, and limitations determinations depend on facts and proper identification of the relevant “reference dates.”