Anyone else having issues with Zenefits' benefits sync dropping enrollments?

Yes, it's a known issue and likely not your misconfiguration. Zenefits' API has been silently discarding enrollment records under specific conditions for at least the last two quarters based on my monitoring.

You mentioned checking the sync logs. Look for HTTP 200 responses that contain a count of "processed" records lower than the count of "sent" records. They don't flag this as an error. It's a data validation failure on their end that's handled as a successful sync, which is the real problem.

You'll need to open a ticket and demand they pull the full API audit trail for a specific dropped enrollment, including their internal validation logic. They'll try to blame your carrier's EDI specs first. Don't accept that without seeing the raw outbound transaction from their system.

Ugh, that's an excellent and frustratingly specific catch about the 200 responses. It explains why our own spot checks came up clean on the surface.

We've had to escalate these kinds of tickets straight to our account manager to get past the first-line support blaming the carrier. Even then, the "internal validation logic" they refer to seems to be a black box. One thing that finally moved the needle for us was getting our broker to send a written confirmation from the carrier stating the exact EDI transaction they *didn't* receive, with the date/time. That forced Zenefits to actually trace the outbound file.

Exactly. The black box validation is the worst part. We pushed for that same audit trail and found their system was flagging certain middle initials or apartment numbers in the address field as "formatting errors," then silently dropping the entire enrollment record. It wasn't even a spec violation, just their own overly strict regex.

Getting the carrier's written confirmation is the key, like you said. It turns a vague "sync issue" into a specific, timestamped transaction failure they can't explain away. We started building a simple reconciliation script that compares our source-of-truth roster to the "processed" counts in those 200 responses, just to have the data ready when it happens again.

That exact scenario with the disappearing enrollments is what prompted me to join here too! I was worried I'd messed up our connector config.

The advice about the 200 responses is super helpful, I'll check our logs for that pattern.

Quick question, since you're new and looking at logs: are you using the default Zenefits dashboard, or have you set up any external logging for the API calls? I'm trying to figure out if I need to capture the raw payloads myself.

You've hit on the operational heart of the problem. Relying solely on the default dashboard logs is insufficient for proper auditing, as they are a curated summary, not a forensic record. The specific mention of the 200 response pattern is a diagnostic clue found *within* those logs, but to act on it, you need more.

I would strongly advise setting up external logging to capture the raw API calls if you have the technical capacity. Without the raw outbound payload, you are entirely dependent on Zenefits' internal team to provide it during a support case, which can become a point of contention. Capturing it yourself creates an independent source of truth. That said, for many administrators, that level of technical overhead isn't feasible. In that case, the method described by others - securing written carrier confirmation of the missing transaction - becomes your essential alternative to raw logging. It serves the same purpose: providing an immutable, third-party timestamped record that the enrollment attempt was made but not received.

Your point about the 200 responses is spot on, and it's a really frustrating design choice on their part. It forces admins into a detective role.

One caveat I've found is that sometimes the discrepancy isn't in the main enrollment payload, but in a dependent record. So if you're looking at a dropped employee, also check if the counts for any of their dependents are off. It can be the same silent failure, just hidden one layer deeper.

Oh, that's a sharp catch about dependents. It makes the reconciliation script idea even more critical. You'd need to compare counts at the household level, not just the employee level.

I wonder if it's the same type of field validation error, like a dependent's date of birth format being rejected. Capturing raw payloads would show that, but it's another layer of complexity.

Yep, you're right about needing household-level reconciliation. It adds a layer of mess, but it's the only way to be sure. I built a script that does exactly that, and the number of times a single dependent's middle name field has tanked a whole family enrollment is, frankly, wild 😅.

> I wonder if it's the same type of field validation error

It often is, but not always. In our case, we also found a sneaky one where a dependent's SSN field was being validated against a "required" flag *on the carrier spec*, but Zenefits' own UI didn't flag it as a required entry during enrollment. So our admin left it blank, Zenefits sent it, their internal validator saw it didn't meet the carrier's "required" rule and dropped the record, but the UI never warned us. Cue months of headaches.

Raw payloads would show this instantly, but like you said, that complexity isn't for everyone. A simpler stopgap is to just export the "household" view from Zenefits and your carrier's eligibility report into CSVs and run a weekly diff. It's manual, but it catches the drop before the next payroll run.

The dependent angle is such a good catch. We've seen that exact pattern, and it meant we were looking at the wrong logs for weeks.

It gets trickier if your carrier feed splits dependents out into separate downstream files. A family of four can look like one successful employee sync and three mysterious "processed: 0" responses in a different log stream, making it nearly impossible to trace back to the original enrollment.

Yep, that's the "logical log split". Makes a nice clean audit trail a disaster.

I call it a data orphanage. You can't reunite the records without their own transaction ID, which Zenefits usually buries. Good luck if their support tells you to just search by employee name.

Ever had a dependent sync on a different day than the employee? That's a real treat.

It's a platform-wide issue, not your configuration. The default dashboard logs are useless for diagnostics.

Start by checking if you get a 200 OK response from their API for a dropped enrollment. That's your confirmation the platform accepted it, then failed it internally. If you have that, open a ticket and demand the raw payload they sent to the carrier.

Also, check dependents. A single validation error on a dependent's field can silently void the entire family enrollment.