Spreadsheet checks before running Wage Backpay in Washington
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Before you run DocketMath’s Wage Backpay calculator for Washington (US-WA), use a quick spreadsheet check to reduce avoidable “garbage in, garbage out” failures. This is especially helpful when your worksheet spans many pay periods, includes job-role or pay-rate changes, or uses partial employment dates.
This Washington checker is grounded in the general statute of limitations (SOL) rule for time limitations in RCW 9A.04.080, with the general 5-year default period:
- General SOL period (default): 5 years
- General statute reference: RCW 9A.04.080
- No claim-type-specific sub-rule was found that would change the SOL period within the scope of this checker—so the 5-year default is the rule used here.
Gentle note: This checker is for spreadsheet integrity and window consistency—not for legal advice.
Even if your formulas are correct, an SOL window mismatch can exclude (or incorrectly include) entire months of wages. The checker focuses on the types of spreadsheet errors that most commonly affect the output by shifting dates, duplicating periods, or misapplying rates.
1) Date boundary errors (the #1 backpay risk)
Backpay spreadsheets often depend on multiple date fields:
- the earliest backpay start date
- one or more employment end dates (e.g., termination, resignation, leave return)
- a pay period start/end date range derived from the spreadsheet
The checker verifies that your dataset aligns to the 5-year lookback window implied by the checker’s default SOL approach (RCW 9A.04.080).
It commonly catches issues like:
- Wrong date formatting (for example, entering a date as a text string that gets parsed incorrectly)
- Swapped or shifted boundaries where only part of a period should be counted
- Using a “last updated” or report date cell as if it were the backpay start date
Warning: One incorrect date input can shift the SOL window and cause multiple pay periods to be wrongly included or excluded.
2) Inconsistent employment ranges across sheets
If you split your workbook into tabs (for example, Time, Comp, and Backpay), the checker compares:
- the worksheet’s overall backpay start/end
- the period-by-period entries that feed totals
- any precomputed subtotals you already rolled up
It flags contradictions such as:
- Tab A uses a range like 2020-01-15 to 2022-03-31, while Tab B uses 2020-02-01 to 2022-03-31
- employment status changes mid-year without updating the date range used by the calculation
3) Pay rate mismatches and unit drift
Backpay math breaks when a rate is treated as the wrong “unit.” The checker looks for patterns like:
- hourly rate entered without a consistent unit (e.g., a value stored as “40” but intended as “40.00/hr”)
- salary entered on an annual basis but interpreted as monthly (or vice versa)
- overtime columns present while overtime logic/rates are missing or mapped incorrectly
These are not “legal” errors; they are spreadsheet integrity errors that can materially distort the computed backpay.
4) Missing or duplicated pay periods
Large worksheets are prone to quiet continuity problems. The checker checks for:
- blank rows that break formulas or stop data alignment
- duplicate pay dates / duplicated pay-period lines (often created during copy/paste)
- gaps where a pay period is accidentally skipped
If you’re working with something like 60–120 pay periods, these discontinuities can be hard to spot visually—but they often explain discrepancies in totals.
5) Currency sign conventions and total rollups
Spreadsheets frequently include negative numbers for adjustments, reversals, or corrections. The checker verifies whether your totals match your intended sign conventions, such as:
- Are adjustments supposed to be subtracted?
- Are reversals already netted into another column?
- Do your “gross” and “net” columns roll up consistently with the row-level logic?
The goal here is to catch totals that “look right” but cannot tie out to the underlying period rows.
When to run it
Run the checker at three moments: before calculating, after importing data, and right before final reporting. This order helps you detect issues when they’re easiest to fix.
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.
Moment 1: Before the first Wage Backpay run
Run the checker before using the calculator. At this stage, you can address:
- date formatting and boundary alignment
- missing columns or misaligned pay-period tables
- inconsistent start/end inputs
Moment 2: After you paste in payroll exports
Payroll data often comes from multiple sources and manual edits. After each import, rerun the spreadsheet checks to catch:
- duplicated pay periods
- pay periods shifted by one day due to timezone/date parsing
- overtime/rate columns becoming absent or mis-mapped after the paste
Moment 3: Immediately before you present totals
Before you publish or share results (monthly breakdown, grand total, or a period table), rerun checks so you can confirm:
- the SOL window filtering logic still matches your latest date inputs (default 5-year SOL)
- period rows and row totals still tie out to your reported totals
Pitfall to avoid: People often validate formulas but never validate the dates those formulas rely on. SOL-window logic is date-driven—treat date inputs like first-class inputs.
Try the checker
A practical way to try this workflow:
- Open your Washington backpay worksheet.
- Confirm you have:
- a backpay start date
- a backpay end date
- a pay period list (or the inputs your sheet uses to generate it)
- the pay rate(s) the worksheet uses (hourly/salary and any overtime assumptions)
- Go to the DocketMath tool page to run Wage Backpay with the checker workflow:
- Primary CTA: /tools/wage-backpay
If you want to verify the setup quickly, use this “input-to-check” map:
| Worksheet component | What the checker validates | Typical error it prevents |
|---|---|---|
| Earliest backpay start date | Date parsing + correct backpay boundary | Wrong date field, swapped parsing, wrong start row |
| Pay period dates | Continuity, duplicates, boundary overlap | Double-counting or skipping periods |
| Rate inputs | Unit consistency + correct column mapping | Annual vs monthly drift, missing overtime mapping |
| Totals rollup | Sign conventions + math tie-out | Totals that won’t reconcile to row-level data |
| Window filtering logic | Uses the default 5-year SOL approach | Including/excluding periods outside the intended window |
After you run the checker, if you see mismatches, fix the underlying worksheet inputs first (especially dates), then rerun before trusting totals.