Spreadsheet checks before running Wage Backpay in Georgia
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
Before you run Wage Backpay in Georgia (US-GA) using DocketMath, a spreadsheet-level review can prevent common “garbage in, garbage out” problems—especially those that affect the time window used for calculating backpay.
This checker focuses on issues that appear before your Wage Backpay calculator runs, so your spreadsheet is ready for Georgia-specific (jurisdiction-aware) rules.
Key checks DocketMath’s Georgia Wage Backpay setup will rely on
| Spreadsheet field | What the checker validates | Why it matters for Georgia |
|---|---|---|
| Claim/incident “start” date | It’s a real date (not text), and it parses consistently | The calculator needs a valid start to determine the lookback period |
| Payment “due” dates (if you track per pay period) | Dates are in chronological order and not missing | Misordered pay periods can shift results by weeks or months |
| Last date / “through” date | It’s present and on/after the start date | A missing or earlier “through” date truncates the calculation window |
| Number of work hours (per row) | No negatives, no blanks in populated rows | Backpay totals assume hours are complete and nonnegative |
| Hourly rate or wage basis | Consistent numeric format; no currency symbols mixed in | Rate parsing errors can inflate/deflate damages |
| “Calculated wages” columns | Formulas are present and reference the correct row | A broken formula can silently carry forward wrong numbers |
| Any offsets (e.g., partial payments) | Offsets are tracked separately and not double-counted | Offsets distort the remaining unpaid amount |
The Georgia lookback rule the checker prepares for
DocketMath’s Georgia Wage Backpay workflow uses the general/default statute of limitations period for the claim type where no claim-type-specific sub-rule was found in the jurisdiction rules provided.
- In Georgia, the general SOL period is 1 year, governed by O.C.G.A. § 17-3-1 (General SOL Period: 1 year):
https://law.justia.com/codes/georgia/2021/title-17/chapter-3/section-17-3-1/?utm_source=openai
Important note: This content uses the 1-year period as the general/default SOL window because no claim-type-specific sub-rule was identified. Your spreadsheet should be checked for dates that fall inside vs. outside that 1-year lookback window.
Spreadsheet patterns the checker flags immediately
Check for these “silent failure” patterns that often occur in wage spreadsheets:
- Date columns stored as text (e.g.,
"01/05/2024"that don’t convert reliably) - Mixed date formats (MM/DD/YYYY in some rows, DD/MM/YYYY in others)
- Blank “through” date or hardcoded placeholders
- Hours entered as strings (e.g.,
"40"alongside numeric"35.5") - Row duplication (same pay period entered twice)
- Offsets embedded in the same column as wages (causing double subtraction)
Pitfall: If your spreadsheet includes pay periods older than the SOL lookback window, your totals may appear “wrong”—even if the Wage Backpay calculator is correct—because the calculator’s include/exclude logic may differ from what you expected.
When to run it
Run the checker before you calculate wage backpay totals, and again after any change that could affect dates or wage amounts.
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 timing (practical workflow)
Before the first run
- Confirm date columns parse correctly
- Confirm your “start” and “through” dates bracket the pay periods you want to include
- Confirm hour and rate columns are numeric
After any edit
- If you adjust the incident/start date
- If you change the “through” date
- If you add or delete pay period rows
- If you update hourly rates or compensation basis
Before exporting results
- Confirm totals reconcile to the row-level data (sum checks)
- Confirm offsets (if used) are tracked in the intended column(s)
Inputs you should freeze before calculating
To avoid accidental recalculation drift, freeze the following spreadsheet inputs before using DocketMath:
- Start date used for the wage period analysis
- Through date (end of wage period analysis)
- Wage basis fields (hours, rate, any wage multiplier logic)
- Any offset fields you plan to apply
Warning: Changing a single date input can shift which pay periods fall inside the 1-year general SOL lookback period under O.C.G.A. § 17-3-1, causing total backpay to increase or decrease even if your wage math is unchanged.
Try the checker
You can run the Georgia Wage Backpay workflow in DocketMath here: /tools/wage-backpay.
If you’re building your spreadsheet now, use this quick checklist to align your sheet with the calculator’s expectations. The goal is to make your inputs “calculator-ready,” not to interpret legal rights (this is a data-prep aid, not legal advice).
Spreadsheet readiness checklist (use before clicking Calculate)
How outputs change when inputs change
Use these “directional” checks while validating your run:
- If you move the through date earlier, some older pay periods may fall outside the 1-year lookback window, reducing included backpay.
- If you move the start date later, included pay periods typically shrink, lowering totals.
- If you fix date parsing (text → true dates), amounts previously misclassified may change—especially around the boundary of the 1-year window.
- If you correct hours (e.g., remove blanks/strings), backpay may change row-by-row, often by noticeable amounts on specific pay periods.
For a fast iteration loop: run DocketMath once after major date changes, then re-run after you fix any detected data-type issues in your sheet.