Envelopes

Earlier, when we looked at inbound EDI, we set aside the ISA, GS, GE and IEA segments, noting that they are part of the EDI file's envelope. Now it's time to look at what they actually do.

The Nesting Structure

An EDI file is not just a flat list of segments. It has a nested structure:

ISA                              Interchange (outer envelope)
│
├─ GS                            Functional Group
│  ├─ ST                         Transaction Set (e.g. a 990)
│  │    B1, N9, ...              The actual document content
│  │  SE
│  ├─ ST                         Another transaction set
│  │    B1, N9, ...
│  │  SE
│  GE
│
├─ GS                            Another Functional Group
│  ├─ ST                         Transaction Set (e.g. a 214)
│  │    B2, L11, ...
│  │  SE
│  GE
│
IEA

The outermost layer is the interchange, bounded by ISA and IEA. Inside that is one or more functional groups, bounded by GS and GE. Inside each functional group is one or more transaction sets, bounded by ST and SE.

The transaction set contains the business data. Everything outside of it is envelope: metadata about who is sending what to whom, when, and how to track it. This is very similar to email: the envelope is like the email's sender/receiver/etc., and the transaction set is the email's body.

A single EDI file can contain multiple transaction sets within a functional group, and multiple functional groups within an interchange. In practice, many EDI files contain just one transaction set, but it is also perfectly normal to receive a file containing fifty invoices.

When Tediware processes an inbound EDI file, it separates each transaction set and delivers them to your system independently. This matters because different transaction sets require different processing logic - you handle an invoice differently than you handle a purchase order.

Let's look at the 990 example again, this time paying attention to the envelope segments.

ISA*00*          *00*          *ZZ*ACME           *ZZ*WALDO          *250303*1506*U*00401*000000052*0*P*:~
GS*GF*ACME*WALDO*20250303*1506*52*X*004010~
ST*990*00000052~
B1*ACME*339807*20250301*A~
N9*CN*ACM12345~
SE*4*00000052~
GE*1*52~
IEA*1*000000052~

{
  "heading": {
    "transaction_set_header_ST": {
      "transaction_set_identifier_code_01": "response_to_a_load_tender_990",
      "transaction_set_control_number_02": "00000052"
    },
    "beginning_segment_for_booking_or_pick_up_delivery_B1": {
      "standard_carrier_alpha_code_01": "ACME",
      "shipment_identification_number_02": "339807",
      "date_03": "20250301",
      "reservation_action_code_04": "reservation_accepted_A"
    },
    "reference_identification_N9": {
      "reference_identification_qualifier_01": "carriers_reference_number_pro_invoice_CN",
      "reference_identification_02": "ACM12345"
    },
    "transaction_set_trailer_SE": {
      "number_of_included_segments_01": 4,
      "transaction_set_control_number_02": "00000052"
    }
  }
}

ISA/IEA: The Interchange Envelope

The ISA segment is the outermost envelope. It identifies the sender and receiver, timestamps the interchange, assigns a control number, and specifies the X12 version.

Looking at the ISA in our example:

ISA-05/06:  The sender's qualifier and ID. "ZZ" means mutually defined (made up).
ISA-07/08:  The receiver's qualifier and ID.
ISA-09/10:  The date and time the interchange was created.
ISA-12:     The X12 release - "00401" in this case.
ISA-13:     The interchange control number, "000000052".
            This number must be unique for each interchange sent between this sender and receiver.
ISA-15:     The usage indicator. "P" means production; "T" means test.

The IEA segment closes the interchange. It contains two elements: the number of functional groups included (1), and the interchange control number again (000000052), which must match ISA-13.

Note that in practice, many trading partners do not rely on the usage indicator and instead set up separate test connections or environments. But you should be aware of it: if a partner does use it, sending "T" in production (or vice versa) will cause problems.

GS/GE: The Functional Group Envelope

Inside the interchange, the GS segment opens a functional group. A functional group contains one or more transaction sets of the same type.

In our example:

GS-01:    The functional identifier code, "GF", which tells the receiver that this
          group contains 990 transaction sets.
GS-02/03: The sender and receiver codes, again identifying Acme and Waldo.
GS-04/05: The date and time.
GS-06:    The group control number, "52". Like the interchange control number, this
          must be unique and is echoed in the GE segment.
GS-08:    The X12 version, "004010".

The GE segment closes the group with a count of transaction sets (1) and the group control number (52).

Control Numbers and Acknowledgments

You may have noticed that control numbers appear at every level: the interchange has one (ISA-13), the functional group has one (GS-06), and the transaction set has one (ST-02). These numbers serve two purposes.

First, they allow the receiver to detect missing or duplicate transmissions. If Acme sends interchanges numbered 1050, 1051, and 1053, Waldo Mart knows that 1052 is missing.

Second, they are used in acknowledgments. When a trading partner receives an EDI file, they usually send back a 997 Functional Acknowledgment (or a 999) that references these control numbers to confirm receipt and report any errors. This is how trading partners know their documents were received and processed correctly.

The Good News

This is a lot of bookkeeping, but it's mechanical bookkeeping. The envelope doesn't change based on business logic. It's the same structure whether Acme is accepting a load tender or sending a shipment status update.

Platforms like Tediware handle envelope generation and validation automatically. When processing inbound EDI, Tediware processes the envelope and gives you the transaction set. When generating outbound EDI, you provide the transaction set content and Tediware wraps it in a valid envelope. The control numbers, timestamps, and identifiers are managed for you.

Envelopes do have one more practical use worth mentioning. If you connect to a Value Added Network (VAN), multiple trading partners may share a single connection. When a file arrives, Tediware inspects the ISA header to determine which partner sent it by matching the sender and receiver identifiers against each partner's envelope configuration. This allows Tediware to automatically route each file to the correct partner's processing flow.