Inputs you need for Wage Backpay in Brazil
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
To run DocketMath (wage-backpay) for Brazil (BR), you’ll generally assemble a clear “pay timeline” showing what the worker should have been paid versus what was actually paid, plus the dates and wage changes that drive those calculations. DocketMath then uses those inputs to estimate backpay totals and the underlying line items you can review/export.
Use this checklist to gather everything before you start:
Full name (or a unique worker ID you use in your records)
Employer legal name (or a unique employer ID)
Job title / role category (or the category used internally)
Start date (e.g., when correct wages stopped being paid)
End date (e.g., when wages were corrected, termination date, or judgment reference date—whatever you’re using as the cut-off for the dispute)
Agreed/contract wage (monthly) for the baseline period
Any subsequent wage changes during the backpay period (effective dates + new amounts)
What the worker should have been paid (monthly amount and any tiers/components your file uses)
What was actually paid (monthly amount and any gaps)
Monthly wages (most common for Brazil salary components)
Whether any portion was paid at another cadence (weekly/biweekly) if your documents show it
Payroll slips / pay stubs for each relevant month (or a consolidated spreadsheet)
Bank transfer records or internal payment ledgers if payroll slips are incomplete
Standard hours per day/week (if you’re modeling an hourly basis)
Overtime hours per period (if applicable)
Enter amounts in **BRL (R$)
Your rounding preference for outputs (e.g., round to 2 decimals)
Any partial payments or supplemental amounts that should offset backpay
Periods you plan to exclude, if your situation requires it (e.g., approved leaves affecting wage entitlement—only include exclusions your workflow supports)
Whether you want gross backpay only or a version of the workflow that accounts for statutory deductions (follow whatever option DocketMath offers during the run)
Gentle warning: Backpay results can change materially based on how you define the “should have been paid” amount and the exact start/end dates. If your timeline is off by even a month, totals can move significantly. If you’re unsure, verify the wage-change effective dates against payroll or wage adjustment notices.
Where to find each input
Below is a practical source map for where you can usually pull each input for DocketMath. The goal is to help you avoid guessing and instead tie each value to a document or system field.
Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.
1) Dates (backpay period)
Look for:
- Employment contract and addenda (for wage terms and effective periods)
- HR records or onboarding paperwork (to confirm effective dates)
- Termination documents (if your end date is termination)
- Payroll ledger or payroll system export showing when correct wages began/stopped
Tip: If you have payroll slips, use them to sanity-check which months actually reflect the wage issue.
2) Wage baseline(s)
Look for:
- Contract salary clause (monthly wage)
- Wage adjustment notices (collective bargaining changes, company policy changes)
- Offer letters or role-change memos with effective dates for promotions/role updates
3) Correct wage vs. actually paid wage
Look for:
- Payroll slips/pay stubs (best evidence for what was paid)
- Bank statements (backup if payroll slips are missing)
- Internal timekeeping records (only if the wage dispute depends on hours)
4) Payment schedule and frequency
Look for:
- HR system or payroll configuration settings (often monthly for base wages)
- Pay slip format/structure (to see how your system reports components)
5) Partial payments and offsets
Look for:
- Payroll slips showing supplemental or partial payments during the dispute period
- Internal payment ledgers (if the worker received payments outside standard payroll runs)
Pitfall to avoid: Entering a single “average paid” figure can misstate backpay if monthly amounts varied. If the data exists, segment by month and use the effective dates of any wage changes.
Run it
Once your inputs are ready, run the wage-backpay calculator in DocketMath.
Enter the inputs in DocketMath and run the Wage Backpay calculation to generate a clean breakdown: Run the calculator.
When rules change, rerun the calculation with updated inputs and store the revision in the matter record.
Tool workflow (step-by-step checklist)
How output changes when you modify inputs
DocketMath’s totals typically move based on two core levers:
- **Time window (date range)
- Moving the end date later usually increases exposure roughly in line with additional months of underpayment.
- Moving the start date later usually decreases totals by removing months from review.
- **Wage definition (should vs. paid)
- Increasing the should-be wage (with an effective date) increases backpay from that date forward.
- Increasing the paid wage (or adding offsets) reduces net backpay for the months affected.
If you enter wage changes as segments (rather than averaging), DocketMath recalculates step-by-step based on each segment’s effective dates.
Audit tip: Keep a simple month-by-month table of “should-be” and “paid” in BRL, aligned to effective dates from your payroll and wage-change documents. This makes it easier to review DocketMath’s line items for accuracy.
Primary CTA (start your run)
Open DocketMath here: **Run wage backpay in Brazil