The EDI ISA ID, Explained: Qualifiers, Envelopes, and What to Send When a Retailer Asks

A retailer's EDI onboarding packet lands in your inbox, and somewhere on the form is a field like "ISA ID," "ISA Qualifier," or — after a trip through someone's memory — "ASI number." Nobody explains it, but the form won't move without it. Here's what it actually is, in plain terms.

The envelope on every X12 transmission

Every X12 EDI file starts with an ISA segment — the Interchange Control Header. Think of it as the outside of a mailing envelope: before a network or a retailer's system looks at a single 850 purchase order or 856 ship notice inside, it reads the envelope to learn two things:

• Who sent this — the sender qualifier and sender ID (elements ISA05 and ISA06)
• Who it's for — the receiver qualifier and receiver ID (elements ISA07 and ISA08)

The ID itself is up to 15 characters. The qualifier is a two-character code that says what kind of identifier follows — the same way "phone:" or "email:" in a contact card tells you how to read what comes next.

The qualifiers you'll actually see

ZZ is the workhorse of small and mid-size trading relationships: the two parties simply agree on a string. Large retailers often prefer DUNS-based qualifiers, and many assign the exact ID a supplier or store must use — their routing tables are built around it.

ISA vs. GS: two layers of addressing

Inside the interchange envelope, documents are grouped by type under GS segments (the Functional Group Header), which carry their own sender and receiver codes. The distinction rarely matters day to day — most partners use the same identity at both levels — but it explains why an onboarding form sometimes asks for "ISA and GS IDs." If your partner only asks for one, the ISA pair is the one they mean.

Why a retailer asks for your provider's information

When you use an EDI provider, retailers commonly send an EDI provider authorization form (often via DocuSign) before testing begins. It authorizes the provider to trade on your behalf and typically asks for:

• The provider's legal name and DBA
• A contact name, phone, and email at the provider
• The ISA qualifier and ID your account will trade under
• Sometimes the connection method — AS2 endpoint details, VAN mailbox, or SFTP

The ISA identity on that form is yours, not the provider's: it identifies your company inside the interchange, even though the provider operates the connection. Your provider's job is to coordinate with the retailer's EDI team, agree the qualifier and ID (or accept the one the retailer assigns), configure the connection, and run the 997 acknowledgment loop that proves envelopes are flowing both ways.

What this looks like on EDISQ

EDISQ stores your ISA identity per trading partner — the qualifier and ID each partner knows you by live on that partner's configuration, so a partner that assigns you an ID and a partner that accepts your DUNS can coexist without conflict. Routing, AS2 connectivity, envelope generation, and 997 reconciliation all key off those stored identities automatically; you never hand-type an ISA segment. During onboarding we coordinate directly with your trading partner's EDI team to establish the identity and certify the connection — the authorization form's provider fields point at us, the ISA identity points at you, and the partner directory shows the document sets each partner trades.

If a retailer's form is sitting in front of you right now asking for provider information and an ISA ID you don't have yet, that's not a blocker — it's the normal starting point. Send the provider details, and let the provider and the retailer's EDI team settle the envelope identities on a setup call. That's the entire mystery of the ISA ID: it's the return address on the envelope, and someone else licks the stamps.

FAQ