Why Wage Backpay results differ in Arizona

The top 5 reasons results differ

If you run a wage backpay calculation in Arizona with DocketMath (wage-backpay calculator) and the numbers don’t match what you expected, the difference is usually traceable to one (or more) of five variables. Arizona’s default statute of limitations (SOL) assumption for this calculator is 2 years under A.R.S. § 13-107(A) (this is a general/default period; no claim-type-specific sub-rule was found in the jurisdiction data provided).

1) The time window is anchored to the SOL date

DocketMath applies a 2-year general SOL window (per A.R.S. § 13-107(A)). If one workflow uses a different “anchoring” point—such as:

• a claim filing date, vs.
• a demand/notice date, vs.
• an event date (e.g., termination)—

then the eligible portion of the backpay period shifts. That directly changes total wages (because you multiply different numbers of hours/pay periods by the wage rate).

2) Different “start date” assumptions for backpay

Even when the SOL window is the same, results diverge if the effective backpay start date changes. Common examples include:

• “last day worked” vs.
• “first unpaid pay period” vs.
• “date of a partial pay reduction.”

Because backpay is typically computed over discrete pay periods, even a small date change can add or remove one pay cycle—often enough to create noticeable differences.

3) Pay frequency and wage rate formatting (hourly vs. salaried assumptions)

Two input mismatches often cause the largest swings:

• Pay frequency mismatch (e.g., entering wages as if they’re biweekly when they’re actually weekly)
• Wage format mismatch (e.g., providing an annual salary while the calculator expects an hourly wage and/or a specific workweek conversion)

In DocketMath, the output depends on the relationship between:

• the wage rate, and
• the hours per pay period (which is tied to schedule + pay frequency).

If one run uses an hourly rate correctly while the other run incorrectly converts a salary (or assumes the wrong workweek), the totals will not reconcile.

4) Treatment of partial payments, offsets, or “gap” paychecks

Results differ when two versions treat the same timeline differently, such as:

• One run credits partial payments as reducing backpay.
• Another run treats those amounts as still unpaid (or ignores them).

Similarly, if one run assumes “no income after X” but records show partial income/payments, the eligible unpaid backpay period can shrink or expand depending on how those payments were modeled.

5) Missing or inconsistent work schedule details

Backpay calculations are sensitive to schedule inputs, including:

• scheduled hours per day,
• workdays per pay period,
• whether/how you model overtime.

Even small differences (e.g., 8.0 hours/day vs 7.5 hours/day) compound across many pay periods, changing the computed unpaid hours and therefore the total backpay.

Jurisdiction-aware baseline (Arizona)

For this diagnostic, Arizona’s baseline assumption is a general 2-year SOL under A.R.S. § 13-107(A). Per the provided jurisdiction data, no claim-type-specific sub-rule was identified—so the calculator’s general/default period is the basis to check first.

How to isolate the variable

Use a “controlled runs” approach: change one variable at a time and keep everything else identical.

• 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 checklist (run in parallel)

A simple “difference hunt”

1. Run A with your “expected” inputs.
2. Run B with everything identical except the earliest date input (the backpay start).
3. If the totals change by roughly the cost of an added/removed pay period, the issue is likely the SOL window selection or backpay start date.
4. If dates match, rerun while changing only pay frequency.
5. If pay frequency matches, rerun while changing only wage rate formatting (hourly vs. converted hourly).

What DocketMath is doing (mechanics that matter)

DocketMath helps by structuring:

• the jurisdiction-aware eligible date range (based on the general SOL baseline),
• the wage computation as rate × hours per period, and
• the resulting total backpay across included pay periods.

So when outputs differ, it’s often not a “mystery legal concept”—it’s usually an input convention difference you can spot with controlled reruns.

Next steps

1. Collect your wage timeline in one place:

   • termination/pay stoppage date,
   • first unpaid pay period start,
   • paycheck dates showing any partial payments,
   • the filing/demand date you used (if applicable to your workflow).
2. Choose one convention and stick to it:

   • Use the same definition for “backpay start” and “calculation end” in every run.
   • Standardize wage representation (enter as hourly if the calculator expects hourly, with consistent workweek/schedule assumptions).
3. Run two controlled DocketMath calculations:

   • one with your current “expected” inputs,
   • one with your inputs aligned to the checklist above.
4. Compute the delta (difference):

   • If the difference equals ~X pay periods × Y hours × Z rate, you’ve likely found the wrong date, pay frequency, schedule, or wage-rate formatting.

If you want the fastest path, start with date + pay period alignment, because Arizona’s 2-year general SOL under A.R.S. § 13-107(A) is commonly the first driver of divergence.

Primary CTA: /tools/wage-backpay

Related reading

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