Why Wage Backpay results differ in Hawaii

The top 5 reasons results differ

Run this scenario in DocketMath using the Wage Backpay calculator.

When you run a Wage Backpay calculation in Hawaii (US-HI) using DocketMath, different outcomes usually come from differences in inputs or from the way the calculation applies Hawaii’s default statute of limitations window. In other words: even if two people enter the same “headline” wage amount, small date, frequency, or earnings-component differences can change which pay periods are counted and how they’re summed.

1) The pay period start date (or earliest unpaid date) shifts the lookback window

One run might count back 5 years from the filing/trigger date, while another run starts from a different “earliest unpaid” date (sometimes called the start of the underpayment). That single change can alter:

• the included pay periods, and
• the total wage base used for the backpay sum.

Quick tell: If the lookback “start” date differs between runs, the totals will almost always diverge.

2) The filing date (or trigger date) changes what’s in scope

Even a modest change—like using a demand date vs. the filing date (or another trigger date you input)—moves the 5-year window forward or backward. The result is a different set of paychecks included, and therefore a different backpay amount.

3) Partial-period averaging vs. paycheck-by-paycheck summation

Different calculators (or different DocketMath inputs) can lead to different aggregation behavior:

• some methods approximate by averaging wages over time, while
• others effectively sum wages per actual pay period.

With biweekly pay, irregular schedules, or partial periods, averaging can undercount/overcount compared to summing period-by-period. In DocketMath, this frequently shows up when pay frequency isn’t aligned with the real-world schedule.

4) Variable compensation (bonuses, overtime, commissions, shift differentials)

Wage totals can swing dramatically depending on what’s included in “wage”:

• base hourly wage only vs.
• base + overtime, commissions, periodic bonuses, shift differentials, etc.

If one run includes those components and another doesn’t (or they’re entered under different wage categories), you can end up with different outputs even when the dates match.

5) Offsets and deductions assumptions (especially interim earnings)

Even if two runs use the same dates and SOL rule, practical calculations differ when one run assumes no offsets while another includes offsets for interim earnings, unemployment, or other income streams.

DocketMath can’t substitute missing facts—so if offset-related inputs differ (or are left blank vs. filled), the final backpay total can change.

How to isolate the variable

Use a “change one thing at a time” method. The goal is to identify whether the difference comes from the SOL window, the pay-period math, wage components, or offsets.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Quick diagnostic checklist (run this with two versions side-by-side)

Compare the output lines that “explain the mismatch”

If DocketMath shows intermediate line items (or if you can view the calculation breakdown), compare these in Run A vs. Run B:

• Lookback window dates → often driven by trigger date or earliest unpaid date
• # of included pay periods → often driven by boundaries + pay frequency
• Wage rate used per period → often driven by wage-component mix
• Pre-adjustment wage total → often driven by summation vs. averaging behavior
• Final adjusted total → often driven by offsets/deductions settings

Important: Don’t change multiple inputs at once. If you tweak both dates and wages between runs, you won’t know which factor caused the difference.

SOL lens (Hawaii default)

For this Hawaii setup, use the default 5-year SOL as the baseline:

• 5 years under HRS § 701-108(2)(d)
• Treat the period as the general/default window because no claim-type-specific sub-rule was identified in the provided source.

(If your real scenario involves a different limitation period, that’s a separate question—consider asking a qualified professional for guidance.)

Next steps

1. Lock your dates first

   • Decide which date you’re treating as the filing/trigger date.
   • Decide which earliest unpaid date should define the backpay start.

2. Standardize what counts as “wages”

   • Make a short list of included earnings categories.
   • Enter them consistently in both runs.

3. Verify pay frequency

   • If the pay schedule doesn’t match the selected frequency, the included period totals will drift.

4. Document your DocketMath inputs

   • Screenshot or note: dates, pay frequency, included wage components, and offsets/deductions assumptions.
   • This makes it easy to reconcile conflicting numbers.

If you’re trying to reconcile two different numbers from two different versions of an analysis, this workflow typically reveals the discrepancy within a few iterations.

Primary CTA: /tools/wage-backpay

Related reading

• Wage & Backpay Calculator Guide for Alabama
• Wage & Backpay Calculator Guide for Arizona
• Wage & Backpay Calculator Guide for Colorado