Audience: EDI developers, B2B integration teams, trading partner technical contacts

EDI transactions use multiple layers of reference numbers and identifiers — each serving a different purpose in routing, matching, and validating the exchange. Understanding which layer an identifier belongs to makes it much easier to diagnose errors when they occur.

These identifiers exist at the interchange and functional group level. They tell the EDI system who sent the file and who should receive it, and they are what Orderful uses to route an incoming transaction to the correct relationship.

ISA IDs appear in the ISA header — the outermost wrapper of any X12 file:

These are paired with qualifier codes in ISA05 and ISA07 that define the ID type (e.g., ZZ for mutually defined, 01 for DUNS).

GS IDs appear in the functional group header, one level inside the ISA:

GS IDs are often the same as ISA IDs but not always. Some trading partners use different identifiers at the GS level, particularly when routing between internal systems.

Common examples:

These identifiers operate at the transaction level and serve two related but distinct purposes.

Control numbers (ISA13, GS06, ST02) are sequential numbers assigned to the interchange, functional group, and transaction set respectively. They exist for EDI structural integrity — they uniquely identify each envelope and transaction in the exchange.

In practice, they don't drive business logic but Orderful surfaces them as filters so you can locate specific transactions.

Business numbers are the identifiers that link an EDI transaction to a specific business document — a purchase order, a shipment, an invoice. These are what your trading partner's system uses to match an inbound document to an existing record.

Common business numbers by transaction type:

Response transactions (856, 810, 214) must reference the business number from the originating transaction. An 856 must carry the PO number from the original 850. An 810 must reference the invoice against an existing order. If the business number doesn't match what's in the receiving system, the transaction will be rejected.

Business numbers are also available as filters in Orderful's transaction view, making them useful for tracing a document through its full lifecycle.

These identifiers appear inside the transaction body and serve specific business or validation purposes — identifying parties, items, carriers, locations, and other entities involved in the transaction.

Common examples:

Note: The exact segments and qualifiers required vary by transaction type and trading partner. Always refer to the trading partner's implementation guidelines for which identifiers they require and in which segments.

If the ISA sender or receiver ID doesn't match a configured relationship in Orderful, the transaction cannot be created. Orderful cannot route the file to any relationship, so no transaction record is generated. The error will reference the sender, receiver, partnership or relationship not being found.

Fix by verifying the ISA IDs in the file match the relationship configuration in Orderful exactly, including spacing and qualifier codes.

GS ID mismatches don't prevent Orderful from creating a transaction, but the receiving trading partner may reject the file if their system expects specific GS02/GS03 values. This often surfaces as a partner reaching out to report a rejected file rather than an automated error in Orderful. Fix by updating the GS ID configuration in the relationship or communication channel.

Control numbers don't generate errors in normal processing. Duplicate control numbers may generate a 997 warning from some partners, but Orderful does not reject transactions on this basis.

Control numbers are primarily useful as filters for locating specific transactions in Orderful's transaction view.

In response transactions, the business number must exactly match the original. If it doesn't match what the receiving system expects — due to a typo, format difference, or referencing a cancelled document — the transaction will be rejected.

Common causes are shortened PO numbers, missing leading zeros, or format changes the trading partner made without notice. Always copy business numbers directly from the originating transaction rather than re-entering them manually.

If a trading partner's configuration requires specific REF segments and they are absent from the transaction, you'll see a validation error identifying the missing qualifier codes. These segments typically come in qualifier + value pairs (e.g., REF*2I*[tracking number]) but some identifiers like PO number or SCAC code may be required in dedicated segments rather than generic REF segments.

The error message will identify which qualifier codes are expected. Add the missing segments through your EDI generation system or a rule in Orderful.

Using an incorrect vendor number, wrong SCAC code, or mismatched party identifier won't always generate an automated validation error — the file may be accepted by Orderful and delivered to the partner, who then rejects it or contacts you to correct it for future transactions.

Common examples are outdated vendor numbers assigned by the buyer, or SCAC codes that changed when a carrier was retendered.

Fix by getting the correct value from your trading partner and updating your EDI generation or rules.

When contacting [email protected] about reference number issues, include:

My business number is correct but the trading partner says it doesn't exist — what's wrong?

Check for format differences. Some partners require leading zeros, specific prefixes, or a fixed character count. Also confirm you're not referencing a test transaction in production or a cancelled document.

How do I find the original PO number to reference in my 856?

In Orderful, go to Transactions, filter by your trading partner, and locate the original 850 transaction. The PO number will be in the BEG02 field or a REF*PO segment.

Can I use transformation rules to fix reference number format issues?

Yes, in many cases. The Rules Editor supports reformatting reference numbers, adding prefixes, or mapping between identifier systems. Contact Orderful Support if you need help configuring complex transformations.

The error mentions qualifier codes I don't recognize — where can I look them up?

Qualifier codes are defined in the X12 standard. Common ones include PO (Purchase Order), BM (Bill of Lading), 2I (Tracking Number), and VN (Vendor Number). Your trading partner's implementation guidelines will specify which ones they require for each transaction type.

Why can't I find the transaction in Orderful after a routing failure?

ISA ID routing failures prevent transaction creation entirely. There is no transaction record — only an EDI job entry. Check the EDI job linked in the notification email for the error details.