Every time you change an employee's VA Rate or Client Rate on the Employee form, the Salary section requires an Effective Date. It's easy to assume this is just a record-keeping field — it isn't. This is the date payroll actually uses to decide which rate applies to which hours.
For an hourly employee whose rate changes partway through a pay period, Calculate (on the Payroll tab) automatically splits their hours: the days before the change are paid at the old rate, the days from Effective Date onward at the new rate. This shows up as a "Rate changed mid-period" badge with a breakdown tooltip on that employee's row.
The split only ever looks at whatever date is stored as this rate change's Effective Date — it has no other way of knowing when a raise or rate correction was actually supposed to start.
A separate case: if an employee's pay frequency itself changes mid-period — for example an Hourly employee moving to a fixed Monthly rate — Calculate splits that period too, pricing the days before Effective Date under the old frequency and the days from Effective Date onward under the new one. This shows up as its own, distinctly-colored "Frequency changed mid-period" badge, separate from the rate-change badge above.
If more than one salary change lands in the same pay period (e.g. a frequency change plus an unrelated rate bump), the system doesn't guess — it skips auto-calculating that employee and flags it for manual review instead, rather than risk pricing it wrong.
Set Effective Date to the real date the new rate should start paying out — not the date you happen to be sitting down to make the edit.
| Situation | What to enter |
|---|---|
| Raise starts today, entered today | Today's date — the simple case. |
| Raise was approved last week but you're only entering it now | The date it actually started, not today. This is the case most likely to be gotten wrong. |
| Raise is confirmed but shouldn't start until next month | The future start date — save it now, it'll apply from that date once payroll reaches it. |
| Correcting a rate that was wrong from the start of the current record | The original start date of that rate, so the correction applies retroactively across the whole period it should have. |
Payroll splits silently on whatever date is entered — right or wrong. If Effective Date is set to today instead of the real start date, a raise that should have started 5 days ago will only apply from today, and those 5 days get paid at the old rate with no warning that anything's off.
There's no validation catching this — a wrong date looks exactly like a right one until someone notices the pay figures don't match what was promised. If a payroll run looks off for an employee who recently had a rate change, this is the first thing worth checking.
Every rate change is logged automatically — old rate, new rate, who made the change, and the same Effective Date used for the payroll split. This keeps the history consistent: whatever date payroll actually used to split someone's pay is the same date the change history shows for that change.
There's no separate screen for this log today — it exists as a record for support/accounting to check when something needs tracing back, not a self-service view yet.
The mid-period split needs a day-by-day log to split against. If an employee's timesheet for the period came in through Import Hours (bulk hours upload, see the Timesheet Review Manual) rather than normal daily TA Portal submission, there's no day-by-day breakdown to split — Calculate pays the full period at their current rate instead, and flags this in its own warning banner so it's never silent.
| Issue | What to check |
|---|---|
| An employee's pay looks wrong for a period where their rate changed | Check the Effective Date that was entered for that rate change against when it should have actually started. This is the most common cause. |
| No "Rate changed mid-period" badge showing, even though the rate did change | Confirm the employee is on an hourly rate and their frequency stayed the same — a rate change that also changes frequency (e.g. Hourly to Monthly) shows the separate "Frequency changed mid-period" badge instead, not this one. Also check their timesheet didn't come in through Import Hours (see Section 5 above). |
| No "Frequency changed mid-period" badge showing, even though the frequency did change | Check whether more than one salary change landed in the same pay period — if so, the system skips auto-splitting and flags it for manual review instead (see the warning banner on the Payroll tab). Also confirm the change's old/new frequency were actually recorded — a change made outside the normal Edit Employee form (e.g. a bulk data fix) may not have logged them. |
| Rate change was entered for a future date but seems to have already applied | Recalculate hasn't been run again since the future date arrived, or the wrong period was selected on the Payroll tab — the split only takes effect the next time that period is calculated. |