834 file format for group life and disability: what billing needs

The 834 file format is the X12 standard for benefit enrollment: the file an employer, or its benefits system, sends a carrier to add, change, end or confirm each person's coverage. Its formal name is Benefit Enrollment and Maintenance, and the version in use is 005010X220. A file is a nest of segments: an envelope, a header naming the employer and the carrier, then a loop for each member with their identifiers, birth date and, inside it, a loop for each coverage with its effective and end dates. HIPAA makes the 834 the required standard for health plans; for group life and disability it is a choice, which is why a billing team cannot assume the fields it needs are there. Group Premium Reconciliation, Botminds' solution for group billing teams, reads every 834 or carrier-layout file in date order and rebuilds each employee's coverage month by month, so the bill can be checked against what enrollment actually said.

The examples come from fictional sample data in the solution: Corrigan Freight Lines, an employer whose benefits system sent six enrollment files by secure transfer between the 10 September bill cutoff and its October payment.

What is an 834 file?

An 834 file is an electronic enrollment file in the X12 Benefit Enrollment and Maintenance format. The federal rule defines the transaction it carries as "the transmission of subscriber enrollment information from the sponsor of the insurance coverage, benefits, or policy, to a health plan to establish or terminate insurance coverage." For health plans the adopted standard since 1 January 2012 is the ASC X12 technical report 005010X220.

CMS lists what the transaction is used for: new enrollments, changes in a member's enrollment, reinstatement, and disenrollment, and notes that it "can include a periodic full update of a health plan sponsor's health plan enrollees, or it can reflect a change to existing enrollment". Those two kinds of file, full and change, behave very differently in billing, as set out below.

Is the 834 required for life insurance?

No. HIPAA's transaction standards bind covered entities, and the covered entity on the insurance side is a health plan: one that "provides, or pays the cost of, medical care". Group life pays for neither, and disability income coverage is an excepted benefit listed in 45 CFR 146.145, outside the definition. CMS describes the 834 standard as one that applies to HIPAA-covered entities; an employer sending life or disability enrollment to a carrier is not bound to use it.

The X12 guide was nonetheless written for those lines. X12 says it addresses human resources benefit plans including "Rate-based coverage (life, short term disability and long term disability)" alongside medical, dental, vision and spending accounts. So a group life and disability carrier receives 834s from employers whose benefits systems produce them, and spreadsheets or carrier layouts from the rest. What each employer puts in the file is governed by the carrier's companion guide and the trading-partner agreement, not by federal rule.

What fields does billing need for life and disability?

Billing needs the fields that set premium, which for life and disability are mostly about pay. Health premium usually depends on a coverage tier, such as employee only or family; life and disability premium usually depends on an amount, either a multiple of salary or a percentage of it, times a rate that can vary by age. A federal survey from 2010 broke this down, and the pattern it found is the point.

That makes six fields essential for a life and disability bill, beyond the ones every 834 carries: the covered salary and its effective date, the plan class, the elected amount for each voluntary coverage, the amount approved so far where evidence of insurability is pending, the coverage effective and end dates, and the date of birth. The X12 guide has places for these; whether an employer fills them is up to its benefits system and the companion guide. A feed that sends only names, IDs and coverage codes cannot produce a correct life or disability bill.

What is the 834 file layout?

An 834 has an envelope and a header, then one loop per member and, inside each member, one loop per coverage, as the figure at the top of this page shows. The member loop opens with the INS segment, whose maintenance type code says what is happening to the person; the Wisconsin agency's guide accepts five codes there, 001, 021, 024, 025 and 030, and at the coverage level uses 030 for its monthly full-file comparison. The name loop carries the birth date in the DMG segment. The coverage loop opens with HD, which names the coverage line, and carries two dates billing lives by: the guide labels them "348 (Coverage Effective Date)" and "349 (Coverage Expiration Date)".

Two practical points follow from the layout. First, an employee's termination can appear in two places: as a member-level maintenance code and as a coverage end date, and they need not agree. Corrigan's file for Dale Pruitt said he was terminated on 18 September and his coverage ended on 30 September; billing must use the coverage date. Second, the birth date sits in the demographics, not the coverage, so a file that omits it, as one Corrigan file did for an election, can be rejected while payroll goes on deducting.

What is an 834 full file vs a change file?

A change file carries only what changed since the last file; a full file carries everyone currently enrolled, so the receiver can compare it against what it holds. The Wisconsin agency's guide runs both: a daily eligibility file of changes, and "the monthly Full File Compare (FFC)". Its header marks which is which, with the BGN segment's action code set to "2 (Change) or 4 (Verify)".

How often are 834 files sent?

As often as the employer and carrier agree; there is no federal frequency. Daily and monthly files are both in use; the Wisconsin agency runs a daily change file and a monthly full file. The 2010 federal guidance on rescissions acknowledged that some employers' HR departments exchange eligibility with their carrier by data feed only monthly, which is one reason a termination can be weeks old before the carrier sees it.

Frequency matters less to billing than order and completeness. Corrigan sent six files in the month after the cutoff: two additions and a rejected change on 16 September, a termination on 19 September, two additions and a termination on 23 September, four salary changes on 25 September, three terminations on 2 October, and a file on 9 October with no changes for October. Applied in date order they produce 14 changes, none of them on the October bill. Applied out of order, or with one missing, they produce a different and wrong bill.

Every enrollment file since the cutoff, in Group Premium Reconciliation

Why do 834 files cause billing errors?

Because they arrive on the employer's schedule and the bill is cut on the carrier's. Every file after the cutoff is, by definition, a set of differences the next payment will show. Three other causes come from the file itself. A rejected entry, such as an election missing a birth date, means the carrier holds no coverage while the employer's payroll goes on deducting; Grace Holloway's $30,000 voluntary life election was rejected on the 16 September file and she was deducted $19.20 a month. A salary change sent with its effective date but after the cutoff, like the four on Corrigan's 25 September file, changes life and disability premium from a month the bill has already priced. And a termination's coverage end date can differ from its termination date, so a billing rule that reads the wrong one credits the wrong month.

None of these is a fault in the 834 standard. They come from timing, from incomplete fields and from carriers applying files as if each were the whole truth. The way through is to keep every file, apply them in order, and rebuild coverage month by month rather than as of one date, which is also how the 820 payment detail should be checked against them.

How to test an employer's 834 feed

Test it against a bill you already trust, before it drives one you do not. Take the employer's last full file and the month of change files that followed it, apply them in date order to the enrollment you held at the previous cutoff, and compare the result with the bill you sent and the payment you received. Every person who differs is either a change the feed carried and billing missed, or a field the feed never carried at all; the first is a timing fix, the second is a conversation with the employer's benefits system before go-live. Corrigan's six files would have shown both kinds in one pass: the 14 changes after the cutoff, and the election rejected for a missing birth date that payroll kept deducting for.

Run the test on a renewal month if you can. Salary updates, class moves and voluntary elections cluster there, so a feed that survives a renewal month has met most of what the year will send it. The eight checks below are the ones to agree in writing with the employer, because each one, left open, becomes a monthly difference on the bill.

How Group Premium Reconciliation reads the 834

The solution's Enrollment history keeper loads every enrollment file, 834 or carrier layout, in date order and rebuilds each employee's coverage month by month: effective and termination dates, amounts, classes and rejected entries, with every change after the bill cutoff flagged. It never edits enrollment; a rejected entry goes to the enrollment specialist, with the payroll deduction behind it shown beside it. On Corrigan's October bill, the rebuilt history let the Bill matcher set bill, enrollment and payment side by side for 645 employees across four coverages and find the 18 that differed.

What the agents cannot do is invent a field the file did not carry. If an employer's feed has no salary, a salary change cannot be billed from it, and the difference stays unexplained until a person finds the cause. That is the argument for testing the feed before the first bill, and for treating the 834 as one source among three, beside the bill and the payment, as described in the group insurance billing analyst's month.

Questions people ask

What is an 834 companion guide?

A carrier's or agency's document saying how it uses the X12 834: which fields it requires, which codes it accepts and how files are exchanged. The Wisconsin agency's guide states that it "does not change the definition, data condition, or use of a data element or segment" in the national guide; it narrows the choices.

What does the INS03 maintenance type code mean?

It is the member's maintenance type: what the file is doing to that person's enrollment, with the codes defined in the X12 national guide. The Wisconsin agency's guide accepts 001, 021, 024, 025 and 030 there, and marks coverage in its monthly full-file compare with 030.

Who sends an 834 file?

The sponsor of the coverage, usually the employer or its benefits administration system, to the payer, the carrier. In the Wisconsin guide the sponsor is identified with the code P5 and the payer with IN, each by federal tax ID.

Can an 834 carry salary and coverage amounts?

Yes: X12 says its guide covers rate-based coverage, meaning life, short-term and long-term disability, whose premium depends on amounts. Where those values sit, and whether an employer sends them, is set by the national guide, which X12 licenses, and the carrier's companion guide.

Is the 834 the same as the 820?

No. The 834 says who is covered and for what; the 820 says what was paid and for whom. A carrier reconciling a group premium needs both, plus its own bill.