Explain the difference between interchange sender/receiver IDs and application submitter/receiver codes.

From our workflow: In an 837P test file, ISA06, ISA08, GS02, and GS03 is checked in context with the surrounding loop, control numbers, and claim totals. A segment that looks correct by itself can still conflict with the rest of the transaction.

For ISA06, ISA08, GS02, and GS03, the 837P must identify each party and service through loops, segments, qualifiers, and control numbers. The receiver cannot rely on the visual layout of a paper form.

Core 837P workflow: understand the file’s purpose, review the envelope and transaction structure, validate before transmission, and read the claim acknowledgment.

Start with what the data is meant to do

Our 837P review for ISA06, ISA08, GS02, and GS03 begins with the business purpose of the data. We then trace the source field into the loop or segment where the receiver expects it.

Keep the source for ISA06, ISA08, GS02, and GS03—such as eligibility, enrollment, authorization, charge data, or the companion guide—alongside the exported value. That makes a rejection traceable without hand-editing the X12 file.

Where this sits in the 837P

Explain the difference between interchange sender/receiver IDs and application submitter/receiver codes. The information must remain consistent with related loops and segments. A change made late in the workflow—such as changing the subscriber relationship, diagnosis order, rendering provider, or service line—can require several connected elements to be rebuilt rather than one text value being replaced.

Practical design rule: Validate relationships, not only individual fields. A valid NPI can still be wrong for the role; a valid date can still be wrong for the qualifier; a valid total can still fail when it does not equal the service lines.

Example from a test workflow

A clearinghouse may assign one value for ISA06 and a different submitter code for GS02; the software should allow both instead of forcing them to be identical.

For ISA06, ISA08, GS02, and GS03, our audit trail includes the internal claim ID, destination, file name, control numbers, creation time, claim count, total charges, and every response received.

Separate interchange IDs from application IDs

In practice, these values may look similar but are not safe to assume. We store each value separately and allow a receiver profile to define when two fields intentionally share the same ID.

ISA06 = SENDER_INTERCHANGE_ID
ISA08 = RECEIVER_INTERCHANGE_ID
GS02  = APPLICATION_SENDER_CODE
GS03  = APPLICATION_RECEIVER_CODE

The ISA06, ISA08, GS02, and GS03 example below uses fictional values. A production file still has to follow the applicable implementation guide and the receiver’s companion guide.

Our release check

  • Use the IDs issued for the exact trading-partner relationship.
  • Pad ISA IDs to the required fixed width.
  • Do not substitute an NPI unless the receiver explicitly assigned it as the submitter ID.

What a rejection often points to

  • Copying the payer ID into every field
  • Ignoring fixed-width ISA formatting
  • Using a display name instead of an assigned code

If a receiver rejects ISA06, ISA08, GS02, and GS03, correct the source record, mapping, or generator that produced it. Editing the exported file may fix one transmission while leaving the defect in the software.

Controls that catch subtle errors

  • Use trading-partner enrollment values
  • Preserve required padding
  • Separate ISA and GS settings
  • Test with the actual receiver

A useful validation message for ISA06, ISA08, GS02, and GS03 identifies the claim or service line, shows the value involved, and explains the relationship that failed. “Invalid file” is not enough for a practical correction.

Apply this in software: Review the electronic 837P filing software for a workflow that keeps claim data, control numbers, exports, and corrections traceable. The payer companion guide and enrollment record still control the final submission.

Continue with these guides

Primary references

Written and reviewed by

1500Software Development Team

Covers the software, printing, validation, export, and troubleshooting steps described on this page.

1500Software Claims Review Team

Reviews field placement, provider roles, source records, and practical correction steps.

Reviewed July 26, 2026. Always follow the receiving payer’s current instructions and companion guide.