What Is an EDI 834 File? A Plain English Guide for HR and Benefits Teams

A carrier sends over an implementation packet, and somewhere inside it is a document called a companion guide. It runs forty pages. It references ANSI ASC X12N 005010X220A1 on the second page and never explains what that means. If you have not worked with one of these before, the packet assumes a lot of knowledge you were never given a reason to have.

An EDI 834 is the file that tells an insurance carrier who is enrolled, in what plan, and starting when. That is the entire job. Everything else in the companion guide is detail about how to say those things in a format the carrier's system can process without a person reading it.

Who sends an 834 and who receives it

The 834 moves in one direction. The plan sponsor sends, the carrier receives.

In practice the sender is rarely the employer typing anything. It is the benefits administration system, the HRIS, the payroll provider, the PEO, the TPA, or a data partner transmitting on the employer's behalf. The employer's role is usually to make sure the elections in the source system are correct and current. What happens after that is a machine-to-machine handoff.

The carrier does not answer with an 834 of its own. Premium billing comes back as an 820, which is a separate transaction type. Technical acknowledgments come back as TA1 or 999 files, and this distinction matters more than it sounds: those files confirm that your transmission was structurally valid, not that the enrollments inside it were accepted. A file can pass every structural check and still result in an employee having no coverage.

What is actually inside the file

An 834 is a plain text file. Opened in a text editor it looks like this:

INS*Y*18*021*28*A***FT~REF*0F*123456789~NM1*IL*1*RIVERA*ANA****34*555001234~DMG*D8*19880412*F~HD*021**HLT*PPO PLAN A*EMP~DTP*348*D8*20260101~

Six lines, one employee. Read in order, they say: this is a subscriber, she is enrolling herself, this is a new addition, the reason is initial enrollment, her status is active, she works full time. Her subscriber ID is 123456789. Her name is Ana Rivera. She was born April 12, 1988. She is electing health coverage under PPO Plan A at the employee-only tier, effective January 1, 2026.

Every 834 is built from that same set of ideas repeated for every member:

• Identity. Name, date of birth, gender, subscriber ID, and often SSN.

• Relationship. Whether this person is the subscriber or a dependent, and if a dependent, what kind.

• Coverage. Which product line, which plan, and at what tier.

• Dates. Eligibility begin, eligibility end, and coverage effective dates.

• Maintenance type. What you are asking the carrier to do with this record.

That last one causes more trouble than the rest combined.

Maintenance type codes, and why they matter

The maintenance type code sits in the INS segment and tells the carrier the intent of the record. The ones you will see most:

Code	Meaning
021	Addition. A new enrollment.
001	Change. Something about an existing member is different.
024	Cancellation or termination.
025	Reinstatement.
030	Audit or compare. This record is a statement of current truth, not a request to change anything.

A termination that goes out coded 001 instead of 024 does not terminate anybody. The carrier reads it as a change to an active record and keeps billing. The file transmitted successfully. Nothing about the transmission log looks wrong. The first evidence anyone sees is an invoice two months later that still includes someone who left in March.

Full file or changes only

Carriers accept 834s in two broad styles, and the choice affects what your feed catches.

A changes only file contains just the activity since the last transmission. New hires, terminations, qualifying life events, plan changes. It is small, it is fast, and if a record fails to generate for any reason, nothing downstream notices, because an absent change looks identical to no change having happened.

A full file contains your entire enrolled population every time, usually coded 030. The carrier compares what you sent against what it has on record and reconciles the difference. It is larger, it takes longer to process, and it catches the records a changes only feed would have quietly dropped.

Most carriers have a preference and some have a requirement. It is worth confirming which style a carrier expects before an implementation starts rather than after the first file gets rejected.

The three ways an 834 fails

Structural rejection. The file is malformed, a required segment is missing, or the envelope is wrong. The carrier rejects the whole transmission and sends back a 999. This is the best kind of failure, because it is loud and immediate.

Member level rejection. The file is fine, but individual records inside it are rejected. Invalid plan code, missing SSN, an effective date outside the eligibility window, a dependent whose subscriber does not exist in the carrier system. The carrier processes the file and returns a discrepancy report listing what it could not apply. If nobody reads that report, those members are not enrolled and everybody involved believes they are.

Silent acceptance. The file transmits, the carrier accepts it, and nothing happens with the contents. Wrong directory on the SFTP server, a file naming convention that no longer matches what the carrier's automated pickup expects, a connection that succeeds against a server that stopped reading that path months ago. Every log says success.

We wrote about one of these on our own system last year and what it changed about how we monitor transmissions. Silent failures are the category worth building process around, because the other two announce themselves.

What happens downstream

The consequences of a bad 834 land on people, not on systems.

An enrollment that never reaches the carrier means an employee finds out at a pharmacy counter that they have no coverage. A termination stuck in limbo means the employer keeps paying premium for someone who left, and carriers have grown less flexible about retroactive refunds. A deduction file that does not match the carrier invoice means somebody in payroll spends the last week of every month reconciling by hand.

Those three situations share a cause. Data left the source system correctly and something went wrong between there and the carrier.

Where the 834 fits among your other feeds

The 834 is the standard for medical, dental, and vision enrollment, and it is the file most people mean when they say carrier feed. It is not the only feed a benefits program runs on.

Retirement and 401(k) contribution files, COBRA notification and eligibility data, FSA and HSA funding, wellness and EAP enrollment, voluntary and ancillary lines, leave and absence data, payroll tax and garnishment reporting: each of these moves on its own format, on its own cadence, to its own vendor. Benefit Cloud supports nine feed types across that full range, and the 834 is one of them.

The reason that matters is that an organization running eight vendors is running eight versions of the problem described above. Each one has its own file format, its own error reporting, and its own way of failing quietly.

If you are the one holding the companion guide

You do not need to learn X12 syntax to run a benefits program well. What you do need is the ability to answer three questions at any moment: did the file go out, did the carrier accept what was in it, and can I prove what we sent.

Benefit Cloud sits between your HRIS or payroll system and every carrier and vendor you send data to. We build and maintain the connections, translate your data into whatever format each recipient requires, and give you transmission history you can look at yourself rather than request from someone. Typical implementation runs 8 to 12 weeks, and we do not bill for a feed until it is live in production.

Ready to simplify your benefit feeds?

Book a demo and we will walk through your current set up.