Wage Backpay rule lens: Arizona

The rule in plain language

In Arizona, wage backpay calculations may be affected by the statute of limitations (SOL)—a deadline after which some amounts may be time-barred (not included as recoverable).

For this Arizona rule lens, DocketMath applies the general/default SOL period because no claim-type-specific sub-rule was found in the provided jurisdiction notes.

General SOL period (Arizona): 2 years

• The general rule is tied to A.R.S. § 13-107(A).
• The jurisdiction source provided lists “General Statute: A.R.S. § 13-107(A)” with a 2-year general SOL period.
• Source (jurisdiction reference): https://www.findlaw.com/state/arizona-law/arizona-criminal-statute-of-limitations-laws.html?utm_source=openai

What “2 years” means in practice

For calculation purposes, treat the 2-year SOL like a filter applied to your selected time window:

• Choose a start date (anchor) for when the unpaid wage period begins to run (your matter will determine the correct anchor).
• Count forward 2 years from that start date.
• In many SOL-aware backpay models, any unpaid wage amounts that fall outside that 2-year window may be treated as excluded from recoverable totals (depending on the legal theory and what the tool is configured to show).

Because the output depends heavily on the anchor you choose, the label “2 years” matters less than which dates you plug in.

Why it matters for calculations

In wage backpay models, the SOL usually changes how much time is included in the backpay lookback window. Put simply: the SOL can turn a “long” wage history into a shorter recoverable window.

Small differences in the rule text can change the output materially. Using the correct jurisdiction and effective date ensures the calculation aligns with the authority that applies to your matter.

How the SOL shifts outputs

Most backpay calculations follow a similar structure:

1. Define the period to evaluate.
2. Compute expected wages (based on pay rate/schedule).
3. Subtract wages actually paid (if your inputs/tool configuration support that).
4. Sum the differences across the included period.
5. Apply additional adjustments if configured (credits, offsets, etc., depending on the tool setup).

In this lens, the SOL mainly impacts step 1: which dates are included.

Example scenarios (conceptual):

Input sensitivity: the “start date” anchor

Even with a fixed 2-year rule, changing the anchor date can materially change results. Common workflow anchors include:

• Date each missed wage payment occurred
• Date wages became due
• Termination date (sometimes used as a proxy, depending on wage accrual structure/theory)
• Filing/notice date (if the model counts backward from it)

DocketMath’s wage-backpay lens is built so you can test these choices by changing inputs and observing how the SOL-filtered window (and therefore totals) changes.

Jurisdiction-aware framing (Arizona)

For Arizona in this lens, you apply the general/default 2-year SOL tied to A.R.S. § 13-107(A) (per the jurisdiction notes).

Key point: No claim-type-specific sub-rule was found in the provided notes, so this lens uses a single default window rather than splitting rules by different claim categories.

Use the calculator

Use DocketMath’s wage-backpay calculator to model how a 2-year Arizona SOL window can change the backpay amount.

Primary CTA: ** /tools/wage-backpay

Run the Wage Backpay calculation in DocketMath, then save the output so it can be audited later: Open the calculator.

What you’ll typically provide (and how outputs change)

To see SOL effects clearly, run scenarios that vary the SOL-sensitive inputs. The most important ones are:

• Pay rate / wage structure

  • e.g., hourly rate, salary conversion to hours, and/or whatever structure the tool expects.
• **Unpaid period start date (anchor)

  • This decides which months/weeks are included within the 2-year SOL window.
• Unpaid period end date

  • Used to define the overall unpaid period being evaluated.
• **Actual wages paid (if applicable)

  • If the tool supports it, subtracting paid wages changes net backpay.
• Schedule assumptions

  • Weekly/biweekly/monthly cadence should match your wage pattern inputs.

Quick workflow checklist (practical)

What the output usually tells you

Depending on how the wage-backpay tool is set up, outputs may include:

• Gross backpay for the included window
• Excluded amounts outside the SOL window (if shown)
• Net backpay (if the tool subtracts paid wages or applies configured adjustments)

In practical terms: if your anchor date shifts by even a few months, the SOL filter may exclude or include entire payroll blocks—especially where wages are frequent (e.g., weekly) or include overtime patterns.

Scenario testing (recommended)

Try these three runs to validate that your SOL filter behaves as expected:

• Run A (broad window): earliest start date you think might apply
• Run B (shifted anchor): move the start date forward by 3–6 months
• Run C (tight window): set start date so the total tested period equals 2 years exactly

If Run A includes more days than Run B, you should see differences consistent with SOL exclusion. If Run B and Run C match closely, the earlier portion excluded in Run A likely contributes little (under this lens) to recoverable totals.

Related reading

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