Spreadsheet checks before running Wage Backpay in Arizona
4 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Running DocketMath’s Wage Backpay calculator in Arizona is easiest when you start with a quick spreadsheet QA pass. This checker focuses on the mistakes that typically distort the time window (and therefore the dollars) before you ever press calculate.
Because Arizona wage-related backpay calculations often depend on the applicable lookback period, this spreadsheet checker validates your spreadsheet dates against Arizona’s general statute of limitations (SOL) framework—not a claim-type-specific shortcut.
The Arizona rule the checker is using (default/general)
Arizona’s general SOL period is 2 years, under:
- A.R.S. § 13-107(A) (general statute of limitations: 2 years)
- General SOL Period: 2 years
Note: The checker uses Arizona’s general/default period. No claim-type-specific sub-rule was found, so the content applies the general 2-year SOL as the safe baseline for your spreadsheet workflow.
Spreadsheet issues the checker catches before running Wage Backpay
Use the checklist below to see what the checker is designed to detect:
- “Start date” after “end date”
- One of the two dates left blank
- Text dates like
01/15/2025stored as strings (Excel/Sheets can silently misread these) - Backpay start date not aligned to a 2-year lookback relative to the anchor date you’re using (commonly a notice/filing date or another “as-of” date in your workflow)
- The spreadsheet uses one anchor for some rows and a different anchor for others
- Different employees/pay periods using inconsistent assumptions for the same column (for example, one row uses 40 hours/week while another uses 35 within what’s supposed to be the same weekly-hours structure)
- Period calculations that treat the boundary day inconsistently (common when spreadsheets use inclusive vs exclusive comparisons)
To make this practical, the checker’s output is intended to answer two questions your spreadsheet run will reflect:
| Output the checker surfaces | What it means for your Wage Backpay run |
|---|---|
| “Date range is reversed” | The calculator may compute negative/incorrect elapsed time unless corrected |
| “Backpay start exceeds the 2-year lookback” | The calculator can overstate eligible days if your window isn’t aligned to the general SOL baseline |
| “Inconsistent anchor date across rows” | Totals may combine periods that shouldn’t be combined |
Gentle reminder: this is a spreadsheet QA guide, not legal advice. SOL application can involve additional facts and procedures; consider confirming assumptions for your situation.
When to run it
Run the spreadsheet checks before you commit to a single Wage Backpay number. The goal is to prevent the most common “garbage-in, garbage-out” problems—especially those that distort the lookback window.
Run the checker before importing a spreadsheet into the Wage Backpay workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
Recommended workflow (high signal, low friction)
- Assemble your date inputs
- Pay period start/end (or work-start/work-end)
- The spreadsheet’s anchor date (the date you’re measuring the 2-year lookback from)
- Run the spreadsheet checker
- Fix date order, formats, and boundary logic first
- Lock the corrected date window
- After the checker indicates consistency, keep the dates fixed while you test calculation changes
- Run DocketMath Wage Backpay
- Use the validated inputs to compute totals
- Re-run only if you change inputs
- If you adjust the anchor date, pay periods, or hours, re-run the checker immediately
Where teams usually slip
- Late-stage edits: someone tweaks the anchor date after the backpay window has been computed.
- Copy/paste formatting loss: one tab uses real dates, another uses text dates.
- Mixed logic: boundary conditions implemented in one formula but not another.
Quick rule of thumb
Run the checker any time you touch dates. If you only change hourly rate or hours/week, you may not need a full date re-check—but if any date columns move or are re-imported, re-run.
Warning: If your spreadsheet uses inconsistent date parsing (for example, some dates are imported as text), calculations can “look right” while producing subtly wrong window lengths.
Try the checker
You can jump straight to DocketMath’s Wage Backpay workflow here: /tools/wage-backpay.
Before you calculate totals, do a rapid pre-flight review in your spreadsheet:
- Are you counting the anchor day as included?
- Are you counting the first eligible day as included?
Once those are clean, your Wage Backpay run will be much more reliable.