ISO/IEC 15434:2025

Information technology - Automatic identification and data capture techniques - Syntax for high-capacity ADC media

This document specifies a transfer structure, syntax, coding of messages and data formats when using high-capacity automatic data capture (ADC) media.

Technologies de l'information — Techniques automatiques d'identification et de capture des données — Syntaxe pour supports de CAD à haute capacité

General Information

• Status: Published
• Publication Date: 08-Jan-2025
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Current Stage: 6060 - International Standard published
• Start Date: 09-Jan-2025
• Due Date: 12-Apr-2025
• Completion Date: 09-Jan-2025

Relations

• Revises: ISO/IEC 15434:2019 - Information technology - Automatic identification and data capture techniques - Syntax for high-capacity ADC media
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 15434:2025 - "Information technology - Automatic identification and data capture techniques - Syntax for high-capacity ADC media" specifies the transfer structure, syntax, coding of messages and data formats for high-capacity ADC media. Published as the fifth edition in 2025, this International Standard defines a two-level envelope model (message envelope and format envelope), a set of format indicators (two-digit codes) and a standardized method for encoding multiple fields of data into media such as 2D symbols, RFID transponders, contact memories and smart cards.

Key 2025 updates include the assignment of format 14 for JSON-structured data and format 15 for ISO/IEC 20248 verifiable data constructs, plus the addition of Annex B with practical examples.

Key technical topics and requirements

• Message structure: A message envelope (header/trailer) encapsulates one or more format envelopes that carry discrete data formats.
• Format indicators: Two-digit codes identify the data structure in use (e.g., transportation, EDI, GS1 Application Identifiers, JSON, binary).
• Supported data formats: Document lists formats including transport (01), complete EDI (02), ASC X12 (03), UN/EDIFACT (04), GS1 AIs (05), ASC MH10 identifiers (06), free text (07), CII (08), binary (09), text element identifiers (12), blocked data (13), JSON (14), ISO/IEC 20248 constructs (15), and reserved ranges for future use.
• Control characters: Non‑printable separators are specified (record separator RS, group separator GS, field separator FS, sub-element separator US and end-of-transmission EoT) with defined ISO/IEC 646 encodings to reliably delimit and parse fields.
• Documentation and examples: Annex A includes ISO/IEC 646 subsets; Annex B provides encoding examples for varied ADC media.

Practical applications and users

ISO/IEC 15434 is intended for implementers and integrators who need robust, interoperable encoding/decoding of multi-field data on high-capacity ADC media, including:

• RFID solution providers and hardware manufacturers
• Supply chain, logistics and transportation systems that exchange structured shipping and tracking data
• Software developers building scanner/reader middleware and host-system parsers
• Standards bodies and industry consortia defining industry-specific data applications (e.g., GS1 implementations)
• Manufacturing and inventory management systems requiring consistent data mapping across media types

Benefits include reduced integration effort, one-to-many media interoperability, and adaptive parsing via format indicators.

Related standards

Normative and related references include ISO/IEC 646, ISO/IEC 19762, ISO/IEC 21778 (JSON), ISO/IEC 20248, GS1 General Specifications, ANS MH10.8.2, and EDI standards such as ASC X12 and UN/EDIFACT.

Standards Content (Sample)

International
Standard
ISO/IEC 15434
Fifth edition
Information technology —
2025-01
Automatic identification and data
capture techniques — Syntax for
high-capacity ADC media
Technologies de l'information — Techniques automatiques
d'identification et de capture des données — Syntaxe pour
supports de CAD à haute capacité
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Documentation notation conventions . 1
5 Message format . 2
5.1 General .2
5.2 Message envelope .3
5.2.1 General .3
5.2.2 Message header .4
5.2.3 Message trailer .4
5.3 Format envelope .4
5.3.1 General .4
5.3.2 Format header.4
5.3.3 Format trailer .9
5.4 Data format .9
5.4.1 General .9
5.4.2 Format “00” — Reserved .9
5.4.3 Format “01” — Transportation .9
5.4.4 Format “02” — Complete EDI message / transaction . 12
5.4.5 Format “03” — Structured data using ASC X12 segments . 12
5.4.6 Format “04” — Structured data using UN/EDIFACT segments . 12
5.4.7 Format “05” — Data using GS1 application identifiers . 12
5.4.8 Format “06” — Data using ASC MH 10 data identifiers . 13
5.4.9 Format “07” — Free form text format . 13
5.4.10 Format “08” — Structured data using CII syntax rules . 13
5.4.11 Format “09” — Binary data . 13
5.4.12 Formats “10” to “11” — Reserved . 13
5.4.13 Format “12” — Using text element identifiers .14
5.4.14 Format “13” — Blocked .14
5.4.15 Format “14” — Data using JSON syntax .14
5.4.16 Format “15” — ISO/IEC 20248 verifiable data construct .14
5.4.17 Formats “16” to “99” — Reserved .14
Annex A (normative) Subset of ISO/IEC 646 (table of hexadecimal and decimal values) .15
Annex B (informative) Examples of ADC media encoded with ISO/IEC 15434 syntax . 17
Bibliography .31

© ISO/IEC 2025 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
This fifth edition cancels and replaces the fourth edition (ISO/IEC 15434:2019), which has been technically
revised.
The main changes are as follows:
— format “14” has been assigned to data structured with JSON syntax (see 5.3.2.16 and 5.4.15);
— format “15” has been assigned to data containing an ISO/IEC 20248 verifiable data construct (see 5.3.2.17
and 5.4.16);
— Annex B has been added to provide examples of syntax used to encode data into high-capacity ADC media.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
iv
Introduction
This document defines the manner in which data is transferred to high-capacity automatic data capture
(ADC) media from a supplier’s information system and the manner in which data is transferred to the
recipient’s information system. It does not define the internal data storage format for specific high-capacity
ADC media. This document does not specify the application of data structures provided by a specific data
syntax format. The application of the data structure may be specified by industry conventions.
Users of automatic identification and data capture (AIDC) techniques benefit by being able to receive data
in a standard form and by being able to provide data in a standard form. Low capacity ADC media, such as
linear bar code symbologies and optical character recognition, typically encode a single field of data. Most
applications of these technologies involve the encoding of a single field of data by the supplier of the medium
and the subsequent decoding of the data field by the recipient. Encoding single fields of data permits the
supplier to perform the encoding from a single field within the supplier’s information system. Decoding
single fields of data permits the recipient to input this data into a single field in the recipient’s information
system, in lieu of key entry.
High-capacity ADC media, such as two-dimensional symbols, RFID transponders, contact memories and
smart cards, encode multiple fields of data. These multiple fields are usually parsed by the recipient’s
information system and then mapped to specific fields of data in the recipient’s information system. This
document defines the syntax for high-capacity ADC media, so as to enable ADC users to utilize a single
mapping utility, regardless of which high-capacity ADC medium is employed.
The benefits of using high-capacity ADC media come with challenges. The ability to convey both data and
meaning (e.g. assuming an encoded serial number is "12345"; "12345" is the data and the understanding
"12345" is a serial number is the meaning) within a single technology has been executed differently by many
industries in a variety of ways. The widespread use of these different data and meaning formats has led to
an additional challenge of identifying which format is being used. To address this challenge, this document
assigns many of the data and meaning formats a unique two-digit number called a format indicator which
identifies the data structure for the encoded data. These format indicators enable a user to employ one or
more formats within a single high-capacity ADC media and accurately decode the data stream.
This document defines a syntax to indicate the message encoded in the high-capacity ADC media conforms to
this document. Its defined syntax also indicates which data format or formats are being used to provide data
and meaning. The purpose of the syntax is to provide a mechanism for an automated information system
consuming data through high-capacity ADC media to adaptively interpret and parse the data meaningfully.

© ISO/IEC 2025 – All rights reserved
v
International Standard ISO/IEC 15434:2025(en)
Information technology — Automatic identification and data
capture techniques — Syntax for high-capacity ADC media
1 Scope
This document specifies a transfer structure, syntax, coding of messages and data formats when using high-
capacity automatic data capture (ADC) media.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary
ISO/IEC 21778, Information technology — The JSON data interchange syntax
ISO/IEC 20248, Information technology — Automatic identification and data capture techniques — Digital
signature data structure schema
ANS MH10.8.2, ASC MH 10 Data Identifiers and Application Identifiers
ANS X12, Electronic Data Interchange
CII Syntax Rule (Vers 3.00), CII Syntax Rule Specifications (3.00) (Electronic Data Interchange — Japan)
GS1 General Specifications Standard
Airlines for America, ATA Common Support Data Dictionary (CSDD)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Documentation notation conventions
This document uses the following typographical conventions in message examples.
F G U R E
a) BOLD: Text that shall be entered exactly as it appears. (In this document, , , , , o are used to
S S S S T
represent non-printable characters. The ISO/IEC 646 representation of non-printable characters that
shall be used and is used in this document can be found in Annex A.)
b) italic, lower case: Variable parameters. The user shall supply an appropriate value. In some cases, default
values are recommended in this document.

© ISO/IEC 2025 – All rights reserved
Non-printable characters in accordance with Annex A shall be used. These come from the ISO/IEC 646 set of
characters and are as follows.
R R
— , where the two-letter couplet, superscript R (i.e. ) and subscript S (i.e. ), collectively represents a
S S
R
single non-printable format trailer character called record separator. The character is encoded as a
S
single byte of decimal value 030 (equivalently hexadecimal value 1E).
G G
— , where the two-letter couplet, superscript G (i.e. ) and subscript S (i.e. ), collectively represents
S S
G
a single non-printable data element separator character called group separator. The character is
S
encoded as a single byte of decimal value 029 (equivalently hexadecimal value 1D).
F F
— , where the two-letter couplet, superscript F (i.e. ) and subscript S (i.e. ), collectively represents a
S S
F
single non-printable segment terminator character called field separator. The character is encoded as
S
a single byte of decimal value 028 (equivalently hexadecimal value 1C).
U U
— , where the two-letter couplet, superscript U (i.e. ) and subscript S (i.e. ), collectively represents a
S S
U
single non-printable sub-element separator character. The character is encoded as a single byte of
S
decimal value 031 (equivalently hexadecimal value 1F).
E E
— o where the three-letter triplet, superscript E (i.e. ), small o (same font size, lower case o) and subscript
T
T (i.e. ), represents a single non-printable message trailer character called end of transmission. The
T
E
character o is encoded as a single byte of decimal value 04 (equivalently hexadecimal value 04).
T
NOTE If the literal letters RS, GS, FS, US or EoT were encoded in the data string, the resultant data would be in
error, and would not be in conformance with this document. In an application built according to this document, such a
data string would not be decoded, parsed or interpreted correctly.
In the following ISO/IEC 15434 message example, the non-printable characters are visually displayed as
R G R E
shown above; [)> 06 25SUN98765432187654321A2B4C6D8E o .
S S S T
Each non-printable character is encoded according to its decimal or hexadecimal value (listed above and in
Annex A), not according to the value for the individual letters. When they are decoded, and visual characters
are used to represent the non-printable characters, they sometimes do not appear as shown in this document.
5 Message format
5.1 General
This clause defines how data shall be transferred from a high capacity ADC media reading device to the
user's application software.
To allow multiple data formats to be contained within a data stream, a two-level structure of enveloping
is employed. The outermost layer of the message is a message envelope that defines the beginning and end
of the message. Within the message envelope, there is one or more format envelopes that contain the data
(see Figure 1). Multiple formats in a single message should only be employed with bilateral agreement of the
trading partners.
The message envelope shall consist of
— a message header,
— one or more format envelope(s), and
— a message trailer (when required).
Each format envelope within the message envelope shall consist of
— a format header,
— data, formatted according to the rules defined for that format, and
— a format trailer (when required).

© ISO/IEC 2025 – All rights reserved
Key
1 message envelope (see 5.2.1)
2 message header (see 5.2.2)
3 message trailer (see 5.2.3)
4 format envelope (see 5.3.1)
5 format header (see 5.3.2)
6 format trailer (see 5.3.3)
7 formatted data (see 5.4)
Figure 1 — Enveloping structure
5.2 Message envelope
5.2.1 General
The message envelope defines the start and end of the data contained within the data stream and provides
the following functions:
— indicates that the message contained within this media is formatted in conformance with the rules of
this document;
— indicates the character which has been defined to separate formats within this message;
— provides a unique character to indicate the end of the message.
The structure within a data stream is as follows:
a message, containing one or more formats;
a format, containing one or more segments;
a segment, containing one or more data elements;
a data element (field), potentially containing one or more sub-elements (sub-fields).

© ISO/IEC 2025 – All rights reserved
5.2.2 Message header
5.2.2.1 General
The message header consists of two parts:
— the three-character conformance indicator, and
— the format trailer character.
R
The complete message header is: [)>
S
5.2.2.2 Conformance indicator
The conformance indicator shall be the first three characters in the message header. It shall be [)> (left
bracket, right parenthesis and greater than). See Annex A for a table of decimal and hexadecimal values used
for characters in this document.
5.2.2.3 Format trailer character
The format trailer character shall be the fourth character in the message header. It shall be the non-printable
R
character “ ” (see Annex A). The format trailer character is used throughout the message to indicate the
S
end of a format envelope (see 5.3.3).
5.2.3 Message trailer
The message trailer identifies the end of the message within the data stream. It shall be the end of
E
transmission character, “ o ” (see Annex A). The message trailer character shall not be used elsewhere in
T
E
the message except in format “09” (binary data) where the “ o ” character can appear.
T
The message trailer shall not be used with formats “02” (complete EDI message / transaction) and “08”
(structured data using CII syntax rules).
5.3 Format envelope
5.3.1 General
The format envelope defines the start and end of data in a given format. The format envelope provides the
following functions:
— identifies the data format used within the envelope;
— defines the character(s) used to separate the segments, data elements (fields) and sub-elements (sub-
fields) within this data format;
— indicates any applicable date, release or control information.
An example message for each format is provided in Annex B.
5.3.2 Format header
5.3.2.1 General
A format header shall consist of:
— a format indicator (a two-digit numeric identifier which identifies the rules governing the format);
— variable header data (if any) which defines the separators used, the version, the release, and the date or
control information of the applicable standards.

© ISO/IEC 2025 – All rights reserved
Table 1 lists the format indicators and variable data associated with each format header.
Table 1 — Format header table showing associated separators
Format Format
Variable header data Format description
indicator trailer
00 Reserved for future use
G R
01 vv Transportation
S S
02 Complete EDI message / transaction
F G U R
03 vvvrrr Structured data using ANSI ASC X12 segments
S S S S
F G U R
04 vvvrrr Structured data using UN/EDIFACT segments
S S S S
G R
05 Data using GS1 application identifiers
S S
G R
06 Data using ASC MH10 data identifiers
S S
R
07 Free form text
S
08 vvvvrrnn Structured data using CII syntax rules
G G G G R
09 ttt.t ccc.c nnn.n Binary data
S S S S S
10 to 11 Reserved for future use
G R
12 Structured data following text element identifier rules
S S
13 Blocked for use to avoid conflict with ISO/IEC 15961-2
G R
14 aaa.a Data using JSON syntax
S S
G R
15 nnn…n ISO/IEC 20248 verifiable data construct
S S
16 to 99 Reserved for future use
Key
vv     two-digit version of format “01” being used (see 5.4.3.1)
R
format trailer character (see 5.3.3)
S
F
segment terminator (see 5.3.2.2.2)
S
G
segment terminator (see 5.3.2.2.2)
S
U
sub-element separator (see 5.3.2.2.4)
S
vvvrrr three-digit version (vvv) followed by the three-digit release (rrr) (see 5.3.2.6 and 5.3.2.7)
vvvvrrnn four-character version (vvvv) followed by the two-character release (rr) followed by the two-character edition indicator
(nn) (see 5.3.2.11)
ttt.t file type name (see 5.3.2.12)
ccc.c compression technique name (see 5.3.2.12)
nnn.n number of bytes (see 5.3.2.12 and 5.3.2.17)
aaa.a application name (see 5.3.2.16)
NOTE ASC MH10 data identifiers were previously known as FACT data identifiers.
5.3.2.2 Separators and terminators
5.3.2.2.1 General
The separators and terminators are an integral part of the data stream. The separator and terminator
characters shall not be used in non-binary data elsewhere in the message. For binary data strings (format
“09”), special considerations apply (see 5.3.2.12).
5.3.2.2.2 Segment terminator
Each segment in format “03” and "04" shall be terminated by the segment terminator character, the non-
F
printable character “ ” (see Annex A).
S
© ISO/IEC 2025 – All rights reserved
5.3.2.2.3 Data element separator
Data elements in formats “01”, “03”, "04", “05”, "06", "09", "12", "14" and “15” shall be separated by the data
G
element separator and the non-printable character “ ” (see Annex A).
S
5.3.2.2.4 Sub-element separator
Sub-elements in formats “03” and "04" shall be terminated by the sub-element separator character, the non-
U
printable character “ ” (see Annex A).
S
5.3.2.3 Format header “00” — Reserved format
The format header “00” is reserved for future use.
5.3.2.4 Format header “01” — Transportation
The format header shall be represented as
G
01 vv
S
where
G
is the data element separator to be used between data elements;
S
vv represents the two-digit version as given in 5.4.3.1.
5.3.2.5 Format header “02” — Complete EDI message / transaction
The format header shall be represented as
There is no variable header data for this format header (see 5.4.4).
5.3.2.6 Format header “03” — Structured data using ASC X12 segments
The format header shall be represented as
F G U
03vvvrrr
S S S
where
vvvrrr represents the three-digit version (vvv) and three-digit release (rrr) indicator used in ASC X12;
F
is the segment terminator to be used to indicate the end of an EDI segment;
S
G
is the data element separator to be used between EDI data elements;
S
U
is the sub-element separator to be used between EDI sub-elements in a composite data element.
S
Format header “03” shall employ ANSI ASC X12 segments, as specified in ANS X12, used in North America.
For international trade, format header “04” should be used.
NOTE Format “03” is common for EDI exchange between trading partners in North America.
5.3.2.7 Format header “04” — Structured data using UN/EDIFACT segments
The format header shall be represented as
F G U
04vvvrrr
S S S
© ISO/IEC 2025 – All rights reserved
where
vvvrrr represents the three-digit version (vvv) and three-digit release (rrr) indicator for the UN/EDIFACT
level used;
F
is the segment terminator to be used to indicate the end of an EDI segment;
S
G
is the data element separator to be used between EDI data elements;
S
U
is the sub-element separator to be used between EDI sub-elements in a composite data element.
S
5.3.2.8 Format header “05” — Data using GS1 application identifiers
The format header shall be represented as
G
S
G
where is the data element separator to be used between data fields.
S
5.3.2.9 Format header “06” — Data using ASC MH 10 data identifiers
The format header shall be represented as
G
S
G
where is the data element separator to be used between data fields.
S
5.3.2.10 Format header “07” — Free form text data
The format header shall be represented as
There is no variable header data for this format header (see 5.4.9).
5.3.2.11 Format header “08” — Structured data using CII syntax rules
The format header shall be represented as
08vvvvrrnn
where vvvvrrnn represents the four-character version (vvvv), two-character release (rr) and two-character
edition (nn) indicator for the CII level used. This equates to the BPID in CII syntax rules (see 5.4.10).
Format header “08” shall employ CII syntax rules, as specified in CII Syntax Rule Specifications, used in
Japan. For international trade, format header “04” should be used.
NOTE Format “08” is intended for use within Japan only.
5.3.2.12 Format header “09” — Binary data
The format header shall be represented as
G G G G
09 ttt.t ccc.c nnn.n
S S S S
© ISO/IEC 2025 – All rights reserved
where
G
is the data element separator to be used between fields in this header and at the end of the last
S
data field.
ttt.t represents the identification of the binary file type, e.g. JPEG, TIFF, PCX, BMP, CSV, CGM, GIF. This
field is a variable length of 1 to 30 characters (including version if applicable). This field shall be
G
terminated by the “ ” character. The binary file type and the means by which to represent the
S
binary file type should be mutually agreed upon between the trading partners.
ccc.c represents the compression technique employed. This field is a variable length of 0 to 30 char-
acters. If no compression is used, this field shall be left blank. In any case, this field shall be ter-
G
minated by the “ ” character. The compression technique and the means by which to represent
S
the compression technique should be mutually agreed upon between the trading partners.
nnn.n represents the number of bytes in the binary message. This field is a variable length field of 1
to 15 digits. The count does not include the length of the data format header or the data format
G
trailer. This field shall be terminated by the “ ” character, which is not part of the byte count.
S
5.3.2.13 Format headers “10” to “11” — Reserved formats
Format headers “10” to “11” are reserved for future use.
5.3.2.14 Format header “12” — Data using text element identifiers
The format header shall be represented as
G
S
G
where is the data element separator to be used between data fields.
S
5.3.2.15 Format header “13” — Reserved format
Blocked for use to avoid conflict with ISO/IEC 15961-2.
5.3.2.16 Format header “14” — Data using Java Script Object Notation (JSON) syntax
The format header shall be represented as
G
14aaa.a
S
where
aaa.a represents a target application name expected to process the JSON data. This may be seen as
a file name or a URL. The application name should be mutually agreed upon between trading
partners. This optional data is variable length from 0 to 1024 characters and shall only contain
printable characters shown in Annex A.
G
is the data element separator to be used between data fields.
S
5.3.2.17 Format header “15” — ISO/IEC 20248 verifiable data construct
The format header shall be represented as
G
15nnn.n
S
© ISO/IEC 2025 – All rights reserved
where
nnn.n represents the number of bytes in the binary message forming the ISO/IEC 20248 raw envelope.
G
is the data element separator to be used between data fields.
S
5.3.2.18 Format headers “16” to“99” — Reserved formats
Format headers “16” to “99” are reserved for future use.
5.3.3 Format trailer
The format trailer identifies the end of a format envelope. The format trailer shall consist of the format
R
trailer character, the non-printable character “ ” (see Annex A). The format trailer character shall not be
S
used in non-binary data elsewhere in the message.
The format trailer shall not be used with formats “02” and “08”.
5.4 Data format
5.4.1 General
Within a given format envelope, the data shall be formatted using one and only one of the following methods:
— transportation;
— complete EDI message / transaction (ASC X12, UN/EDIFACT or CII standard);
— structured text (ASC X12 or UN/EDIFACT subset);
— data structured using the rules of GS1 application identifiers;
— data structured using the rules of ASC MH 10 data identifiers;
— free form text;
— CII message record without message-group header and trailer;
— binary data;
— data structured using the rules of text element identifiers;
— data structured using JSON syntax;
— ISO/IEC 20248 verifiable data construct.
If more than one format is included in a message, format “01”, if used, shall be the first format in the message.
5.4.2 Format “00” — Reserved
This format is reserved for future use.
5.4.3 Format “01” — Transportation
5.4.3.1 General
Format “01” consists of two areas: the first is mandatory data which is common to all carrier sortation and
tracking applications, the second area is optional data which can be useful to specific applications between
trading partners.
© ISO/IEC 2025 – All rights reserved
The organization controlling the data structure within this format is identified through the version indicator
in the format header. At the time of publication of this document, the following versions have been identified:
— version “02” formatted according to the rules of ASC MH10/SC 8 (using measurement qualifiers of pounds
[“LB”] and kilograms [“KG”]);
— version “06” formatted according to the rules of the International Air Transport Association (IATA);
— version “56” formatted according to the rules of International Federation of Freight Forwarders
Associations (FIATA);
— version “96” formatted according to the rules of ASC MH10/SC 8 (using measurement qualifier of pounds
[“LB”] only).
5.4.3.2 Format “01” version “02”
5.4.3.2.1 Mandatory data
This data is required within version “02” of the “01” format. The following data elements shall be ordered
as listed below, immediately following the format header. Each data element is defined as either fixed or
variable length. Where fields are variable in length, the minimum field length and the maximum field length
G
(min.max) are shown below. All fields are separated by the data element separator character (“ ”) (see
S
Annex A) defined in the format header.
Ship to postal code (an 00.11)
Ship to country code (ISO 3166-1) (n 03)
Class of service (assigned by carrier) (an 01.03)
Tracking number (controlled by carrier) (an 01.20)
Origin carrier standard carrier alpha code (SCAC) (an 02.04)
SCAC of the carrier intended to transport the package
The recommended class of service is three digits of numeric data.
5.4.3.2.2 Optional data
There are nine optional data elements. Optional data elements, if used, shall immediately follow mandatory
data, in the order specified below. Each data element is defined as either fixed or variable length. Where
fields are variable in length, the minimum field length and the maximum field length (min.max) are shown
below. All optional fields, including blank ones, shall be separated by the data element separator character
G G
(“ ”) (see Annex A). Trailing data element separators shall be suppressed so that repeated characters do
S S
not occupy the end of the format envelope.
It is possible that data that has been identified as optional data is not needed in all applications. The optional
data fields and associated lengths are shown below.
Carrier assigned shipper ID (pick-up location) (an 01.10)
Julian day of pickup (n 03)
Shipment ID number (an 01 . 30)
n/x (container n of x total containers) (n 01.04 / n 01.04)
Weight (“LB” or “KG”) (decimal is a character if used) (r 01.08, a02)

© ISO/IEC 2025 – All rights reserved
Cross match (value is Y or N) (a 01)
Ship to street address (an 01.35)
Ship to city (an 01.35)
Ship to state/province (an 02)
Ship to name (an 01.35)
NOTE The weight qualifier is appended directly to the value without an intervening space and is in uppercase
letters. An example of this format would be if shipment weight is 117,6 kg, this data stream would appear as 117.6 KG.
For historic reasons, the encoded decimal mark is the character with hexadecimal value 2E as defined in ISO/IEC 646
as shown in Annex A.
5.4.3.3 Format “01” version "96"
5.4.3.3.1 Mandatory data
This data is required within version “96” of the “01” format. The following data elements shall be ordered
as listed below, immediately following the format header. Each data element is defined as either fixed or
variable length. Where fields are variable in length, the minimum field length and the maximum field length
G
(min.max) are shown below. All fields are separated by the data element separator character (“ ”) (see
S
Annex A) defined in the format header.
Ship to postal code (an 03.11)
Ship to country code (ISO 3166-1) (n 03)
Class of service (assigned by carrier) (an 01.03)
Tracking number (controlled by carrier) (an 01.20)
Origin carrier SCAC (an 02.04)
(SCAC of the carrier intended to transport the package)
The recommended class of service is 3 digits of numeric data.
5.4.3.3.2 Optional data
There are nine optional data elements. Optional data elements, if used, shall immediately follow mandatory
data, in the order specified below. Each data element is defined as either fixed or variable length. Where
fields are variable in length, the minimum field length and the maximum field length (min.max) are shown
below. All optional fields, including blank ones, shall be separated by the data element separator character
G G
(“ ”) (see Annex A). Trailing data element separators shall be suppressed so that repeated characters do
S S
not occupy the end of the format envelope.
It is possible that data that has been identified as optional data is not needed in all applications. The optional
data fields and associated lengths are shown below.
Carrier assigned shipper ID (pick-up location) (an 01.10)
Julian day of pickup (n 03)
Shipment ID number (an 01 . 30)
n/x (container n of x total containers) (n 01.04 / n 01.04)
Weight (lb) (decimal is a character if used) (r 01.10)

© ISO/IEC 2025 – All rights reserved
Cross match (value is Y or N) (a 01)
Ship to street address (an 01.35)
Ship to city (an 01.35)
Ship to state/province (an 02)
5.4.4 Format “02” — Complete EDI message / transaction
This format is used to encode an entire EDI transaction / message with the intent of passing it directly to an
EDI translator. The format shall be either ASC X12, UN/EDIFACT or CII-standard. Enveloping structures as
defined by the applicable standard shall be included, for example:
— ISA, GS, ST, SE, GE and IEA segments (for ASC X12);
— UNA, UNB, UNH, UNT and UNZ segments (for UN/EDIFACT); or
— message-group-header, message and message-group-trailer record (for CII standard).
E R
The message trailer character “ o ” and the format trailer character “ ” shall not be used with format “02”.
T S
There shall be no more than one “02” format in a message envelope. Format “02” shall not be combined with
any other format within a message envelope.
5.4.5 Format “03” — Structured data using ASC X12 segments
This format is used to represent data, such as ship to and ship from, etc., structured according to ASC X12
rules. This format allows the encodation of data represented by either individual ASC X12 segments without
enveloping, i.e. ISA/IEA, GS/GE and ST/SE, or a single ASC X12 transaction set with enveloping, i.e. ST/SE.
This data is not intended to be passed directly to an EDI translator.
F
For format “03,” the version of ASC X12 format is contained in the format header. The character “ ” shall
S
G
be used as the ASC X12 segment terminator. The character “ ” shall be used as the ASC X12 data element
S
U
separator. The character “ ” shall be used as the ASC X12 sub-element separator (see Annex A).
S
EDI segments such as BIN that encode binary data shall not be used in format “03.” Binary data should be
encoded only in format “09” (see 5.3.2.12).
Format header “03” employs ANSI ASC X12 segments, used in North America. For international trade, format
header “04” should be used. Format “03” is intended for use within North America only.
5.4.6 Format “04” — Structured data using UN/EDIFACT segments
This format is used to represent data, such as ship to and ship from, etc., structured according to UN/
EDIFACT rules.
This format allows the encodation of data represented by either individual UN/EDIFACT segments without
enveloping, i.e. UNB/UNA/UNZ and UNH/UNT, or a single UN/EDIFACT message with enveloping, i.e. UNH/
UNT. This data is not intended to be passed directly to an EDI translator.
F
For format “04,” the version of UN/EDIFACT format is contained in the format header. The character “ ”
S
G
shall be used as the UN/EDIFACT segment terminator. The character “ ” shall be used as the UN/EDIFACT
S
U
data element separator. The character “ ” shall be used as the UN/EDIFACT sub-element separator (see
S
Annex A).
5.4.7 Format “05” — Data using GS1 application identifiers
Each data element in this format shall be preceded by the appropriate GS1 application identifier (AI) code, as
specified by the GS1 General Specifications Standard, and followed by the data element separator character

© ISO/IEC 2025 – All rights reserved
G
“ ” unless the data element is the last field in the data format, i.e. the last format “05” data element is
S
R
followed by the format trailer character “ ” (see Annex A).
S
5.4.8 Format “06” — Data using ASC MH 10 data identifiers
Each data element in this format shall be preceded by the appropriate ASC MH10 data identifier (DI) code,
G
as specified by ANS MH10.8.2, and followed by the data element separator character “ ” unless the data
S
element is the last field in the data format, i.e., the last format “06” data element is followed by the format
R
trailer character “ ” (see Annex A).
S
5.4.9 Format “07” — Free form text format
This format permits free-form text information. There is no variable header data for this format. Complete
sentences are followed by a period and, if the sentence is not the last sentence in a paragraph, two spaces.
R
Two-line feeds are used between paragraphs. The format trailer character " " shall not be used within the
S
free form text message.
5.4.10 Format “08” — Structured data using CII syntax rules
This format is structured data according to CII standards (defined by the Center for Informatization of
Industry, Japan). Format “08” contains only one CII-message-record. Format-end and message-end in format
“08” shall be indicated by the CII-message-trailer.
E R
The message trailer character “ o ” and the format trailer character “ ” shall not be used with format “08”.
T S
Format “08” shall not be combined with any other format within a message envelope.
Format header “08” employs CII syntax rules, used in Japan. For international trade, format header “04”
should be used.
NOTE Format “08” is intended for use within Japan only.
5.4.11 Format “09” — Binary data
This format is for binary data in any format. The length and format of the data shall be identified in the
format header. Binary files shall be defined as to the type, compression technique and number of bytes used
in the data stream.
Binary data strings, such as those that represent digital image data, may be included in messages exchanged
by and agreed upon between trading partners. CAD/CAM drawings, picture files, various raster and vector
graphic images, as well as 2D and 3D images are examples of the kinds of data that can be compressed and
enc
...