Spreadsheet checks before running Wage Backpay in Arkansas

What the checker catches

Before you run Wage Backpay in DocketMath for Arkansas (US-AR), it helps to run a spreadsheet sanity check that focuses on statute-of-limitations (SOL) timing and basic arithmetic consistency. DocketMath’s wage backpay calculator can produce totals quickly—but a fast result can still be wrong if your spreadsheet inputs are off by even one pay period.

This checker is designed to catch the most common issues that show up right before you press /tools/wage-backpay.

1) SOL window misalignment (Arkansas default)

For Arkansas wage-backpay calculations, this checker applies the general/default SOL period of 6 years under Ark. Code Ann. § 5-1-109(b)(2).

Key point: No claim-type-specific sub-rule was found in the jurisdiction data you provided—so the checker uses only the general/default 6-year period as the rule baseline.

What the checker catches:

• Using a different SOL length in the spreadsheet than 6 years
• Calculating the lookback from the wrong date (for example, using the claim filing date when your sheet uses the work end date)
• Assuming the SOL only affects totals—when it actually affects which pay periods are included

2) Date-column inconsistencies

Backpay is date-driven, so spreadsheet problems often hide in the date layer rather than in the wage math.

The checker catches:

• Mixed date formats (e.g., one tab stores dates as text like "1/5/24" while another uses real date values)
• Missing dates for pay periods (blank date cells in the pay-period range)
• Off-by-one errors caused by end-of-week vs. paycheck dates (for example, shifting a pay period to the next day and accidentally moving it into or out of the lookback)

3) Pay-period coverage gaps

Even with correct SOL logic, missing or duplicated rows can distort results.

The checker catches:

• Weeks/periods that exist in a master pay table but don’t roll into the wage backpay table
• Duplicate pay periods (two rows representing the same timeframe)
• Coverage gaps caused by filtering (e.g., a spreadsheet filter applied before exporting the dataset you paste into the tool)

4) Output-to-input mismatch

Once the calculator runs, the checker helps confirm that your spreadsheet totals align with the component structure used as inputs (so you can trust the resulting backpay number).

The checker catches:

• Totals that don’t reconcile when you recompute from component columns (such as gross vs. net, or totals by period)
• Misapplied columns (for example, using “regular hours” where the tool expects an hourly rate to derive wages)
• Sign errors (negative wage lines, or deductions entered with the wrong sign convention)

Quick checklist of common “red flags”

Gentle reminder: this is a practical spreadsheet validation step, not legal advice. SOL application can depend on case-specific facts and how dates are defined in your dataset.

When to run it

Run the spreadsheet checker right before you calculate wage backpay with DocketMath. In practice, it should be your last validation step after you:

1. Consolidate payroll/pay-period data,
2. Compute intermediate columns (hours, hourly rates, gross wages),
3. Decide what “start” and “end” dates define each pay period row.

A practical workflow (recommended order)

1. Build or import your pay-period rows (one row per pay period).
2. Normalize dates (make sure they are real date values, not text).
3. Compute period wages from the columns you trust most.
4. Set the anchor date for your 6-year lookback logic (see below).
5. Run the checker to exclude anything outside the SOL window and flag spreadsheet issues.
6. Then run DocketMath using the cleaned inputs at /tools/wage-backpay.

How the SOL window changes your inputs

The checker doesn’t just “warn”—it affects what gets included.

• If a pay period is inside the 6-year window: its wage figure remains eligible for the calculator total.
• If a pay period is outside the 6-year window: the checker marks it as excluded, so your total reflects only eligible periods under Ark. Code Ann. § 5-1-109(b)(2) (general/default 6 years).

Anchor date: be consistent across your sheet and your run

Your spreadsheet will likely use one of these as the anchor for the lookback:

• the filing date you’re modeling, or
• the work end date for the relevant period,

depending on how your sheet is structured.

Whatever anchor you choose, keep it consistent:

• the checker’s exclusion logic must match the anchor your spreadsheet uses
• don’t mix an anchor used for filtering with a different anchor used for summary totals

Try the checker

Ready to validate your spreadsheet before running Wage Backpay? Use DocketMath with jurisdiction-aware checks for Arkansas (US-AR), then proceed to the calculator.

1. Open DocketMath Wage Backpay: **/tools/wage-backpay
2. Paste or map your pay-period data into the tool workflow.
3. Run the spreadsheet checks to confirm:

   • date integrity,
   • pay-period coverage,
   • SOL window inclusion using 6 years under Ark. Code Ann. § 5-1-109(b)(2).

What you should expect to change after the checker runs

Use this “before/after” mental model:

Data inputs to double-check (fast)

• Pay period start and pay period end (or a single pay-period date your sheet uses)
• Wage amount per period (the gross wages figure you intend to back out)
• Hours and rate columns if DocketMath expects them to derive wages
• Any included/excluded filters you applied earlier—ensure they’re not accidentally removing eligible periods

Related reading

• Wage & Backpay Calculator Guide for Alabama
• Wage & Backpay Calculator Guide for Arizona
• Wage & Backpay Calculator Guide for Colorado