Spreadsheet checks before running Wage Backpay in Tennessee

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run Wage Backpay with DocketMath for Tennessee (US-TN), a spreadsheet can quietly sabotage your results—especially around the statute of limitations (SOL). The Spreadsheet checker is designed to flag common problems that often look correct (because the sheet produces numbers) while still being wrong inside the legally relevant time window.

1) SOL window mismatch (Tennessee default rule)

For Tennessee, the checker uses a general/default SOL period of 1 year. The relevant statute is:

• Tennessee Code Annotated § 40-35-111(e)(2) (general/default period)
  Source: https://law.justia.com/codes/tennessee/title-40/chapter-35/part-1/section-40-35-111/

Important clarity: The jurisdiction data did not identify a claim-type-specific sub-rule. So DocketMath applies the 1-year general/default period as the checker’s governing window.

What the checker catches:

• Your spreadsheet is including wage/recoupment items older than 12 months from the anchor date you input.
• Your spreadsheet is treating dates inconsistently—such as one formula using an invoice date in one column while another uses a payment date.
• Off-by-one errors at the boundary (for example, items exactly at “1 year ago” being included/excluded incorrectly because of how dates are compared).

Why this matters: Including transactions just outside the SOL window can inflate “backpay owed,” and that inflation can then cascade into downstream outputs like totals, any computed components, or settlement-style ranges you may produce from the same dataset.

2) Date-format and column alignment problems

Wage backpay spreadsheets often have dates coming from exports, manual entry, or mixed formatting. Even if the spreadsheet displays a date correctly, the underlying value may be stored as text, causing comparisons and filtering to fail.

The checker flags patterns like:

• A “Date” column stored as text (e.g., 03/01/2024 that won’t compare reliably to a real date anchor).
• Multiple date columns (e.g., “Work Date” vs “Pay Date”) while formulas reference the wrong one for SOL filtering.
• Row-level misalignment, where the hours value from one row is paired with the wage rate from the adjacent row (so the math becomes internally inconsistent).

3) Wage-rate and hours consistency checks

Backpay calculations depend on internal consistency. The checker can catch input issues that lead to calculations that are arithmetically “reasonable” but conceptually wrong.

Common issues it flags:

• Hours entered as negatives (or unusually large values), which often indicates unit confusion or sign errors.
• Wage-rate units mismatch, such as entering an annual salary where an hourly rate is expected (or vice versa).
• Pay components that don’t net as expected—e.g., wage amounts updated while deductions/adjustments are not, producing totals that don’t reconcile.

4) Output sanity checks against your own totals

Even without offering legal guidance, a good spreadsheet QA step verifies that filtering and period-level calculations behave as expected.

The checker can help you confirm:

• Whether your totals shrink when SOL filtering is applied (they should if your sheet includes older items).
• Whether the checker’s per-period breakdown sums back to your spreadsheet’s grand totals.
• Whether “missing” rows appear due to blank/unparseable dates or unrecognized fields.

When to run it

Run the spreadsheet checker before you execute the Wage Backpay calculation in DocketMath. A reliable workflow is:

1. Lock your anchor date

   • Pick the date your spreadsheet will use as the SOL comparison point.
   • Use that same anchor consistently across the model (no per-tab or per-worksheet drift).

2. Confirm every transaction has a usable date

   • Ensure the date column you intend to use for SOL filtering is formatted/stored as a real date (not text).
   • Confirm the sheet uses the correct date column consistently for all filters and calculations.

3. Run the checker

   • Fix any flags it reports first—especially SOL-related inclusions/exclusions and date parsing issues.

4. Run DocketMath Wage Backpay

   • After SOL filtering and column alignment are correct, the backpay totals are far less likely to be distorted by older or misdated entries.

5. Re-check after edits

   • If you change dates, date parsing, wage-rate mapping, or how rows are matched, run the checker again before trusting the final results.

Try the checker

You can use DocketMath to validate your spreadsheet inputs for Tennessee (US-TN), using a workflow optimized for SOL-related correctness.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

What to prepare in your sheet

Before you run the checker, make sure your sheet has (at minimum):

• A date column (the one you want to use for SOL filtering)
• A hours worked column (or the wage-bearing quantity your sheet uses)
• A wage rate column (the unit your model expects—commonly hourly, but follow your sheet’s structure)
• Any adjustment components your spreadsheet includes (e.g., commissions, overrides, bonuses), if applicable

How the outputs change when SOL filtering is applied

When the checker applies Tennessee’s 1-year general/default window tied to Tennessee Code Annotated § 40-35-111(e)(2), you should expect these behavior patterns:

Next action

Open the DocketMath workflow here to try it: /tools/wage-backpay

If you want the most reliable results, run the checker first, then rerun it after any spreadsheet edits that affect dates or wage-rate mapping.

Related reading

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