What Is Retro Pay? How to Calculate It

You approved the raise on the 5th, effective from the 1st. Payroll had already closed on the 3rd. Two weeks later you look at the pay run and realize the employee has been working at $20 an hour and getting paid $18, and nobody did anything wrong, and you still owe them the difference.

That is retro pay, and if you run payroll without an HR department it will happen to you. Not because you are careless, but because approving a change and getting that change into a payroll system are two different events separated by a gap, and the employee keeps working through the gap.

This guide is what to do about it: what retro pay actually is, how it differs from back pay, how to calculate it correctly for hourly and salaried staff including the overtime case everyone gets wrong, how it is taxed, how to pay it, what the law requires, and how to stop creating it in the first place. Tracking rate changes and their effective dates is exactly the kind of thing I built FirstHR to handle. One caveat: this touches tax and wage law, the rules vary by state, and I am not a tax professional. Treat this as a map, and confirm the specifics with your accountant.

What Is Retro Pay?

Retro pay, short for retroactive pay, is money an employer owes an employee for work already performed and already paid for, but at the wrong rate. It is the gap between what the employee received and what they should have received, for a pay period that has already closed.

Hold on to one word in there: wages. Retro pay is not a bonus, not a goodwill gesture, and not a discretionary payment. It is money that was already the employee's, that you failed to hand over on time. That framing determines everything else in this article: how it is taxed, how quickly you must pay it, what happens if you do not, and how you should describe it when you do.

Retro Pay vs Back Pay

The two terms get used interchangeably and they are not the same thing. The difference is whether the employee was paid the wrong amount, or was not paid at all.

Read the last two rows carefully, because that is where the stakes live. Retro pay is a bookkeeping correction with a cost equal to what you owed. Back pay, when it arises from a violation, can come with liquidated damages equal to the unpaid wages again, meaning the bill doubles, plus attorney's fees.

The practical takeaway: if you discover an underpayment, correcting it promptly and voluntarily keeps it in the retro pay column. Leaving it, arguing about it, or hoping nobody notices is how it becomes back pay, and back pay is a different kind of problem with a different kind of price.

When It Happens

Retro pay has a small number of recurring causes, and recognizing them is most of the battle, because five of the six are entirely preventable.

The overtime trigger has its own mechanics worth understanding separately, because it is where most of the money hides. Hours that arrive late, a shift differential that was forgotten, or a timesheet approved after the run closed all produce a shortfall that has to be corrected afterward.

Look at the first one, because it accounts for most of them. The structural problem is that the effective date and the approval date are different dates, and the payroll cutoff sits somewhere between them. You decide on Tuesday, it takes effect from the 1st, and payroll closed last Friday. Nobody was slow. The calendar simply does not care about your intentions.

The new hire case deserves a word because it is the most damaging. Someone's very first paycheck is short, because they started mid-period and the setup was not complete, and their first experience of working for you is being underpaid. It is fixable and it is memorable, and it is the reason rate information belongs in new hire paperwork rather than being entered by whoever runs payroll that week.

The last one, misclassification, is not really a retro pay problem at all. If someone was treated as exempt and was actually non-exempt, the overtime they were never paid is back pay, and you should be talking to a professional rather than quietly running a correction.

How to Calculate It

The arithmetic is genuinely simple. What people get wrong is the inputs, and the overtime. Every input comes from your records: the rate history, and the hours. If your time and attendance data is unreliable, the calculation will be too, and no amount of care in the arithmetic will fix a wrong hour count.

Hourly Employees

The simplest case, and the formula is one line: (new rate minus old rate) times hours worked at the old rate.

That is the whole thing for regular hours. Where it stops being one line is when overtime enters the affected period, which is covered below and is the single most common place this calculation goes wrong.

Salaried Employees

Same principle, one extra step: you have to convert the annual salary into a per-period figure before you can compare them.

The mistake here is almost always in the period count rather than the arithmetic. Someone says the raise was effective in March and two runs went out at the old rate, and it was actually three. Count against the payroll records and the effective date, not against what anyone remembers.

Note also that the number of pay periods depends on your pay schedule: 26 for biweekly, 24 for semimonthly, 52 for weekly, 12 for monthly. Dividing an annual salary by the wrong figure produces a per-period number that is wrong in every direction.

Retro Pay on Overtime

Here is the one that catches everybody, and it follows directly from how overtime works. Per DOL Fact Sheet 23, overtime is one and a half times the regular rate. If you retroactively raise someone's base rate, you have retroactively raised their regular rate, and therefore their overtime rate. Correcting the base and forgetting the overtime leaves the employee still underpaid.

Notice that the gap on an overtime hour is $3.00, not $2.00. The raise was $2.00 an hour, but the overtime premium multiplies it: 1.5 times $20.00 is $30.00, against 1.5 times $18.00 which is $27.00. That $1.00 difference per overtime hour is what employers miss, and it compounds across every overtime hour in the affected period.

Commissions and Variable Pay

Commissions produce retro pay constantly, and for a structural reason: the numbers frequently arrive after the payroll run that should have contained them. A deal closes on the 28th, the commission is calculated on the 5th, and payroll went out on the 1st.

The correction itself is straightforward. Calculate the commission that was owed for the period, subtract whatever was actually paid for it, and pay the difference. What is not straightforward, and what employers routinely miss, is the overtime consequence. A commission is remuneration, and for a non-exempt employee it goes into the regular rate for the period it was earned. If that period contained overtime, a corrected commission means corrected overtime as well, apportioned back across the weeks the commission relates to.

The practical fix is to define, in writing, which pay period a commission belongs to and when it will be paid. Most commission-driven retro pay is not really an error at all: it is an undefined process producing predictable lateness.

How It Is Taxed

Retro pay is taxed as wages, fully. What is different is the withholding, because the IRS classifies it as a supplemental wage, and supplemental wages have their own withholding method.

The wider category is worth understanding, because retro pay sits inside it alongside bonuses, commissions, and severance. That is covered in supplemental pay.

Two methods are available and both are acceptable. The flat-rate method: pay the retro pay separately, withhold 22 percent federal income tax, done. The aggregate method: add it to the regular paycheck and run the whole combined amount through the normal withholding tables. The flat rate is simpler and is what most small businesses use.

If you use the aggregate method, the tables you need are in IRS Publication 15-T, which is where all federal withholding calculations actually come from.

The point to internalize, and to tell your employee: 22 percent is a withholding rate, not a tax rate. It is an estimate collected in advance. Their actual tax on that money is settled on their annual return like any other income, and most employees below the top bracket end up slightly over-withheld and get the difference back.

Deductions and Garnishments on Retro Pay

Retro pay is wages, which means the things that come out of wages come out of it too. That has two consequences most employers do not think about until the run is already built.

The first is benefit deductions. If the employee has a percentage-based deduction, most commonly a retirement contribution, the retro pay increases the wages that percentage applies to. A 5 percent 401(k) deferral applies to the retro pay as well, and if you offer a match, the match applies too. A flat-dollar deduction, such as a fixed health premium, does not change: it was already taken correctly, and taking it twice is an error. The distinction is percentage-based versus fixed, and it is the thing to check before you release the run.

If you have any employee with a garnishment in place, the retro pay run needs to account for it. This is precisely the kind of thing that gets missed when a correction is handled as a one-off outside the normal process, which is one more argument for putting retro pay through the regular payroll run rather than around it.

If the Retro Pay Relates to Last Year

This comes up more than you would think, and the answer is cleaner than people expect. Wages go on the W-2 for the year you pay them, not the year they were earned. Retro pay for last October, paid this March, belongs on this year's W-2.

You do not amend last year's W-2 for this, because last year's W-2 was not wrong: it correctly reported what you actually paid in that year. The only time a Form W-2c comes into it is where the original W-2 itself misreported something, meaning you got the numbers wrong rather than simply paying some wages late. Those are different situations and it is worth being certain which one you are in before you file anything.

How to Pay It

Two decisions: when, and how it appears. Neither is complicated, and both have a right answer.

The labeling point is more than cosmetic. Calling retro pay a bonus on a pay stub is wrong in three ways: it misdescribes wages, it tells the employee something untrue about money that was always theirs, and in states with strict wage statement requirements it can create a compliance problem. Some states require the pay stub to show the inclusive dates of the period the payment covers, which for retro pay means naming the period being corrected rather than the period in which you happen to be paying it.

How the payment appears is governed by your state's wage statement rules, and the mechanics of the run itself are covered in the payroll guide. If you are unsure how your own process handles an off-cycle payment, find out before you need to run one.

On timing: the next regular payroll run is the standard and defensible approach. Running an off-cycle payment is available and occasionally right, particularly where the amount is large enough to matter to the employee's month, but it is extra work and it is rarely necessary. What is not acceptable is waiting. An underpayment is already late by definition.

Is It Legally Required?

If the wages are owed, yes. This is the part people occasionally get confused about, so it is worth being blunt: retro pay is not optional and it is not a gesture. It is unpaid wages, and unpaid wages must be paid.

Where the obligation comes from depends on what created the shortfall. If the employee was underpaid relative to the minimum wage or was owed overtime, the obligation is federal, under the Fair Labor Standards Act, and it comes with the enforcement machinery described earlier. If the shortfall relates to a raise you promised, the obligation arises from your own agreement and from state wage law, which is where most retro pay actually lives.

The broader framework of which employment laws reach you, and at what headcount, sits in human resource laws.

The Department of Labor maintains a summary of state payday requirements, which is the fastest way to find out how quickly wages must reach an employee where you operate.

State variation is real and worth checking rather than assuming. Some states have strict wage statement requirements with per-employee, per-period penalties for non-compliance. Some restrict retroactive pay adjustments for public employees. And prompt-payment rules, meaning how quickly wages must reach the employee, differ meaningfully across states. If you have people in more than one state, this is a thing to look up rather than generalize about.

The reassuring version of all this: an employer who finds an underpayment, calculates it correctly, pays it on the next run, and documents what happened is in an entirely defensible position. Almost nothing bad happens to employers who fix things. The problems arise from delay, from denial, and from hoping.

Retro Pay After Someone Leaves

You discover the underpayment after the employee has already gone. This happens, it happens more often than you would expect because departures prompt people to check their records, and it is the version of the problem with the least room for error.

Two things change once someone has left, and both make the situation tighter rather than looser.

The practical instruction is simple: pay it immediately. Not on the next regular run, not when convenient. A former employee owed wages is the one scenario where an off-cycle payment is clearly the right call, because in some states the clock on penalties is already running and every day of delay is a day of exposure.

The prevention is to check for outstanding pay adjustments as part of the exit process, before the final check is calculated. That is a five-minute item on an offboarding checklist, and it is the difference between a routine final payment and a wage claim six months later.

When You Overpaid

The mirror image of retro pay, and it is harder, which surprises people. You paid someone too much. The money was never theirs. Surely you can just take it back?

Generally, no. Not unilaterally. In many states, deducting an overpayment from a future paycheck without the employee's written consent is itself a wage violation, and the fact that they were never entitled to the money does not change that. Wage deduction rules are strict and they do not contain a common-sense exception.

Practically, most employees repay overpayments without drama when they are told promptly and treated like adults. What generates conflict is discovering after four months, and taking the money back without asking. Both of those are avoidable, and the first one is avoidable by checking your payroll runs.

Telling the Employee

An employee who finds an unexplained extra amount on their pay stub does not think my employer fixed something. They think what is this, and is it a mistake, and will they take it back? Which is why this section exists.

Tell them before they see the paycheck, in writing, and show the arithmetic. Five things belong in that message.

Giving employees a way to see their own pay history, through an employee self-service portal, does a surprising amount of this work for you. An employee who can look up what they were paid and when does not need to ask, and does not need to guess.

One further step worth taking, particularly for larger corrections: get a written acknowledgment. Not a legal waiver, and not anything adversarial. Simply a record that you explained the correction, the employee saw the arithmetic, and both parties agree on what was owed and what was paid. A signed acknowledgment costs nothing, takes a minute, and it is the document that resolves the question if anyone ever asks what happened.

This matters more than it sounds, because retro pay conversations tend to be verbal and small businesses tend not to write things down. Six months later, the only record that the correction was explained at all is somebody's recollection of a conversation. That is a weak position to be in, and the fix is a single signed page.

How to Prevent It

Almost all retro pay is preventable, and the prevention is administrative rather than clever. The problem is never that the arithmetic is hard. The problem is that a decision was made in one place and the payroll system found out about it somewhere else, later.

The first item is the one that matters most, and it is nearly free. The effective date is the thing. If you write down, at the moment of approval, that this rate starts on this date, then two things become possible: payroll can be told the right thing, and if the change misses the cutoff, you know immediately that retro pay is owed rather than discovering it later.

The fourth item is the structural fix. Rate history belongs in your HRIS rather than in a spreadsheet, and the reason is retrievability rather than sophistication.

If pay rates and their effective dates live in one retrievable place, retro pay calculations become trivial, because the question what was this person's rate in March has an answer. If that information lives in an inbox and someone's memory, then every retro pay calculation is an archaeology project, and archaeology projects produce errors.

This is the piece I built FirstHR around, and I want to be straightforward about the scope: we do not run payroll. What we hold is the employee record, including the compensation history and the effective dates, so that the information payroll needs exists before payroll needs it. Most retro pay at a small business is not a payroll failure. It is a records failure that shows up in payroll.

Common Mistakes

Six recurring errors, and one of them costs real money while the others cost trust.

The overtime one is the only one with a legal cost, and it is worth restating because it is so easy to miss. A retroactive raise changes the regular rate. The regular rate is what overtime is calculated from. If the affected period contained overtime hours and you corrected only the base pay, the correction itself is an underpayment, and you have now made the same mistake twice.

Two of these are records problems wearing a payroll costume. Counting periods from memory happens because the records are not retrievable, and that is a personnel file problem rather than a payroll one. The same is true of the new hire whose rate was never properly recorded, which belongs in onboarding documents.

The rest are trust failures, and trust failures compound. An employee who was underpaid, then given a confusing correction they did not understand, then found the net smaller than the number they were told, has had three bad experiences from one administrative slip. Each of those was preventable with a sentence.

Frequently Asked Questions