EDI 820 Premium Payment Transactions Explained

If you work in healthcare billing or revenue cycle management, you’ve probably spent significant time with 837 claim files and 835 remittance transactions. But there’s another critical transaction that often flies under the radar: the EDI 820 Premium Payment Order/Remittance Advice.

The 820 is the X12 transaction set used to transmit premium payment information — most commonly between employers or plan sponsors and insurance carriers or TPAs (Third-Party Administrators). It tells the payer who is paying, how much is being paid, and for whom the coverage applies.

Understanding the 820 is essential for anyone managing group benefits, self-funded plan operations, or employer-sponsored health coverage. In this post, we’ll break down what the 820 does, how it’s structured, and what to watch for when implementing or troubleshooting these files.

What Is the EDI 820 Used For?

The EDI 820 — formally known as the Payment Order/Remittance Advice — serves two closely related purposes depending on context:

Premium Payment Transmission: An employer or plan sponsor sends an 820 to a carrier or TPA to accompany a premium payment. The 820 details which employees (subscribers) the payment covers, what coverage periods are included, and the exact amounts allocated per member.
Remittance Advice: In some implementations, the 820 serves as a remittance document similar to the 835 — it tells the recipient how to apply funds received. The difference is that the 820 is oriented around premium payments rather than claim payments.

The most common use case in healthcare is the premium payment scenario: an employer group transmits an 820 alongside an ACH wire or check, so the insurance carrier can reconcile exactly which member months are being paid.

Who Sends and Receives the EDI 820?

Understanding the trading partners involved is key to knowing whether an 820 is relevant to your workflow:

Sender	Receiver	Use Case
Employer / Plan Sponsor	Insurance Carrier	Group premium payment for enrolled employees
TPA	Carrier	Forwarding aggregated premium on behalf of employer groups
Benefits Administrator	Self-Funded Plan	Funding transfer with member-level detail
COBRA Administrator	Carrier	COBRA premium payments for qualified beneficiaries

If your organization is on either end of group benefit plan management, the 820 is likely part of your integration footprint — even if it’s been handled manually until now.

EDI 820 File Structure: The Key Loops and Segments

Like all X12 transactions, the 820 is wrapped in an ISA/GS envelope and uses a hierarchy of loops to organize payment and member-level data. Here’s the essential structure:

ISA/GS Envelope

Every EDI file starts with interchange and group control envelopes. For the 820, these look like any other X12 transaction:

ISA*00*          *00*          *ZZ*EMPLOYERID     *ZZ*CARRIERID      *261005*1700*^*00501*000001234*0*P*:~
GS*RA*EMPLOYERID*CARRIERID*20261005*1700*1234*X*005010X218~
ST*820*0001~

ST*820 — Transaction Set Header, identifies this as an 820
005010X218 — The implementation guide version (the most widely used version of the 820 for premium payments)

BPR — Beginning Segment for Payment Order/Remittance Advice

The BPR segment is the heart of the 820. It defines the payment amount, payment method, and effective date:

BPR*C*125000.00*C*ACH*CTX**01*021000021*DA*1234567890*1200212345**01*021000021*DA*9876543210*20261005~

Breaking this down:

Position	Value	Meaning
BPR01	C	Transaction Handling Code — C = Payment accompanied by remittance
BPR02	125000.00	Total payment amount
BPR03	C	Credit/Debit Flag — C = Credit
BPR04	ACH	Payment Method — ACH transfer
BPR16	20261005	Effective Entry Date

If payment is sent by check rather than ACH, you’ll see CHK in BPR04 and fewer banking data elements.

TRN — Trace Number

The TRN segment provides a reference number that ties the payment to this specific 820 transaction:

TRN*1*INV2026100501*1200212345~

TRN01: Trace Type Code — 1 = Current Transaction Trace Numbers
TRN02: Reference Number — your invoice or payment reference
TRN03: Originating Company ID (usually the employer’s EIN or TPA identifier)

This number is critical for reconciliation. The carrier uses it to match the 820 against the incoming wire or ACH transaction.

REF — Reference Identification

REF segments can appear at multiple levels in the 820 to provide additional cross-referencing data:

REF*38*GROUP12345~
REF*72*DIVISION-A~

38 = Master Policy Number (group contract number)
72 = Health Industry Number

Use these segments to identify the specific group contract being paid. Carriers often require the group number here to route the payment correctly within their system.

Loop 1000A — Payer (Remitter) Information

This loop identifies who is sending the payment:

N1*PR*ACME CORPORATION*EI*987654321~
N3*123 MAIN STREET~
N4*BOSTON*MA*02101~

N1*PR — Payer/Remitter identifier
EI — Employer’s Identification Number (EIN)
The N3/N4 segments provide the payer’s address

Loop 1000B — Payee (Receiver) Information

This loop identifies who receives the payment:

N1*PE*BLUE CROSS BLUE SHIELD*XV*12345~
N3*P.O. BOX 99999~
N4*CHICAGO*IL*60601~

N1*PE — Payee identifier
XV — Health Care Financing Administration National Plan ID

Loop 2000 — Individual Coverage Information

This is where the member-level detail lives. Each subscriber typically has their own 2000 loop:

ENT*1*IL*34*123456789~
NM1*IL*1*SMITH*JOHN*A***34*123456789~
REF*1L*EMP001~
DTM*303*20261001~
DTM*036*20261031~

Breaking this down:

ENT — Entity Detail, identifies the type of entity (IL = Insured or Subscriber)
NM1*IL — Individual name segment for the subscriber
- 34 = Social Security Number qualifier
REF*1L — Employee ID / Member ID within the employer’s system
DTM*303 — Coverage Effective Begin Date (Oct 1, 2026)
DTM*036 — Coverage Effective End Date (Oct 31, 2026)

Loop 2300 — Premium Payment Information

Under each subscriber, the 2300 loop captures the actual premium amounts:

RMR*ZZ*INV001*PI*850.00~
REF*18*MEDICALPLAN~
DTM*007*20261001*20261031~

RMR — Remittance Detail segment
- RMR01: Reference ID Qualifier (ZZ = Mutually Defined)
- RMR02: Reference ID (invoice line reference)
- RMR03: Payment Action Code — PI = Paid in Full
- RMR04: Amount Paid
REF*18 — Plan type or coverage code
DTM*007 — Coverage period start and end

If an employee has multiple coverage types (medical, dental, vision), you may see multiple 2300 loops per subscriber — one per benefit line.

SE — Transaction Set Trailer

SE*42*0001~
GE*1*1234~
IEA*1*000001234~

Standard X12 closing segments. The segment count in SE01 must exactly match the number of segments between ST and SE (inclusive).

Common EDI 820 Implementation Challenges

1. Segment Count Mismatches

The SE01 count is a frequent source of validation failures. If you add or remove segments during file generation and forget to update the trailer count, the entire transaction will reject. Always generate SE01 programmatically rather than hardcoding it.

2. Group Plan Identification Mismatches

Carriers are picky about how group plans are identified in REF and N1 segments. A group number formatted as GRP-12345 in your system but expected as 12345 at the carrier will cause routing failures — even if the dollar amounts are correct. Validate against the carrier’s companion guide before your first production transmission.

3. Missing DTM (Date) Segments

Coverage period dates in the 2300 loop are mandatory for proper application of premiums. A missing or malformed DTM causes the carrier to reject the member line — sometimes silently, resulting in lapses in coverage that don’t surface until a claim is denied weeks later.

4. Handling Partial Payments

When an employer makes a partial payment, the 820 must accurately reflect what’s being paid. Using PP (Partial Payment) in RMR03 instead of PI signals to the carrier that this isn’t a full settlement — and typically triggers a separate reconciliation process. Many implementations default to PI incorrectly, creating accounting headaches.

5. COBRA Members

COBRA participants often have different group structures than active employees. Some carriers use a separate group number for COBRA coverage; others use a plan-level flag. Check your carrier’s companion guide for how COBRA subscribers should be identified in the NM1 and REF segments within Loop 2000.

EDI 820 vs. EDI 834: What’s the Difference?

These two transactions are often confused because they both involve employee benefit information. Here’s the key distinction:

	EDI 820	EDI 834
Purpose	Premium payment/remittance	Benefit enrollment/maintenance
Primary Data	Dollar amounts, payment periods	Member demographics, plan elections
Trigger	Payment cycle (monthly)	Enrollment event (hire, life event, open enrollment)
Direction	Employer → Carrier (with payment)	Employer → Carrier (enrollment data)

In a mature benefits integration, you’ll typically see both: the 834 keeps enrollment current, and the 820 handles the money movement that follows.

Validating an 820 File

Before sending an 820 to a payer, you should validate:

ISA/GS/ST structure — Proper delimiters, control numbers, version identifier (005010X218)
BPR amount matches the sum of all RMR04 premium amounts across all subscribers
DTM coverage dates are present and formatted as YYYYMMDD or YYYYMMDDYYYYMMDD (period range)
Segment count in SE01 is accurate
TRN reference number is unique per transmission
Group identifiers in REF segments match the carrier’s expected format

Validating against the 005010X218 implementation guide will catch structural issues before submission.

Key Takeaways

The EDI 820 is the transactional backbone of premium payment in group benefits — it’s what makes it possible to automate the flow of dollars from employers to carriers with member-level precision. Getting it right means:

Fewer reconciliation failures and manual follow-ups
Reduced risk of coverage lapses caused by unapplied payments
A cleaner audit trail linking payments to specific member months

Whether you’re implementing a new benefits integration, debugging a recurring reconciliation issue, or simply trying to understand what your TPA is sending on your behalf, knowing the 820’s structure gives you a significant operational advantage.

Ready to work with EDI files in your browser? Try EDI Paisan free — no install required.