Common Wage Backpay mistakes in Louisiana
6 min read
Published April 15, 2026 • By DocketMath Team
The top mistakes
Run this scenario in DocketMath using the Wage Backpay calculator.
If you’re using DocketMath to estimate wage backpay exposure in Louisiana (US-LA), the calculation is only as good as your underlying assumptions. The most common errors fall into predictable buckets—many of them trace back to how people handle the lookback window and how they enter pay and work-time inputs.
Below are the mistakes we see most often when building a wage backpay model in Louisiana under the general/default limitations period.
Important (default lookback): Louisiana’s General SOL period is 1 year, using the general rule in La. Rev. Stat. Ann. § 9:2800.9. This article describes that general default; no claim-type-specific sub-rule was found for a different period. (If a different period may apply to your situation, consider verifying with a qualified professional.)
1) Using an unlimited lookback instead of the 1-year SOL window
A frequent error is assuming wage backpay can “reach back” indefinitely. In Louisiana, when you’re modeling under La. Rev. Stat. Ann. § 9:2800.9, you should treat the 1-year period as the default lookback.
What goes wrong in practice
- You enter dates that extend more than 365 days before the relevant filing/trigger date.
- DocketMath may compute arrears for the full range if the model inputs aren’t constrained to the 1-year SOL window you intend to use.
Input/output effect: expanding the date range typically increases the number of pay periods included, which can materially raise the total backpay output.
2) Entering hourly totals without reconciling hours vs. rate
Backpay generally comes down to hours × rate (and then adjusted for whatever structure you’re modeling). If you enter:
- an hourly rate that’s slightly off, or
- total hours that already reflect an adjustment,
…your totals can diverge quickly.
Common data mismatches
- Confusing scheduled hours with worked hours
- Mixing overtime-inclusive pay with a base straight-time rate
- Duplicating a differential (for example, adding a shift differential that was already embedded in a “total hourly wage” number)
Input/output effect: a small rate error repeats every period; a hours error repeats even faster.
3) Using incorrect dates for each pay period
People often use one overall “start date” and “end date” for the entire loss period, even though wage computations are typically periodic (weekly/biweekly/semimonthly).
Result
- Pay period alignment errors can inflate or deflate backpay—especially if your SOL lookback cuts through a pay cycle.
Input/output effect: if your pay periods don’t match the actual payroll cadence, DocketMath may include the wrong set of periods (or apply hours/rates to the wrong dates).
4) Failing to separate “earnings received” from “earnings that should have been received”
A common modeling failure is mixing the comparison framework. Backpay modeling is typically about:
- what the employee should have earned, versus
- what the employee actually earned
If you only enter “missed wages” in one column but also adjust another column for the same missing amount, you can double-count the difference.
Input/output effect: the output can look “too high” in a way that doesn’t match any single payroll ledger review, because the delta is effectively calculated twice (once conceptually, once via inputs).
5) Misapplying deductions or offset logic inside the model
Even when you’re keeping the tool simple, you still need consistency about whether inputs are gross or net and how offsets/deductions are treated.
Common mistakes
- Applying deductions in a net field while also using a gross rate
- Omitting offsets when your inputs are already net of those changes
Practical takeaway: decide whether your DocketMath inputs represent gross or net compensation and keep that basis consistent across every period.
Input/output effect: inconsistent treatment often produces a stable-looking but wrong total—because the tool is faithfully computing totals from mismatched bases.
How to avoid them
You can reduce wage backpay mistakes by tightening your inputs and aligning them with how wage computations work in payroll records. These steps are designed to help you get more reliable outputs from DocketMath for Louisiana (US-LA).
Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.
1) Build your date range around the 1-year default SOL
Because Louisiana’s default limitations period is 1 year under La. Rev. Stat. Ann. § 9:2800.9, constrain the modeled timeframe accordingly.
Checklist
**Using DocketMath (practical workflow)
- Start with the broad employment timeline.
- Then restrict the timeline in the tool so the included pay periods match the 1-year default SOL lookback you’re modeling.
2) Use payroll-derived hours per period, not one blended estimate
Instead of entering one average number for hours, enter actual hours shown on timesheets or payroll registers for each pay period that you include.
Checklist
3) Align inputs to pay periods (weekly/biweekly/semimonthly)
Treat pay period alignment as part of your model, not an afterthought.
Checklist
4) Choose one approach: “difference approach” or “missed-wages approach”
DocketMath works best when the story your inputs tell is internally consistent. Choose one approach and stick to it.
Common approach options
- Option A (difference approach):
- Enter expected earnings and actual earnings, then model the delta.
- Option B (missed-wages approach):
- Enter the incremental missing amount directly, and avoid re-deriving the delta elsewhere.
Checklist
5) Keep compensation components consistent with the wage rate you input
If you’re entering an hourly rate, ensure it matches how payroll treats the employee’s pay.
Checklist
6) Sanity-check totals against pay history
Before relying on the result, compare modeled totals to payroll records (as adjusted by your chosen framework).
What to check
- Off-by-one date range inclusion/exclusion.
- Swapped rates (straight-time vs. overtime vs. differential).
- Periods that fall outside the 1-year SOL window you intended to model.
Goal: catch mistakes early by reconciling to real pay records, not by trusting the tool output at face value.