How to run Offer Of Judgment Analyzer in DocketMath for Hawaii

7 min read

Published June 4, 2026 • By DocketMath Team

Under review

missing_or_unverified_packet

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

Step-by-step

This guide walks you through running the Offer Of Judgment Analyzer in DocketMath for Hawaii (US-HI), using jurisdiction-aware rules based on Haw. R. Civ. P. 68. It’s written to be practical and repeatable—whether you’re doing a quick screening run or building a litigation timeline.

Note (Hawaii timing is default): Hawaii’s offer-of-judgment timing uses a default rule: the offer can be served “at any time more than 10 days before the trial begins.” In the provided jurisdiction notes, no claim-type-specific sub-rule was found. So for analyzer runs, use 10 days before trial as the standard cutoff—not a different window by claim type.

1) Open the tool and select the Hawaii jurisdiction

Go to the primary CTA: /tools/offer-of-judgment-analyzer
In the tool’s jurisdiction selector, choose Hawaii (US-HI).

Why this step matters: DocketMath uses the jurisdiction code to apply the correct procedural timing and rule structure for the analyzer run.

2) Gather the inputs you’ll need (before you type anything)

Before starting, collect these values so you can enter them consistently:

Offer date (often entered as the “served” date)
Trial start date (the date you’re counting back from)
Offer amount (monetary offer)
Expected judgment amount (the amount you want to compare against)
Costs treatment assumptions you want the analyzer to reflect (because the rule turns on “costs then accrued”)
If you’re modeling a scenario with non-cash terms: any additional terms affecting the effect specified in the offer (Haw. R. Civ. P. 68 applies to offers “for the money or property or to the effect specified in the offer”)

Input quality tip: If your workflow is timeline-first, it helps to sanity-check dates before you enter them into the analyzer. You can use the internal date tool at /tools/date-calculator.

3) Enter dates using the “served” and “trial begins” anchors

In Hawaii, the key anchor is the rule’s requirement that service occur more than 10 days before the trial begins:

Enter the date the offer is served
Enter the trial begins date

DocketMath will then align your inputs to the >10 days before trial requirement described in the rule.

Rule anchor (Hawaii):
Haw. R. Civ. P. 68 provides (paraphrased for clarity):

“At any time more than 10 days before the trial begins, any party may serve… an offer…”
“If within 10 days after …” (the follow-on timing applies after service)

So your analyzer inputs should reflect the “served” anchor for the >10-day timing, not the trial date itself.

4) Add the comparison numbers

Next, fill in the numeric scenario details:

Offer amount: the amount you offered
Expected judgment amount: the amount you expect the court might award
If the tool supports scenario selection: choose the mode that matches your intended comparison (for example, whether you’re modeling acceptance versus no acceptance). This selection can change how the tool interprets the “offer vs. judgment” direction.

As you enter values, watch how DocketMath updates outputs tied to the rule’s cost-shifting mechanics—those outputs can change even when the offer and judgment numbers look similar, depending on date compliance.

5) Review the analyzer outputs in three lenses

After you run the calculation, review the results using these lenses:

Timing compliance: Does the offer fall within Hawaii’s permitted window (more than 10 days before trial begins)?
Offer vs. judgment comparison: Does the offer “break” the threshold in the direction that matters under the selected scenario logic?
Cost effects: DocketMath translates the procedural mechanism into numeric effects based on your costs-related inputs and assumptions.

Because Haw. R. Civ. P. 68 is procedure-driven, two runs with identical offer and judgment amounts can still produce different outputs if your date inputs differ.

6) Save or iterate with a second scenario

Run at least one follow-up scenario to test sensitivity, especially around the offer/judgment comparison:

Scenario A: expected judgment slightly below offer
Scenario B: expected judgment slightly above offer

Even small changes near the comparison threshold can flip outcomes in an analyzer.

Checklist for a strong second run:

Keep offer served date unchanged (so you isolate comparison sensitivity)
Keep trial start date unchanged (so you isolate comparison effects)
Change only the expected judgment estimate

Common pitfalls

Avoid these mistakes; they’re the ones that most often cause an analyzer run to diverge from how Hawaii’s rule would apply in practice.

Pitfall 1: Treating “10 days” as “10 business days”

Haw. R. Civ. P. 68 uses “10 days”. In the rule text excerpt provided, it’s not limited to business days. If your workflow uses business-day conventions, double-check your method before entering dates into DocketMath. A one-day shift can move the result from “compliant” to “noncompliant.”

Pitfall 2: Swapping “served” and “trial begins”

The timing depends on:

Offer being served more than 10 days before trial begins
A separate “within 10 days after” follow-on window that applies after service

If you enter the trial date in the offer served field (or vice versa), the analyzer’s timing compliance output will be inaccurate.

Pitfall 3: Ignoring that Hawaii’s rule covers more than cash

The rule applies to offers “for the money or property or to the effect specified in the offer.” If your offer includes non-monetary elements, confirm your scenario is mapped correctly in the analyzer. Otherwise, the tool may reflect only the monetary component (depending on how the UI is structured).

Pitfall 4: Costs assumptions that don’t match your scenario

Haw. R. Civ. P. 68 references “costs then accrued.” If you plug in a cost number that doesn’t correspond to the relevant accrual point you intend, outputs can be misleading. A common workflow error is using total projected costs rather than costs that are accrued as of the offer-related moment you’re modeling.

Pitfall 5: Building claim-type-specific timing when none is provided

Your briefing notes indicate no claim-type-specific sub-rule was found for Hawaii in the dataset you referenced. That means you shouldn’t create separate “10-day” rules by claim category inside DocketMath runs. Use the default rule window described in Haw. R. Civ. P. 68.

Try it

Use this quick “sanity check” workflow to run a first pass in DocketMath for Hawaii (US-HI):

Quick run checklist

Set jurisdiction to Hawaii (US-HI)
Enter Offer served date
Enter Trial begins date
Enter Offer amount
Enter Expected judgment amount
Confirm any costs inputs/assumptions reflect “costs then accrued” (per your scenario)

Example workflow (use your real facts)

In DocketMath, keep your Hawaii selection fixed.
Enter:
- Offer served: the date you served the offer
- Trial begins: the first day of trial
Set:
- Offer amount: your offered figure
- Expected judgment amount: your current best estimate
Run the calculation.
Immediately do one adjustment:
- Change only expected judgment amount and re-run.

If the analyzer output changes sharply between these two runs, your scenario is sensitive to the offer-vs-judgment comparison. That’s a good sign to tighten your estimates and re-check your date inputs.

Internal helper: verify date math

If you want a quick way to confirm you’re truly more than 10 days out from trial, use /tools/date-calculator.