We all want to believe the robots have it handled!
And to be fair, they mostly do. A 180 integration pushes data one direction, from payroll to your recordkeeper. A 360 sends information back the other way too. Either one dramatically cuts down on human error, and that's a real improvement over someone keying numbers into a portal or uploads a spreadsheet every other Friday.
But an integration isn't set-it-and-forget-it. It's a system with mapping, timing, and triggers, and every one of those was configured by a person at some point, usually years ago, usually based on a plan document that has since been amended. Glitches happen. Mapping shifts. Plan design changes and nobody tells the software, which is long since out of the implementation phase.
The errors don't make themselves known. They surface during compliance testing, an audit, or a call from an upset participant about something you didn't know was happening. By then, the fix is a correction, and corrections cost money.
Here's what to actually check.
Start with the source of truth
The most common integration failure isn't a data transfer error. It's a definition error. The file transmits perfectly. It just transmits the wrong thing, faithfully, every pay period, for eternity or until you stop it.
Compensation. Compare your payroll system's eligible pay codes against your plan document. If your plan includes bonuses and your payroll system leaves them out of the deferral calculation, the integration will report that incorrectly, and it will do it consistently. That leads to one of two outcomes: a testing problem or a correction after someone finally catches it. The pesky ones to definitely check are exclusions like car allowances, gift cards, types of vacation or leave pay.
Deduction codes. Pre-tax, Roth, catch-up pre-tax, catch-up Roth. Matching, Safe Harbor, Nonelective. Each one needs to map to the right source at the recordkeeper.
Here's how this usually shows up. A plan sponsor calls because an employee has unvested money in their account, and they're confused: "We're a safe harbor plan. Everything should be 100% vested."
They're right. The money was transmitted as a regular matching contribution instead of a safe harbor match. The vesting schedule attached itself accordingly. Now the sources have to be switched, retroactively, which is a lot more work than mapping it correctly in the first place.
Loan payments. Two things here. First, confirm repayments are tagged as after-tax and are not being treated as elective deferrals or reducing taxable gross. Second, and this is the one people miss: are the payments starting and stopping on schedule?
If someone's first loan payment was supposed to come out of the first paycheck and it didn't hit until the second, they're already behind and accruing interest. That comes down to timing. When does the recordkeeper's file get to payroll on a 360? Or, if it's a 180, when does the recordkeeper ping you to be the bridge, and does the person who receives that ping know it's their job to act on it?
Hours. This one has come up with two separate clients recently, so it's on my mind.
If you have both hourly and salaried employees, payroll needs to report hours to the recordkeeper for both. What we ran into was salaried employees with no hours reported at all. Their plan requires 1,000 hours to receive a profit-sharing contribution. No hours reported meant no hours on file, which meant those employees were excluded from the contribution.
We caught it, because that's what we do. (We catch things like that. We don't calculate it. Let me be clear.) But catching it didn't fix it. The client had to re-report the census with hours added, rerun compliance testing, and is running profit sharing illustrations again right now as a result.
The other place that hours matter is with long-term part-time employees. Anyone who works at least 500 hours in each of two consecutive 12-month periods has to be allowed to defer their own money into the plan.
Read that twice, because the "each" is the whole thing. It isn't 500 hours added up across two years. It's 500 hours in one 12-month period, and then 500 again in the next one. Two separate tests, both of which have to pass.
You don't have to match those employees. You don't have to give them employer contributions. But the trigger has to be there, and the trigger only fires if hours are being reported. Some recordkeepers don’t even have that trigger – you are the one that has to review it and report eligibility to them.
Do a three-way match
Pick five to ten random employees each quarter, preferably ones with all the possible pay types, and reconcile three things by hand:
The payroll register. What actually came out of the check.
The recordkeeper portal. What actually got deposited in the account.
The participant's election. What they actually asked for.
If the three don't agree, the integration is failing somewhere. Maybe it isn't accounting for a pay type. Maybe it's a rounding issue. Maybe the match isn’t calculating. Maybe it's something nobody has a name for yet. The worst version of this ends in an ADP or ACP testing failure a year later, which is a problem you get to solve with – you guessed it – more money.
This exercise is also how one of our clients discovered they hadn't done the prior year's matching true-up.
Check the timing logic on eligibility and auto-enrollment
If your integration handles eligibility, it triggers actions based on hire dates and hours. This means you should scrutinize the timing of when information moves to the next step as much as the underlying information itself.
Two real scenarios:
Immediate entry. Your plan says an employee is enrolled as soon as they're hired, automatically. But if the recordkeeper hasn't received information about that employee yet, they don't know the person exists, and they can't accept a contribution for someone who isn't in the system. Find out how your file timing interacts with that.
First of the month following hire, monthly entry thereafter. Now add this: your recordkeeper is responsible for sending the auto-enrollment notice, and their process requires 30 days advance notice.
Follow the sequence. They learn the employee exists at some point after the hire date. They send the notice. Thirty days run. Then the next entry date arrives, and only then does the automatic enrollment happen.
You can be 60 days out from where your plan document says that employee should have been enrolled. That's not an oops. That's operating the plan differently than your document says, and every one of those pay periods is a missed contribution if it was automatic enrollment. An audited plan will probably catch it. It's yours to fix either way.
Missed enrollees. Whatever your plan uses as the entry trigger, 90 days, a year, something else, confirm the deductions actually started. On a 180, this depends on your payroll system being programmed correctly. Verify that it fired.
Auto escalation. If your plan has a 1% annual increase, check that payroll updated the percentage on the correct anniversary date. Is that programmed into payroll, or are you relying on the recordkeeper to feed it back? Whichever it is, someone should be able to answer that question without looking it up.
Zombie employees. Make sure termination dates are entered in payroll and that the feed tells the recordkeeper to stop contributions and trigger distribution notices.
What you don't want is a participant who was never marked terminated, who then can't get their money out when they want it, and who sues you because they couldn't take a distribution before a market downturn.
Is that extreme? Yes. Are people also crazy? Yes. Don't open yourself up to unnecessary risk.
Understand your own submission process
This one is about the button.
Review your payroll process, and not only for the redundancy you should have anyway so that more than one person can transmit and oversee. Look at the actual steps involved in getting contributions submitted.
Sometimes it's fully automatic: you run payroll, you're done. Sometimes there's an approval step where you have to review the file and confirm it before it proceeds.
If there's an approval step and nobody clicks it, you have a problem. Payroll runs Friday. The sync doesn't get approved until the following Thursday. That gap can be a late contribution, and late contributions get corrected.
Nobody in that story did anything wrong on purpose. They just didn't know the process had a time-sensitive step waiting on them.
Read the exception reports
Two questions on flags.
Who receives them, and how often? When a file doesn't transmit as expected, when the recordkeeper can't accept it, somebody gets an email. Find out who that is and how often it goes out. Ask your recordkeeper directly because they all have different rules.
Is anyone reading them? If you're the person who gets the error report after every pay cycle, that report has to get reviewed by someone. The common errors are unglamorous: a Social Security number mismatch, a missing address, negative net pay. Some are not: a loan default warning.
We had a case where the sponsor and the participant were both receiving notices. Your loan is about to default. Your loan is about to default. Your loan defaulted.
Then everyone was surprised.
Nobody read them! If a recordkeeper can't process a file because of an error, that's another late contribution, which the sponsor usually has to fix out of pocket.
What to do with this
None of this requires you to distrust the automation. The integration is almost certainly doing what it was told. The question is whether what it was told still matches your plan document, your payroll codes, and the way your organization actually hires and terminates people today.
A reasonable version of this is:
Once a year: compare pay codes and deduction codes against the plan document. Do it when the document changes, too.
Once a quarter: three-way match on five to ten employees.
Once, right now: map the timing sequence for eligibility and auto-enrollment, end to end, and see whether it fits what your document promises.
Every pay cycle: somebody named reads the exception report.
That's it. It's not a big lift, and it's a lot smaller than a correction!
If you're one of our clients, you already know we've had this conversation. If you're not, and you want to talk through your situation or get the full checklist of what else belongs on that list, reach out!