Spreadsheet checks before running Wage Backpay in Indiana

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run Wage Backpay calculations in Indiana (US-IN) using DocketMath, you can reduce errors by running a spreadsheet “health check.” Even if DocketMath calculates wage-backpay math reliably, the results can be thrown off when the spreadsheet inputs (dates, rates, and hours) don’t match what the worksheet expects.

This checker is designed to catch practical, spreadsheet-specific issues that commonly distort backpay totals—especially when you later reconcile totals against payroll records or proposed damages schedules. (This is not legal advice; it’s a workflow check to help your calculations reflect your data correctly.)

1) Lookback-window errors (Indiana’s default SOL)

Indiana has a general 5-year statute of limitations (SOL). That default period is stated in Indiana Code § 35-41-4-2. No claim-type-specific sub-rule was found that would create a different lookback period, so the checker should treat 5 years as the default “backpay window.”

What the checker catches:

• Pay periods with dates that fall outside the 5-year lookback window (based on your chosen “as-of” date).
• Worksheets that accidentally use the wrong lookback window (for example, an outdated template set to 4 years, or a copied assumption set to 6 years).
• “Off-by-one” date boundary issues—such as whether your sheet includes or excludes the end date in a way that shifts which periods count.

Why this matters:

• A correct calculator can’t fix incorrect date logic. If the spreadsheet feeds the wrong date ranges into DocketMath, the totals may be systematically too high or too low.

2) Missing or mismatched pay-rate inputs

Backpay spreadsheets often involve multiple rate fields (for example, hourly base rate, overtime-related rates, or different pay categories). Spreadsheet checks should confirm:

• Every time interval has a corresponding pay rate (no blank cells).
• Rates use the correct unit the worksheet expects (e.g., $ per hour, not a pre-multiplied daily/weekly figure).
• Rate values aren’t stored as text (for example, "15.50"). Text values can cause silent failures or incorrect arithmetic depending on formulas.

What the checker flags (typical patterns):

• Blank rate cells for specific dates or pay periods.
• Rates that differ wildly from adjacent rows without an intentional rate-change marker.
• Mixed numeric/text formats in the same rate column.

3) Overtime and time-entry alignment

If your sheet totals hours by week or day, alignment issues can multiply quickly. The checker should verify:

• Hour totals come from the correct date column range.
• Week boundaries are consistent across the dataset (e.g., Monday–Sunday vs. Saturday–Friday).
• Aggregations don’t double-count (for example, when daily rows are already included and then rolled up again into weekly rows).

Practical signs of problems:

• Weekly totals that don’t match the sum of the underlying daily entries.
• A sudden jump/drop at week boundaries caused by an inconsistent date filter.

4) Arithmetic consistency checks

Even when individual numbers look reasonable, spreadsheet math can drift due to copy/paste mistakes, rounding, or formula mix-ups.

The checker should test:

• Row-level consistency: Hours × Rate matches the line item calculation.
• Subtotal consistency: the spreadsheet subtotal equals the sum of line items (not a different range).
• Grand total consistency: the grand total matches the subtotal logic without applying rounding twice.
• Data cleaning artifacts: negative hours or negative pay values created by merges, adjustments, or reclassifications.

A simple validation approach:

• Recompute Hours × Rate using the same date ranges and rate versions your worksheet is using.
• Compare that recomputed subtotal to the sheet subtotal.
• Flag deviations beyond a tolerance you choose (for example, ≥ $1.00 or ≥ 0.1 hours) so you catch meaningful inconsistencies without overreacting to harmless rounding.

5) “As-of” date and reconciliation drift

When you reconcile your spreadsheet to payroll ledgers—or align your totals to a planned SOL window—your “as-of” date has to match across everything you’re using.

The checker should confirm:

• The as-of date used for SOL/lookback is the same one used to determine which rows count.
• Pay periods that span the cutoff date are treated consistently (for example, either split the period or exclude/include in a consistent way across the sheet and DocketMath inputs).

This prevents the common scenario where the calculator output is “right,” but your spreadsheet counts the wrong rows because the as-of date logic diverged.

When to run it

Run the spreadsheet checker at three points in your workflow to catch errors early—before they get locked into final numbers.

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.

1) Before you enter data into DocketMath (first pass)

Run the checker right after you export or copy data into your spreadsheet:

• Confirm date formats are consistent and recognized as dates.
• Confirm pay-rate fields are numeric and in the correct units.
• Confirm the SOL lookback logic is set to Indiana’s default 5-year window (per Indiana Code § 35-41-4-2), driven by your chosen as-of date.

Goal: prevent “garbage in” from becoming “confidently wrong” outputs.

2) After you apply filters or transformations (second pass)

Run it again after transformations such as:

• Filtering to specific employees, departments, or job roles.
• Merging time entries with rate-change tables.
• Pivoting daily → weekly (or weekly → monthly).

Goal: catch lost rows, duplicated rows, or rate mismatches introduced during transformation.

3) After DocketMath output is generated (final verification)

After you generate the Wage Backpay figures:

• Reconcile DocketMath summary totals with your spreadsheet’s recomputed totals using the same inputs and date ranges.
• Look for line-item gaps where one side includes a pay period and the other excludes it.

Warning: If you change the spreadsheet after running DocketMath, re-run the checker. The most expensive errors often happen after the “final” export step, when one cell formatting change breaks date parsing or a join drops rows.

Try the checker

Use DocketMath to perform Wage Backpay spreadsheet checks designed for Indiana (US-IN) workflows. Start by choosing your reference as-of date and ensuring your spreadsheet feeds cleanly into the tool.

Primary CTA: /tools/wage-backpay

Practical input/output map to keep your worksheet aligned:

Spreadsheet input fields to verify

• Pay period start/end dates: valid dates, consistently formatted
• Hourly rate(s): numeric, correct units
• Hours worked: non-blank, roll up correctly, no unintended negatives
• Chosen as-of date: drives Indiana default lookback (5 years, per Indiana Code § 35-41-4-2)

Output behavior you should expect

• Periods outside the 5-year lookback window should be excluded or flagged, based on how your worksheet is structured to feed the tool.
• Totals should reconcile when you compute hours × rate using the same date ranges and rate versions.

Quick “go/no-go” checklist

Related reading

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