EDI 834 Benefit Enrollment and Maintenance Guide

The EDI 834 is how a health plan learns who it covers. HR adds a new hire, a spouse joins at open enrollment, an employee leaves: each change reaches the carrier or third-party administrator as an 834. If the file is wrong, people show up at the pharmacy without active coverage, or stay on the plan months after they left and the premium bill goes with them.

This guide covers what the 834 carries, who sends it, the difference between full and change files, every segment benefits teams map, two live examples (an addition and a termination), how the 834 relates to the 820 premium payment, and the errors that cause rejections and coverage gaps. It explains the file format only: your carrier's companion guide and your benefits and compliance advisers govern eligibility rules and legal obligations.

What Is an EDI 834?

An EDI 834 is the Benefit Enrollment and Maintenance transaction set defined by ASC X12, used by a plan sponsor to send enrollment, change, termination and verification data for its members to a health plan or administrator. In the US it is one of the HIPAA standard transactions. The federal rule at 45 CFR 162.1502 names the X12 technical report 005010X220 as the enrollment standard, and in practice files carry the errata version 005010X220A1 in GS08 and ST03.

Authoritative references for 834 work:

• 45 CFR Part 162, administered by CMS, lists the adopted HIPAA transaction standards, including the 834, 835 and 837
• The X12 005010X220A1 technical report (TR3) defines every loop, segment and code used in a HIPAA 834
• Carrier and state companion guides, such as the Wisconsin ETF 834 companion guide, show which elements a specific receiver requires and which codes it accepts

Who sends it? The plan sponsor: an employer's HR or benefits system, a benefits administration platform acting for the employer, a union trust, or a government program. Exchanges and state Medicaid agencies also send 834s to the plans they contract with.

Who receives it? The health plan (insurer, HMO, dental or vision carrier) or a third-party administrator (TPA) running a self-funded plan.

When is it sent? On a schedule the two sides agree: daily or weekly change files are common, with a full file sent periodically or after open enrollment.

Why does it matter? The 834 is the carrier's record of who is covered and from when. Claims are adjudicated against it, eligibility responses (271s) are built from it, and premium bills are calculated from it.

Full Files and Change Files

The first decision in any 834 build is whether each file carries everyone or only what changed. BGN08 (Action Code) declares it.

Many carriers want both: daily or weekly change files plus a monthly full file to catch drift. Ask the carrier how it treats members missing from a full file before sending one. Some terminate them automatically; others report discrepancies for review.

The 834 Enrollment Workflow, Step by Step

1. Event in HR. A hire, a qualifying life event, an open enrollment election or a termination is recorded in the HR or benefits system.
2. Build the file. The system collects members with changes since the last run and builds an 834, one INS loop per member, subscriber first and each dependent after.
3. Send. The file goes to the carrier or TPA, usually by SFTP or through a clearinghouse.
4. Acknowledge. The receiver returns a 999 Implementation Acknowledgment saying whether the file passed X12 and TR3 validation.
5. Load and report. The carrier loads the members. Most carriers also send an error or discrepancy report in their own format for members they could not load (for example, an unknown plan code).
6. Bill and pay. The carrier bills premiums based on enrollment. The sponsor pays, often with an EDI 820 premium payment listing the members or groups the payment covers.

Interactive Example: New Hire and Spouse (INS03 021)

A fictional employer adds a new full-time employee and spouse to a PPO medical plan and a dental plan, both at the employee-and-spouse level, effective 1 December 2026. The subscriber's INS loop is Y, relationship 18 (self), maintenance type 021 (addition), reason 28 (initial enrollment). The spouse follows with N and relationship 01. Each person carries one HD loop per coverage with a 348 coverage begin date. All names, IDs and organizations are fictional.

Use the Plain English tab for a readable summary, or click any segment to see each element.

Interactive Example: Termination of Employment (INS03 024)

The same employer ends coverage for a different fictional employee and child after the employee leaves. Both INS loops use maintenance type 024 (cancellation or termination) and reason 08 (termination of employment), with an eligibility end date (357) at member level and a coverage end date (349) on each HD loop.

834 Structure at a Glance

The TR3 has more loops (reporting categories, employer responsible party, custodial parent and others). Carriers' companion guides say which ones they read.

Key Segments Explained

BGN: Beginning Segment

BGN*00*ENR20261101A*20261101*0900****2~

N1: Sponsor (1000A) and Payer (1000B)

N1*P5*SAMPLE MANUFACTURING CO*FI*990000010~
N1*IN*SAMPLEVILLE HEALTH PLAN*FI*990000001~

P5 identifies the plan sponsor and IN the insurer or administrator. Both usually carry a federal tax ID (FI) in N104, though the carrier's guide may ask for its own assigned group or sponsor ID instead.

INS: Member Level Detail

INS opens each member's loop and says what is happening to that member.

INS*Y*18*021*28*A***FT~

INS06 (Medicare status), INS07 (COBRA qualifying event), INS10 (handicap indicator) and INS12 (death date) are situational and appear only when they apply. Which reason codes a carrier accepts with each maintenance type is a common companion-guide restriction.

REF: Subscriber Identifier and Policy Number

REF*0F*ZZE00451~
REF*1L*GRP778899~

REF*0F carries the subscriber's identifier and repeats, unchanged, on every dependent's loop: it is how the carrier ties the family together. REF*1L carries the group or policy number. Other REF qualifiers (department, employee ID, prior coverage) appear when the carrier's guide asks for them.

NM1, DMG and Address: Member Name and Demographics

NM1*IL*1*SAMPLE*TAYLOR****ZZ*ZZE00451~
DMG*D8*19880412*F~

Whether to send a Social Security number is set by the carrier's guide and your own privacy policies. The samples on this page use a mutually defined ID (ZZ) and fictional values.

HD: Health Coverage

One HD loop per coverage the member is in: medical, dental, vision, and so on.

HD*021**HLT*PPO 500*ESP~
DTP*348*D8*20261201~

The DTP under each HD carries 348 (benefit begin) and, on terminations, 349 (benefit end). An HD with a plan code the carrier does not recognize is the most common reason a member fails to load.

DTP: Member and Coverage Dates

A termination usually needs both: 357 says when the member's eligibility ends, and 349 on each HD says when that coverage ends. Sending only one is a frequent companion-guide rejection.

How the 834 Relates to the 820, 270/271 and 835

The 834 and 820 are a pair. Reconciling them (are we paying for exactly the people we enrolled?) is where many benefits teams find terminated employees still on the bill, or new hires the carrier never loaded.

Common 834 Errors and How to Prevent Them

834 Implementation Checklist

Before going live with a carrier or TPA:

• Get the carrier's 834 companion guide and confirm it uses 005010X220A1
• Agree full file, change file or both, and the schedule for each
• Agree the action code (BGN08) and maintenance type for each file type
• Build a plan code (HD04) and coverage level (HD05) mapping table with the carrier
• Agree the identifiers: subscriber ID in REF*0F, member IDs in NM109, group numbers in REF*1L
• Confirm how the carrier treats members missing from a full file
• Confirm its retroactive add and termination windows
• Test additions, changes, terminations, reinstatements and a full file
• Set up monitoring for the 999 and the carrier's error report
• Reconcile enrollment against premium bills or 820 payments monthly

For background on how X12 envelopes and acknowledgments work, see our EDI document types reference and the 997 functional acknowledgment guide.

Reading 834 Files With OrderSync's Free Inspector

When a carrier rejects a file or a member does not load, the first step is reading the 834 itself. Paste any X12 file into the free EDI inspector to see the envelope, each member's INS loop, coverage lines and dates broken out segment by segment, with control-number and segment-count problems flagged. It runs in your browser and needs no signup. Use the sample files on this page, or files with personal data removed, when you are trying it out. For converting X12 to other formats, the EDI to JSON converter and EDI translator work on the same files.

Frequently Asked Questions