EDI Paisan
EDI Paisan Your Friend in EDI
← Back to Blog

How to Split an 837 File by Payer

March 30, 2026 · EDI Paisan Team
837 healthcare EDI medical billing HIPAA tutorial file splitting

You’ve got one 837 file with claims for Blue Cross, Aetna, UnitedHealth, and Cigna all mixed together. The clearinghouse wants them separated. Here’s how to do it.

Batch 837 files are efficient for generating claims — one file, one submission, done. But downstream, that convenience can create problems. Some clearinghouses require payer-specific files. Payer portals often only accept submissions for their own claims. And when something goes wrong, a mixed-payer file makes troubleshooting significantly harder.

Splitting an 837 by payer sounds simple in theory. In practice, it requires understanding the file’s structure at a level most billing software doesn’t expose. This guide walks through exactly how to do it.

Why You’d Need to Split an 837 File

There are several real-world scenarios where splitting becomes necessary:

  • Direct payer submission — Some payers (particularly Medicaid programs and large regional carriers) require direct file submission rather than clearinghouse routing. They only want their claims.
  • Clearinghouse routing rules — Some clearinghouses impose payer-specific file limits, or separate batches by payer as part of their own workflow.
  • Troubleshooting rejections — If 200 claims are rejected and they span 10 payers, isolating the payer-specific issues is much easier with separate files.
  • Reporting and reconciliation — Tracking claim volume and payments per payer is cleaner when the source files are already separated.
  • ERA matching — When 835 remittances come back payer-by-payer, having your original 837s split the same way makes reconciliation straightforward.

Where Payer Information Lives in an 837

Before you can split, you need to know where payer identity is encoded in the file. There are two places to look.

Option 1: The ISA Interchange Receiver (ISA08)

In an 837 routed through a clearinghouse, ISA08 is the clearinghouse’s receiver ID — typically the same across all claims. The payer differentiation happens inside.

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *260330*0900*^*00501*000000001*0*P*:~

ISA08 here (RECEIVER) is the clearinghouse. Not the payer. This is the most common setup.

However, in direct payer submissions, ISA08 is the payer’s interchange ID. If you’re building separate files for direct submission, ISA08 needs to match each payer individually.

Option 2: NM1*40 — The Receiver Loop

Inside the ST transaction, the NM1*40 segment identifies the intended receiver of the claims — the payer.

NM1*40*2*BLUE CROSS BLUE SHIELD*****46*00990~
  • NM1*40 — Loop 1000B: the Receiver Name
  • NM1*4009 — Payer’s NPI or electronic identifier
  • NM1*4046 — EDI ID (the routing number used by clearinghouses)

This is the primary identifier for routing. Even when all claims are wrapped in a single ISA, each functional group (GS/GE) or transaction set (ST/SE) may carry a different NM1*40 pointing to a different payer.

Option 3: NM1*PR — Payer at the Claim Level

Deep in the hierarchical loops, NM1*PR identifies the payer at the subscriber/claim level:

NM1*PR*2*AETNA*****PI*60054~
  • PR qualifier = Payer
  • PI = Payer ID (60054 is Aetna’s standard EDI payer ID)

This is the most granular level of payer identification. In a mixed-payer file, different claims will have different NM1*PR segments. The payer ID here is the authoritative reference for splitting.

Common Payer IDs You’ll See

PayerCommon EDI Payer ID(s)
Blue Cross Blue Shield (varies by plan)00990, BCBSMA, 04672, etc.
Aetna60054
UnitedHealthcare87726, UHC
Cigna62308
Humana61101
Medicare (varies by MAC)00883, 00902, etc.
Medicaid (state-specific)Varies widely by state

Payer IDs are not universally standardized — the same payer may have different IDs across clearinghouses. Always verify with your clearinghouse’s payer list.

The Structure You’re Splitting Along

An 837 file is a nested hierarchy. When splitting by payer, you need to understand exactly which layers to cut at and which to rebuild.

ISA (Interchange Start)
  GS (Functional Group Start)
    ST (Transaction Set Start)
      BHT
      NM1*41 — Submitter
      NM1*40 — Receiver (← PAYER ROUTING)
      HL*1 — Billing Provider
        HL*2 — Subscriber
          SBR
          NM1*IL — Insured
          NM1*PR — Payer (← PAYER ID)
          CLM — Claim
            LX / SV1 — Service Lines
    SE (Transaction Set End)
  GE (Functional Group End)
IEA (Interchange End)

A correct split preserves the full envelope structure for each output file. You don’t just extract CLM blocks — you need valid ISA/IEA, GS/GE, and ST/SE wrappers around each payer’s claims, with correct control numbers and segment counts.

The Manual Approach

Here’s what splitting by hand actually looks like.

Step 1: Identify all payers in the file

Scan the file for all unique NM1*PR values (payer ID in element position 9). For a file with 500 claims across 8 payers, you might find payer IDs like: 60054, 87726, 62308, 00990, 61101, and three state Medicaid IDs.

Step 2: Group the claim hierarchies

For each claim (CLM segment), walk up the HL hierarchy to find its NM1*PR. Group CLMs by payer. This is trickier than it sounds — the HL structure is relational, not flat. You need to track HL parent references to know which subscriber belongs to which billing provider loop.

Step 3: Rebuild the envelope for each payer

For each payer group, reconstruct a valid 837 file:

  1. Start with a fresh ISA segment (new control number)
  2. Add GS with appropriate functional group info
  3. Start ST with a new transaction set control number
  4. Include BHT, NM1*41 (submitter), NM1*40 (payer receiver)
  5. Re-sequence HL numbers — they must be sequential starting from 1 in each new file
  6. Include all relevant CLM loops with their service lines, dates, and references
  7. Close with SE (correct segment count), GE, IEA

Step 4: Validate

After splitting, each output file must be independently valid:

  • ISA13 must match IEA02
  • GS06 must match GE02
  • ST02 must match SE02
  • HL numbers must be sequential with correct parent references
  • Segment counts in SE01 must be accurate

One missed segment or off-by-one HL reference and the whole file rejects.

What Can Go Wrong

  • HL renumbering errors — The most common manual mistake. If HL*3 referenced HL*2 as its parent but you’ve renumbered and that parent is now HL*1, the hierarchy is broken.
  • Segment count drift — SE01 must exactly equal the number of segments between ST and SE. Miss one modifier or reference segment and you’ll get a structural rejection.
  • Split subscriber loops — A subscriber may have claims for multiple payers (coordination of benefits). Splitting naively can result in incomplete subscriber information.
  • Control number collisions — If you generate multiple files, control numbers across them must be unique.

For a small file (50 claims, 2 payers), manual splitting is tedious but manageable. For a production batch of 2,000 claims across 15 payers, it’s a full engineering project.

A Concrete Example

Let’s say you have an 837 with two claims — one for Blue Cross, one for Aetna:

Original file (simplified):

ISA*00*          *00*          *ZZ*MYBILLING      *ZZ*CLEARHOUSE     *260330*0900*^*00501*000001001*0*P*:~
GS*HC*MYBILLING*CLEARHOUSE*20260330*0900*1*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH001*20260330*0900*CH~
NM1*41*2*MY BILLING SERVICE*****46*123456789~
NM1*40*2*ROUTING CLEARHOUSE*****46*CLRHS01~
HL*1**20*1~
NM1*85*2*SMITH FAMILY MEDICINE*****XX*1234567890~
  HL*2*1*22*0~
  SBR*P*18*******CI~
  NM1*IL*1*JOHNSON*ROBERT****MI*ABC123456~
  NM1*PR*2*BLUE CROSS BLUE SHIELD*****PI*00990~
  CLM*PAT001*150***11:B:1*Y*A*Y*Y~
  LX*1~
  SV1*HC:99213*150*UN*1***1~
  HL*3*1*22*0~
  SBR*P*18*******CI~
  NM1*IL*1*WILLIAMS*SARAH****MI*XYZ789012~
  NM1*PR*2*AETNA*****PI*60054~
  CLM*PAT002*200***11:B:1*Y*A*Y*Y~
  LX*1~
  SV1*HC:99214*200*UN*1***1~
SE*22*0001~
GE*1*1~
IEA*1*000001001~

After splitting — Blue Cross file:

ISA*00*          *00*          *ZZ*MYBILLING      *ZZ*CLEARHOUSE     *260330*0901*^*00501*000001002*0*P*:~
GS*HC*MYBILLING*CLEARHOUSE*20260330*0901*2*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH001-BCBS*20260330*0901*CH~
NM1*41*2*MY BILLING SERVICE*****46*123456789~
NM1*40*2*ROUTING CLEARHOUSE*****46*CLRHS01~
HL*1**20*1~
NM1*85*2*SMITH FAMILY MEDICINE*****XX*1234567890~
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*JOHNSON*ROBERT****MI*ABC123456~
NM1*PR*2*BLUE CROSS BLUE SHIELD*****PI*00990~
CLM*PAT001*150***11:B:1*Y*A*Y*Y~
LX*1~
SV1*HC:99213*150*UN*1***1~
SE*15*0001~
GE*1*2~
IEA*1*000001002~

After splitting — Aetna file:

ISA*00*          *00*          *ZZ*MYBILLING      *ZZ*CLEARHOUSE     *260330*0902*^*00501*000001003*0*P*:~
GS*HC*MYBILLING*CLEARHOUSE*20260330*0902*3*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH001-AETNA*20260330*0902*CH~
NM1*41*2*MY BILLING SERVICE*****46*123456789~
NM1*40*2*ROUTING CLEARHOUSE*****46*CLRHS01~
HL*1**20*1~
NM1*85*2*SMITH FAMILY MEDICINE*****XX*1234567890~
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*WILLIAMS*SARAH****MI*XYZ789012~
NM1*PR*2*AETNA*****PI*60054~
CLM*PAT002*200***11:B:1*Y*A*Y*Y~
LX*1~
SV1*HC:99214*200*UN*1***1~
SE*15*0001~
GE*1*3~
IEA*1*000001003~

Notice what changed in each output file:

  • New ISA control numbers (000001002, 000001003) — unique, no collision
  • Updated GS group numbers (2 and 3)
  • New BHT reference numbers (BATCH001-BCBS, BATCH001-AETNA)
  • HL numbers re-sequenced (HL*1, HL*2 in each)
  • SE segment count recalculated (15 in each, not 22)
  • IEA and GE updated to match

That’s the manual rebuild — and this was just two claims. Scale it to 1,000.

Splitting Smarter with EDI Paisan

This is exactly the kind of task that EDI Paisan Pro was built to automate.

Upload your 837 file, and EDI Paisan automatically identifies every payer in the batch by NM1*PR. From there, the split operation:

  1. Groups all claims by payer ID
  2. Reconstructs valid envelopes — ISA, GS, ST — for each output file
  3. Renumbers HL segments sequentially within each file
  4. Recalculates segment counts for accurate SE01 values
  5. Assigns new control numbers to avoid collisions
  6. Validates each output file before download — structure, control number matching, segment counts

The result: one ZIP file containing a properly structured 837 for each payer in your original batch. Each file is submission-ready.

No manual HL renumbering. No segment count math. No risk of a structural rejection because you miscounted a segment.

File splitting is available in EDI Paisan Pro. The free tier lets you view, parse, and validate 837 files — Pro adds batch operations including split by payer, split by billing provider, and split by date of service.

Learn more at edipaisan.com →

Segment Reference for Payer Splitting

SegmentLocationRole in Splitting
ISA/IEAOutermost wrapperMust be rebuilt per output file with new control numbers
GS/GEFunctional groupMust be rebuilt; GS06/GE02 must match
ST/SETransaction setMust be rebuilt; ST02/SE02 must match; SE01 = segment count
NM1*40Loop 1000BRouting receiver — update if doing direct payer submission
NM1*PRSubscriber loopPrimary payer identifier — split key
HLThroughoutMust be re-sequenced 1, 2, 3… in each output file
BHTAfter STUpdate reference number per output file

Key Takeaways

  • NM1*PR is the primary field for identifying the payer at the claim level — that’s your split key.
  • Splitting isn’t just extracting claims — you must rebuild valid ISA/GS/ST envelopes with correct control numbers.
  • HL renumbering is the most error-prone part of manual splits — every HL reference must be updated consistently.
  • SE01 (segment count) must be recalculated exactly for each output file.
  • For production volumes, manual splitting isn’t realistic — the error rate gets too high.

If you’re working with mixed-payer 837 files regularly, EDI Paisan Pro handles the split automatically and validates each output before you download. No script-writing, no counting segments by hand.

Try EDI Paisan free at edipaisan.com →

EDI Paisan is built by healthcare IT engineers who got tired of explaining EDI files in Notepad. We build modern tools for the people who keep healthcare running.