Spreadsheet checks before running Alimony Child Support in Hawaii

What the checker catches

Before you run an alimony/child support calculation in Hawaii (US-HI), DocketMath’s spreadsheet checker helps you validate a key timing rule that automated spreadsheets can easily get wrong: whether your input events fall within the applicable statute of limitations (SOL) window.

For this Hawaii US-HI automation, the checker is built around the general/default SOL period. Based on the jurisdiction guidance provided for this content, no claim-type-specific sub-rule was identified—so the checker explicitly treats the 5-year general period as the governing default.

It uses:

• HRS § 701-108(2)(d) — general/default SOL period is 5 years
  Source: https://codes.findlaw.com/hi/division-5-crimes-and-criminal-proceedings/hi-rev-st-sect-701-108/?utm_source=openai

What the 5-year SOL means for your spreadsheet

In practical spreadsheet terms, the checker affects whether rows representing older events are included or flagged depending on how your sheet applies the lookback window.

Common spreadsheet problems the checker catches include:

• Old due dates: Entries older than 5 years from the relevant reference/anchor date can be flagged as potentially outside the SOL under the general rule.
• Mismatched date columns: If you accidentally use a “service date” column where your sheet expects a “due date” (or any other designated SOL-driving date), the 5-year lookback shifts and changes which rows get flagged.
• Off-by-one cutoff errors: Mixing date formats (for example, partial inputs like YYYY-MM with full dates) can push events just inside/outside the cutoff.
• Inconsistent jurisdiction tagging: If your dataset includes non-HI timeline events but you don’t separate them, the checker may apply the Hawaii US-HI default window to records that shouldn’t be assessed under that configuration.

Typical “before calculation” validation items

Use the checker to confirm these items before you compute totals:

When to run it

Run DocketMath’s spreadsheet checks twice as a routine workflow: (1) before calculating, and (2) after you change anything that could alter dates or row inclusion.

Run the checker before importing a spreadsheet into the Alimony Child Support workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) First run: immediately after building the dataset

Do this right after you import or manually enter:

• Payment or obligation event dates
• Any start/end dates used to generate installments
• The reference date your spreadsheet uses to decide what’s “in window”

This first run is where you prevent date issues from cascading into every computed line. It’s also where you catch format mistakes early (e.g., date strings that look right but aren’t real date values).

2) Second run: after every change that can move dates relative to the cutoff

Re-run if you edit anything that could affect whether rows fall inside/outside the 5-year lookback under HRS § 701-108(2)(d), such as:

• Adjusting a start date (even by a few days)
• Changing how installments are generated (monthly → weekly/biweekly, etc.)
• Swapping which date column drives the SOL logic
• Cleaning time fields (converting text to actual date values)

Quick decision rule

If you can answer “yes” to any of these, rerun the checker:

• Did you change the date column used for SOL logic?
• Did you alter the spreadsheet’s reference date (the anchor/lookback measurement date)?
• Did you add rows that include events older than the prior dataset?

Try the checker

Start with the DocketMath calculator/checker here: /tools/alimony-child-support.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

What to prepare in your spreadsheet (inputs)

Before you click through, make sure the checker can interpret your timing inputs consistently:

• Date field accuracy

  • Use real date values (e.g., 2024-06-15), not strings like "06/15/24".
• One source of truth for the timeline

  • Pick a single “event date” that your sheet will treat as the SOL-driving date (for example, each installment’s due date).
• Reference date clarity

  • Choose the date your sheet uses as the “look back” anchor and keep it consistent across the run.

How outputs change around the 5-year boundary

Because the Hawaii US-HI configuration here uses the general/default 5-year SOL under HRS § 701-108(2)(d), the checker’s flags typically change when:

• A row’s event date crosses the 5-year lookback boundary
• The reference date moves forward/backward
• A data-quality issue (like converting text to dates) corrects the true date value

So you may see different results when you:

• Fix a date that was stored as text and becomes a real date
• Move the reference date (e.g., by 30–90 days), which shifts which rows land inside vs. outside the lookback window
• Change installment frequency, which can increase the number of rows that fall outside the window

Simple checklist before you trust the numbers

Use this as a practical guardrail:

If you want the most reliable workflow: keep the first run close to raw data entry, and keep the second run immediately after any date cleanup or structure changes.

Related reading

• Alimony & Child Support Estimator Guide for Alabama
• Alimony & Child Support Estimator Guide for Arizona
• Alimony & Child Support Estimator Guide for Colorado