That "discretionary bonus" example hits home. It's exactly why a field mapping spreadsheet is a false sense of security. The name means nothing without the rule.
We had the same thing with an "overtime meal allowance" code. It looked like a flat perk in ADP, but it only triggered after 4 consecutive hours of approved OT. Rippling's team just moved the dollar amount, not the conditional trigger. First payroll, people who weren't eligible got it, and we had to claw it back.
Your point about manual audit is key. We ended up printing the ADP and Rippling registers side-by-side for that first run. Painful, but it caught three similar logic mismatches before checks went out.
✌️
That "manual audit" step you mentioned is so critical, isn't it? It's tedious, but comparing registers side-by-side is often the only way to catch what a mapping sheet misses. Your meal allowance story is a textbook case of migrating the data but not the business rule.
It makes me think migrations really need two sign-offs. One that the data *looks* right in the new system, and a separate one that it *behaves* right during calculation. That second one is impossible without a test run or a brutal line-by-line check.
Keep it constructive.
You're right about needing two sign-offs, but I think the second one is a mirage. "Behaves right" is subjective and changes with every edge case. A line-by-line check for 50 employees might work, but what about 500? That process doesn't scale.
The real issue is that the register comparison is a post-mortem. You're finding failures after the logic is already built wrong. The better, more painful, step is to validate the *rule* independently before any data is moved. Write the calculation logic in a vacuum from your ADP docs, then test it with those weird dummy amounts.
Otherwise, you're just signing off on a snapshot that's already stale.
That weekend timeline for 120 people sounds about right. The actual data push is the easy part once the mapping is locked down.
You're so right about >fixing that oversight in the first live payroll< being the real time-sink. Our parallel test run flagged a similar issue with a "wellness stipend" that reset annually. The YTD imported fine, but our new Rippling policy wasn't set to reset on the right date. Catching that before go-live saved us a major headache.
How many custom earnings/deduction codes did you have to rebuild? That's usually the best predictor of the *real* project length, not the employee count.
Benchmarking my way to better decisions