What Happens to Payroll When a Pay Rate Changes Mid-Period?
You give an employee a raise on the 15th. Their pay period runs the 1st through the 31st. Payroll day comes around — what rate applies to the hours they worked before the 15th?
If you answered "whatever rate is in the system when payroll runs," you're not alone — that's what most timesheet and payroll tools actually do, because it's the easy thing to implement. It's also wrong, and it under- or over-pays someone every single time a rate changes.
The correct answer
Hours worked before the rate change should be paid at the old rate. Hours worked on or after the change should be paid at the new rate. The two amounts get added together for that pay period. It sounds obvious written out like that — but it requires the system to actually remember rate history, not just the current number.
Why this quietly goes wrong
Most tools store exactly one rate per employee: a single number that gets overwritten the moment someone updates it. The instant you change it, every hour that employee ever worked — past and future — is retroactively treated as if it had always been the new rate. Run payroll for a period that straddles the change, and the whole period gets paid at whichever rate happens to be set at the moment you click "run," which is almost never correct for the days before the change.
For a small team this might mean a $20 error nobody notices. For a larger crew, or a rate change that happens to land near a bigger raise, it adds up — and it's the kind of mistake employees notice immediately, because it's their paycheck.
What it takes to get right
- A rate history, not a rate field. Every rate change needs to be recorded with the date it took effect, not just overwrite the old value.
- Per-entry resolution. Each clocked hour needs to be matched against whatever rate was in effect on the day it was worked — not the rate in effect today.
- Clear visibility when it happens. Whoever's running payroll should be able to see, at a glance, that a rate changed partway through the period they're looking at — not just a total that quietly blends two rates together with no explanation.
The same logic applies on the billing side too — if a client's rate changes mid-period, the invoice should split the same way payroll does, for the same reason.
Flow Agenda handles this automatically
Every rate change is recorded with an effective date, and every hour is paid (or billed) at the rate that was actually in effect when it was worked — no manual splitting, no spreadsheet math. Free for small teams, 30-day trial for the rest.
Start your free trial