# EDI 834 Benefit Enrollment and Maintenance Guide

> EDI 834 explained: the HIPAA 5010 enrollment file, INS, REF, NM1, HD and DTP segments, maintenance codes, full vs change files, examples and common errors.

<QuickAnswer>
The EDI 834 Benefit Enrollment and Maintenance is the HIPAA X12 transaction an employer, union or government agency uses to tell a health plan who to enroll, change or terminate. Each member gets an INS loop with identifiers, demographics and one HD loop per coverage. Under HIPAA it uses the 005010X220 implementation guide.
</QuickAnswer>

**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.

<EDIGuideCTA
  transactionType="834"
  headline="Check an 834 before the carrier does"
  body="Paste an 834 into the free EDI inspector to see each member loop, coverage line and date broken out segment by segment, with envelope and control-number problems flagged."
/>

## What Is an EDI 834?

**An EDI 834 is the Benefit Enrollment and Maintenance transaction set defined by [ASC X12](https://x12.org/products/transaction-sets), 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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-O/section-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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/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](https://etf.wi.gov/sites/default/files/2024-07/Appendix%201%20-%20834%20Companion%20Guide.pdf), 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](/guides/edi/271-eligibility-benefit-response)) 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.

| | Change file | Full file |
|---|---|---|
| **BGN08** | `2` (Change (Update)) | `4` (Verify) or `RX` (Replace), per the carrier's guide |
| **What it contains** | Only members with an addition, change, termination or reinstatement since the last file | Every currently enrolled member |
| **INS03 on members** | `021` addition, `001` change, `024` termination, `025` reinstatement | Often `030` (Audit or Compare), or the carrier's specified value |
| **What the carrier does** | Applies each transaction | Compares against its own records, and may terminate anyone missing |
| **Main risk** | A missed file means a missed change | A member accidentally left out may be terminated |

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](/guides/edi/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](/guides/edi/820-payment-order) 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.

<EDISample id="834-enrollment-add" />

## 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.

<EDISample id="834-enrollment-termination" />

## 834 Structure at a Glance

| Loop | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Header | **ST** | Transaction Set Header | Required | `ST01` = `834`, `ST03` = `005010X220A1` |
| Header | **BGN** | Beginning Segment | Required | Purpose, reference, date, time, action code |
| Header | **REF** | Transaction Set Policy Number | Situational | `REF01` = `38`, master policy number |
| Header | **DTP** | File Effective Date | Situational | `007` effective, plus report dates where used |
| Header | **QTY** | Transaction Set Control Totals | Situational | Counts some receivers use to check the file |
| 1000A | **N1** | Sponsor Name | Required | `N101` = `P5` |
| 1000B | **N1** | Payer | Required | `N101` = `IN` |
| 1000C | **N1** | TPA/Broker Name | Situational | Broker or administrator, where relevant |
| 2000 | **INS** | Member Level Detail | Required, repeats | One per member, subscriber first |
| 2000 | **REF** | Subscriber Identifier | Required | `REF01` = `0F` |
| 2000 | **REF** | Member Policy Number | Situational | `REF01` = `1L`, group or policy number |
| 2000 | **DTP** | Member Level Dates | Situational | Eligibility begin `356`, end `357`, employment begin `336` |
| 2100A | **NM1** | Member Name | Required | `NM101` = `IL` |
| 2100A | **PER, N3, N4** | Communications and Address | Situational | Contact numbers and residence address |
| 2100A | **DMG** | Member Demographics | Situational | Date of birth and gender |
| 2300 | **HD** | Health Coverage | Situational, repeats | One per coverage line |
| 2300 | **DTP** | Health Coverage Dates | Required with HD | Begin `348`, end `349` |
| 2310 | **LX, NM1** | Provider Information | Situational | Primary care provider selection, where the plan requires one |
| 2320 | **COB** | Coordination of Benefits | Situational | Other coverage the member has |
| Trailer | **SE** | Transaction Set Trailer | Required | Segment count and control number |

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~
```

| Element | Name | Example | What it means |
|---|---|---|---|
| **BGN01** | Transaction Set Purpose Code | `00` | Original. Some guides allow `15` (re-submission) |
| **BGN02** | Reference Identification | `ENR20261101A` | Your file reference. Keep it unique |
| **BGN03** | Date | `20261101` | File creation date |
| **BGN04** | Time | `0900` | File creation time |
| **BGN08** | Action Code | `2` | `2` Change (Update), `4` Verify, `RX` Replace |

### 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~
```

| Element | Name | Example | What it means |
|---|---|---|---|
| **INS01** | Member Indicator | `Y` | `Y` subscriber, `N` dependent |
| **INS02** | Individual Relationship Code | `18` | `18` self, `01` spouse, `19` child, and other codes the TR3 lists |
| **INS03** | Maintenance Type Code | `021` | `021` addition, `001` change, `024` cancellation or termination, `025` reinstatement, `030` audit or compare |
| **INS04** | Maintenance Reason Code | `28` | Why: `28` initial enrollment, `08` termination of employment, `07` termination of benefits, `03` death, `01` divorce, `XN` notification only, `AI` no reason given |
| **INS05** | Benefit Status Code | `A` | `A` active, `C` COBRA, `S` surviving insured |
| **INS08** | Employment Status Code | `FT` | `FT` full-time, `PT` part-time, `TE` terminated, `RT` retired, and others |

`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~
```

| Element | Name | What it means |
|---|---|---|
| **NM101** | Entity Identifier Code | `IL` for the member in loop 2100A |
| **NM102** | Entity Type Qualifier | `1` person |
| **NM103 / NM104** | Last and first name | The member's legal name as the carrier should hold it |
| **NM108 / NM109** | ID qualifier and ID | `34` Social Security number, or `ZZ` a mutually defined identifier |
| **DMG02** | Date of birth | `CCYYMMDD` |
| **DMG03** | Gender code | Values per the TR3 and the carrier's guide |

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~
```

| Element | Name | Example | What it means |
|---|---|---|---|
| **HD01** | Maintenance Type Code | `021` | Same codes as INS03, applied to this coverage |
| **HD03** | Insurance Line Code | `HLT` | `HLT` health, `DEN` dental, `VIS` vision, and others |
| **HD04** | Plan Coverage Description | `PPO 500` | The carrier's plan or option code. Must match its setup exactly |
| **HD05** | Coverage Level Code | `ESP` | `EMP` employee only, `ESP` employee and spouse, `ECH` employee and children, `E1D` employee and one dependent, `FAM` family, `IND` individual |

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

| Qualifier | Where | Meaning |
|---|---|---|
| `007` | Header | Effective date of the file |
| `336` | Member (2000) | Employment begin |
| `356` | Member (2000) | Eligibility begin |
| `357` | Member (2000) | Eligibility end |
| `348` | Coverage (2300) | Benefit begin |
| `349` | Coverage (2300) | Benefit end |

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

| Transaction | Sent by | Purpose | Relation to the 834 |
|---|---|---|---|
| **834 Benefit Enrollment** | Plan sponsor | Who is covered, by which plan, from when | The source of enrollment |
| **[820 Premium Payment](/guides/edi/820-payment-order)** | Plan sponsor | Pays premiums and lists what the payment covers | Pays for the coverage the 834 created. HIPAA names `005010X218` for premium payments |
| **[270 Eligibility Inquiry](/guides/edi/270-eligibility-benefit-inquiry)** | Provider | Asks whether a patient is covered | Answered from enrollment data |
| **[271 Eligibility Response](/guides/edi/271-eligibility-benefit-response)** | Health plan | Returns coverage and benefits | Reflects what the 834 loaded |
| **[837 Health Care Claim](/guides/edi/837-health-care-claim)** | Provider | Bills for care | Adjudicated against enrollment |
| **[835 Claim Payment/Advice](/guides/edi/835-health-care-claim-payment-advice)** | Health plan | Explains claim payments | Denials for "patient not eligible" often trace back to the 834 |
| **[999 Implementation Acknowledgment](/guides/edi/999-implementation-acknowledgment)** | Receiver | Confirms the file passed X12 and TR3 validation | Returned for each 834 file |

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

| Error | What happens | Prevention |
|---|---|---|
| **Plan code in `HD04` not set up at the carrier** | Member rejected or loaded without coverage | Agree a plan code table with the carrier and validate against it before sending |
| **Dependent missing `REF*0F` or using its own number** | Dependent not linked to the subscriber | Repeat the subscriber's identifier on every dependent loop |
| **Dependent sent before its subscriber** | Dependent rejected | Always send the subscriber INS loop first, then its dependents |
| **Termination without `349` on each HD** | Coverage stays active | Send member eligibility end and coverage end dates |
| **Full file sent with `BGN08` = `2`** | Members missing from the file are not reconciled | Set the action code for the file type the carrier expects |
| **Members omitted from a full file by mistake** | Carrier may terminate them | Count members before sending and compare with the last full file |
| **Wrong relationship code in `INS02`** | Dependent rejected or mis-tiered | Map HR relationship values to X12 codes explicitly |
| **Coverage level in `HD05` that does not match the dependents sent** | Premium and coverage mismatch | Derive the level from the dependents actually enrolled |
| **Retroactive change outside the carrier's window** | Change rejected or held for review | Check the carrier's retro policy, and send changes as soon as HR records them |
| **Ignoring the 999** | A rejected file looks like it was sent | Monitor every 999 and the carrier's load report |

## 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](/guides/edi/820-payment-order) monthly

For background on how X12 envelopes and acknowledgments work, see our [EDI document types reference](/edi-document-types) and the [997 functional acknowledgment guide](/guides/edi/997-functional-acknowledgment).

## 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](/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](/edi-to-json) and [EDI translator](/edi-translator) work on the same files.

## Frequently Asked Questions

<div className="not-prose">

### What is an 834 file?

An 834 file is the X12 Benefit Enrollment and Maintenance transaction. A plan sponsor, usually an employer, sends it to a health plan or administrator to add, change, terminate or verify members' coverage. Under HIPAA it follows the 005010X220 implementation guide, usually sent as 005010X220A1.

### What is the difference between a full 834 file and a change file?

A change file carries only members with an addition, change, termination or reinstatement since the last file, flagged with BGN08 = 2. A full file carries every enrolled member so the carrier can compare its records. Carriers often want change files frequently and a full file periodically.

### What does INS03 mean in an 834?

INS03 is the Maintenance Type Code. It says what is happening to the member: 021 addition, 001 change, 024 cancellation or termination, 025 reinstatement, or 030 audit or compare. INS04 gives the reason, such as 28 initial enrollment or 08 termination of employment.

### What is the HD segment in an 834?

HD (Health Coverage) describes one coverage the member is enrolled in. HD01 is the maintenance type for that coverage, HD03 the insurance line (HLT, DEN, VIS and others), HD04 the carrier's plan code and HD05 the coverage level, such as EMP, ESP or FAM. Coverage dates follow in DTP 348 and 349.

### How are dependents sent in an 834?

Each dependent gets its own INS loop after the subscriber's, with INS01 = N and a relationship code in INS02 such as 01 spouse or 19 child. The dependent repeats the subscriber's identifier in REF*0F so the carrier can link the family.

### How does the 834 relate to the 820?

The 834 tells the carrier who is covered. The 820 pays the premiums for that coverage and lists what the payment covers. Reconciling the two shows whether you are paying for exactly the members you enrolled.

### What acknowledgment comes back for an 834?

Under HIPAA 5010, receivers usually return a 999 Implementation Acknowledgment, which reports whether the file met X12 and implementation guide rules. Many carriers also send their own load or error report listing members they could not process.

### Is the 834 only for health insurance?

No. The 834 carries any benefit line the TR3 supports, including dental, vision, prescription drug and disability coverage, through the insurance line code in HD03. The carrier's guide lists which lines it accepts on its files.

</div>
