Spreadsheet checks before running Wage Backpay in Louisiana
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 calculations in Louisiana with DocketMath, a spreadsheet “sanity check” can prevent the most common data and timing errors. This is especially useful because wage-backpay spreadsheets often mix (1) pay-period schedules, (2) compensation components, and (3) date ranges used to limit the recovery window.
Here’s what the Spreadsheet Checker is designed to catch for US-LA:
Wrong or missing “start date”
- If your spreadsheet starts accruing backpay on the wrong day (for example, using the filing date instead of the event date you intended), your totals can shift significantly.
- The checker checks that your “start” and “end” columns are both populated and ordered correctly.
Incorrect time window after applying Louisiana’s general recovery limit
- In the checker’s jurisdiction-aware default for Louisiana, the recovery limit uses a general one-year limitation period.
- The checker references La. Rev. Stat. Ann. § 9:2800.9 and applies a 1-year period as the default.
- No claim-type-specific sub-rule was found for wage backpay in the jurisdiction data you provided. That means the checker does not add special carve-outs; it uses the general/default period for this setup.
- Practically, this is about making sure the sheet’s date logic doesn’t accidentally expand or shrink the eligible range.
Inconsistent pay frequency math
- Many spreadsheets label columns as “per week,” “biweekly,” or “monthly,” but the multiplier logic sometimes uses the wrong factor.
- The checker validates that your pay-period frequency selection matches the number of earning rows implied by your date range—so you don’t end up over-counting or under-counting pay periods.
Compensation component drift
- Wage backpay models often include multiple columns (base wage, overtime, differentials, bonuses).
- The checker flags issues like:
- blank component inputs in rows where they should be populated (or vice versa),
- totals that don’t reconcile to per-period component entries (when your model has a total column), and
- inconsistent sign conventions (for example, mixing positive and negative values without a clear rule).
Overlapping or duplicated pay periods
- If your spreadsheet pulls from multiple sources (for example, an HR export plus manual adjustments), overlaps can double-count days.
- The checker looks for date overlaps and other signs that the sheet contains more rows than the selected pay period length should reasonably produce.
Pitfall to watch: A spreadsheet can be “arithmetically correct” yet still produce an incorrect backpay number if the date window is off by even a few weeks. The checker’s biggest value is catching date-range and window-limit inconsistencies before you rely on the totals.
When to run it
Run the checker before you run DocketMath’s Wage Backpay and again after you update inputs. A practical workflow looks like this:
Build your date schedule
- Generate the list of pay periods between your chosen start and end dates.
- Confirm your pay frequency (weekly, biweekly, semi-monthly, etc.).
Fill compensation columns
- Ensure base wage and any add-ons are consistent with the intended structure.
- For each pay-period row, make sure values are either correctly populated—or intentionally set to 0 where appropriate.
**Apply or confirm your recovery window (Louisiana default)
- For the US-LA checker default, the recovery limit is a 1-year general period tied to La. Rev. Stat. Ann. § 9:2800.9.
- Because no claim-type-specific sub-rule was found in the provided jurisdiction data, the checker applies the general/default period (not specialized buckets).
Run DocketMath Wage Backpay
- After the spreadsheet passes the structural checks, run the calculator and review outputs such as totals and any period breakdowns.
- Also sanity-check the implied number of pay periods against your expectation.
Re-run immediately after edits
- Re-run the checker whenever you change:
- start date / end date / event date,
- pay frequency,
- component column structure,
- bulk edits to compensation figures.
If you’re doing this repeatedly (for example, periodic updates to a damages model), treat the checker as a pre-flight step—a quick “structure check” that catches issues early.
Try the checker
Launch DocketMath’s Wage Backpay flow here: /tools/wage-backpay.
As you prepare your sheet, use these checklist items while running the checker—watching how fixes change the output:
If the start date is blank, the checker may not be able to validate the window reliably.
If the start date is after the end date, period generation may fail or yield zero eligible rows.
The checker applies a 1-year general period for the US-LA setup using La. Rev. Stat. Ann. § 9:2800.9.
Since no claim-type-specific sub-rule was identified in the provided jurisdiction data, you should expect the same general window logic rather than special treatment.
Example: selecting biweekly while your date schedule produces weekly rows can break multiplier logic and distort totals.
For each pay period:
- component entries should roll up correctly into any per-period total column (if your model uses one),
- overtime/differentials should appear only in the periods where your inputs indicate they apply.
Overlaps can produce “too many rows” for the date span.
When overlaps exist, recalculations can jump even if individual row values seem plausible.
When the checker flags something, fix the spreadsheet first, then run the checker again. Spreadsheet logic often depends on row order and column structure, so a date edit can indirectly change which rows are counted.
Gentle note (not legal advice): This checker is a practical spreadsheet QA step, not a substitute for professional legal review. If your matter involves uncertainty about dates, eligibility, or the applicable limitations framework, consider confirming with a qualified professional.