X12.
56 Interconnect Mailbag
Introduction
EDI Value Added Networks (VANs) use the X12.56
Interconnect Mailbag Control Structures (X12.56
Standard) to pass interchanges between each other.
Millions of X12.56 Mailbags are processed each
day. The fact that the X12.56 Standard is so widely
used among most North American VANs is a
testament to its usefulness. That it remains
essentially in its original form shows that it was well
thought out for its intended needs.
This is a practical, not technical, overview of the
X12.56 Standard. For the X12.56 technical
specification, please refer to The ASC X12 (X12.56)
Interconnect Mailbag Control Structures
documentation.
From the X12.56 Standard under Purpose and
Scope:
This standard defines the control segments used
to start and end a mailbag containing EDI data
to be exchanged between two interconnecting
entities. The mailbag includes zero or more
interconnect acknowledgment segments and zero
or more EDI data interchanges. The basic
interconnect mailbag consists of an interconnect
mailbag header segment (IH), the EDI data to be
transmitted from one interconnect entity to
another, and the interconnect mailbag trailer
segment (IT). In addition, an interconnect
mailbag acknowledgment segment (IA) is
provided to report complete receipt and safe
storage of an interconnect mailbag.
The purpose of this standard is to provide
control structures and an audit mechanism to
facilitate the exchange and receipt
acknowledgment of EDI data between
interconnecting entities. The original sender and
the ultimate receiver of the data contained in the
mailbag have no responsibility for creating,
managing, or removing the interconnect mailbag
segments. This standard is solely for use
between sites acting as interconnect entities.
The X12.56 Standard also recognizes its limitations:
Delivery of data from the original sender to the
ultimate receiver may require several
© 2010, Loren Data Corp.
All rights reserved
Control Structures
Overview
Version 1.0
by
Todd Gould
March 8, 2010
Loren Data Corp.
PO Box 600
Indian Rocks Beach
Florida 33785 USA
813-426-3355
www.LD.com
interconnect links. It is recognized that other
point-to-point data tracking mechanisms exist.
The interconnect mailbag control structures are
designed to stand alone in addressing a given
interconnect link. The structures are in no way
dependent on the types of data tracking
mechanisms that may be used in links prior to or
following a link that employs the interconnect
mailbag control structures.
How it works
Process
The process is an asynchronous send and
acknowledge model. VAN-A places one or more
Interchanges in an X12.56 Interconnect Envelope,
which includes a unique Control Number and a
count of the number of interchanges included. This
Mailbag is then sent to VAN-B over the
preestablished communications channel.
X12.56 Interconnect Mailbag Control Structures: Overview
1-3 v1.0
VAN-B then evaluates the Mailbag to confirm that
there is the indicated number of “valid” interchanges
in the mailbag. The interpretation of “valid” varies
from VAN to VAN, but generally means confirming
a valid Interchange envelope without regards to full
transaction syntax (this is left for the end-user
processing).
If the IH/IT envelope is intact and the count of
interchanges match, then VAN-B generates a
Mailbag back to VAN-A with an IA segment
positively acknowledging the receipt of the VAN-A
mailbag. If there is a problem with VAN-A’s
mailbag, VAN-B generates a Mailbag back to VAN-
A with an IA segment indicating the nature of the
problem.
Interchanges
While an X12 construct, the X12.56 Mailbags
regularly contain X12 ISA/IEA envelopes,
EDIFACT UNB/UNZ envelopes and any other
recognized traditional EDI standards (e.g.
Tradacoms).
The Segments
For those familiar with the ISA/IEA Interchange
envelope, the IH/IT Interconnect envelope is very
similar.
The X12.56 Standard consists of three simple
segments. The IH and IT are used to define the
X12.56 envelope itself and the IA is used to send
ACKs and NACKs.
Without getting into the technical details of the
Mailbag segments a brief description follows.
IH – Interconnect Header
The IH is the very first data in the mailbag structure.
Contained in the IH segment is the sending and
receiving VAN information, date/time stamp and a
control number.
IT – Interconnect Trailer
The IT is the very last data in the mailbag structure.
The IT segment contains a count of the number of
Interchanges, a count of the number of Interconnect
© 2010, Loren Data Corp.
All rights reserved
Acknowledgment Segments (IA) and a repetition of
the control number in the IH segment.
IA – Interconnect Acknowledgment
Zero or more IAs can be contained in a mailbag.
While they can be combined with Interchanges in
the same mailbag, most commonly they are sent in
their own mailbag. The IA contains a reference to
the control number of the mailbag being
acknowledged, a status code (e.g. Accept/Reject)
and if rejected one or more codes explaining the
reason for the rejection. (e.g. the most common W1
means rejected duplicate mailbag – based on control
number).
Real-World Implementation
Common Usage
The “Mailbag Number” corresponding to the
Control Number in the IH segment is the main way
VANs use to verify the receipt and processing of
Interchanges over Interconnects. When a company
on VAN-A sends an interchange to a trading partner
on VAN-B and the interchange does not arrive, one
of the first requests of VAN-A is, “What was the
Mailbag Number?”
The second significant benefit of the Mailbag is the
ability to prevent duplicate transmissions. VANs
routinely reject any Mailbag that has the same
Mailbag Number from the same VAN. The standard
rejection code of W1 makes it easy for the sending
VAN to understand this is a low level warning, and
not the case of interchanges that cannot be
processed.
Common Problems
By the definition of the standard, Mailbags are to be
fully rejected or accepted. In practice, some VANs
do partially process defective mailbags.
Some VANs do not send or properly process reject
codes. As mentioned, the most common code is W1
indicating a duplicate Mailbag. Several VANs do not
send the W1 code for duplicates but substitute
another. Other VANs do not process the receipt of a
W1 code properly and regularly follow up with a
X12.56 Interconnect Mailbag Control Structures: Overview
2-3 v1.0
support call of the “why didn’t mailbag ### Acknowledgement Turnaround Time
process.” Mailbag Acknowledgments are not returned in real-
Also, since not all VANs properly catch duplicate time, nor is there even a standardized, expected
mailbags, there is a lot of wasted NetOps interaction response time.
and wasted time with the “did you receive Mailbag
##” request. If all VANs properly blocked duplicates
and sent a W1 NACK, it would be a simple process
of automatically resending any missing mailbag. If it
had not been processed the first time, it would get an
ACK, if it was a duplicate a W1 NACK, and if no
response on the second try escalation would be
indicated.

Limitations of the Current Standard

Partial Transmission
The current standard says that partial transmissions
should not be NACKed as the sending system would
know that the communication line was dropped. As
that is not the case in today’s world, it is necessary
to NACK partial mailbags and this wording should
be removed from the standard.

NACK Codes
In general, the NACK codes (other than W1) often
do not communicate enough information for
recovery and require manual communication
between the two VANs to solve.

Multi-Hop
The X12.56 Standard only handles a single hop
between VANs. If the payload is forwarded to
another network it uses a new mailbag without any
reference to the original.

Non-Delivery
A positively acknowledged mailbag does not mean
that an interchange can be delivered, only that it is
intact. Interchanges sent to the wrong VAN or to
terminated mailboxes are not communicated via the
X12.56 protocol.

© 2010, Loren Data Corp. X12.56 Interconnect Mailbag Control Structures: Overview
All rights reserved 3-3 v1.0