Spreadsheet checks before running Wage Backpay in Brazil

What the checker catches

Running DocketMath’s Wage Backpay calculator in Brazil is much smoother when your spreadsheet passes a jurisdiction-aware set of checks first. This spreadsheet checker focuses on the kinds of issues that commonly cause wage backpay outputs to be wrong, incomplete, or internally inconsistent—especially when you’re computing differences between a “should have been paid” amount and what was actually paid.

A well-prepared sheet typically includes (at minimum) these concepts:

• Pay periods / dates
• Base wages and any variable components (if applicable)
• Backpay rate logic inputs (how you compute “owed” per period)
• Actual payments for each period
• Deductions / offsets (if you model them)
• Currency normalization (if any amounts were entered in different units)

Below are the specific categories the checker catches before you run the calculator.

Common spreadsheet problems that break backpay math

Practical note: A spreadsheet that totals “about right” at the bottom can still be wrong if period-level allocations are inconsistent. Backpay calculators are sensitive to row-level dates and amounts—run the checker even when the final sum seems reasonable.

Brazilian jurisdiction-aware logic checks (BR)

Brazil-specific modeling errors often show up as period allocation and pay component normalization issues. Even without embedding every substantive legal rule into your spreadsheet, DocketMath’s checker can enforce structural rules that support reliable backpay calculations.

Key checks typically include:

• No “floating” totals: each computed amount should tie to a specific pay period row.
• Consistent period cadence: if you’re using monthly periods, all lines should align to months; if weekly, all lines should align to weeks.
• No mixed formats: Brazilian spreadsheets may mix formatting styles like R$ 1.200,50 and 1200.50. The checker flags values that look like currency strings instead of numeric fields.

Pitfall to watch: Rounding and formatting quirks often hide in “format-only” cells. If one column is stored as text (common when copy/pasting currency), results can become unstable across recalculations.

When to run it

Use the checker at three points in your workflow—each time it prevents a different class of failure.

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.

Recommended run cadence

• Before first run of Wage Backpay

  • Catch formatting problems (text numbers, missing fields, date ordering) before you generate results.
• After importing or copying data

  • Common after payroll exports: you paste new rows, then change only some columns.
  • Re-run to catch duplicates and column misalignment.
• After editing business logic fields

  • If you change how “owed” is computed per period (for example, switching from base-only to base-plus-variable), re-run to ensure every row still conforms to the expected structure.

Quick decision checklist

If you changed or received any of the following, run the checker again:

• Did you import data from another system (e.g., payroll CSV export)?
• Did you change your period frequency (weekly ↔ monthly)?
• Did you update or add deductions/offsets?
• Did you alter formatting (currency symbols, thousands separators)?

How output behavior changes after fixes

Once the spreadsheet passes checks, DocketMath’s wage-backpay results typically become:

• Stable across recalculations (the same totals every time you run)
• Traceable period-by-period (so you can explain why the total changed)
• Less sensitive to rounding artifacts caused by string-to-number conversion issues

When checks fail, you may notice symptoms like:

• Results shift drastically after seemingly minor edits
• Rows are excluded unexpectedly due to missing required fields
• Totals flip sign because offsets were entered incorrectly

If you see any of these symptoms, treat it as a prompt to return to the checker results, fix the flagged rows, and re-run.

Gentle disclaimer: This tool-driven validation helps catch spreadsheet and structural issues. It’s not legal advice, and it can’t substitute for a human review of any underlying assumptions in your data.

Try the checker

To start, open DocketMath’s Wage Backpay workflow here: /tools/wage-backpay. You can then connect your spreadsheet to the spreadsheet-checker step before executing the calculation.

Here’s a practical setup sequence to follow:

1. Confirm period columns

   • Ensure each row has a pay period identifier (date-based) and that the chronological order is correct.
2. Verify numeric entry format

   • Currency values should be numeric (not currency strings). If your sheet uses comma decimals (common in Brazil), the checker will reveal which cells are misread.
3. Validate required columns for wage-backpay

   • The checker will flag missing columns rather than guessing.
4. Review row-level flags

   • Fix issues at the flagged row level (duplicates, blanks, invalid dates) instead of relying only on end totals.
5. Run Wage Backpay

   • Once the sheet is clean, run the calculation and review the period breakdown.

If you want a faster starting point, load your draft spreadsheet, run the checker, and address the highest-severity items first. In most workflows, the “severe” issues are formatting and date integrity; resolving those usually reduces the downstream number of flags.

Related reading

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