Reference·X12 820·N1
X12 820 Reference

How to Test X12 820 N1: A Field-by-Field Breakdown

Jul 28, 2026 · 5 min read

An 820 without a correctly coded N1 loop can still total the right dollar amount and still be useless, because nothing in the file says definitively who sent the money or who it's meant for. That distinction matters most in files that pass through an intermediary, where the entity actually cutting the check isn't the entity whose name appears anywhere else in the transaction.

Quick answer

N1 (Name) identifies a party in the payment transaction using an entity identifier code — most often PE for the payee (the health plan receiving premium funds) or RE for the remitter (whoever is sending payment, which may be an employer, a third-party administrator, or the group itself). Each N1 loop pairs that role with an organization name and, usually, an identification code such as a Tax ID or payer ID.

The elements that actually matter in practice

N101 →
Entity Identifier Code — the role this party plays in the payment — PE for payee, RE for remitter, and a smaller set of codes for other participants
N102 →
Name — the organization's name as it should appear for that role, whether that's the health plan, the employer group, or a TPA acting on the employer's behalf
N103
Identification Code Qualifier — tells you how to interpret N104 — common values point to a federal Tax ID, a payer-assigned ID, or another identifier scheme
N104
Identification Code — the actual identifier for the named party, used to match this N1 loop against a system of record instead of relying on name matching alone

Example

Synthetic example Generated by Synthibase
N1*PE*Meridian Health Plan*FI*471029384

A synthetic payee loop: N101=PE marks Meridian Health Plan as the payee, and N103/N104 carry a federal Tax ID (FI) identifying the plan.

Where this trips people up

Test files often hardcode a single N1 loop for the payee and skip the remitter loop entirely, which never exercises the case a payer's system actually needs to handle: an employer paying through a TPA, where the remitter name on the check doesn't match the group name anywhere else in the file. Teams also tend to leave N103/N104 blank in synthetic data because the segment technically parses without them, then discover in production that downstream matching logic depends entirely on that identification code and falls back to unreliable name matching whenever it's missing.

EDI 835 Remittance Advice: Complete Guide for Healthcare IT
How to Write EDI Test Cases That Actually Catch Go-Live Failures
Generate realistic payer and remitter identities in minutes
Synthibase produces synthetic X12 820 files with distinct payee and remitter N1 loops, complete identification codes, and TPA-style routing scenarios, no real employer or health plan data involved.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.