1. What Is EDI and GS1?

1.1 What Is EDI?

Electronic Data Interchange (EDI) is the computer-to-computer exchange of business documents in a standardised electronic format between trading partners. EDI replaces paper-based processes like purchase orders, invoices, and despatch advices with structured electronic messages, reducing manual data entry, errors, and processing time.

EDI is not email attachments or PDFs — it is a structured, machine-readable format where each piece of information (item code, quantity, price, date) occupies a defined position in the message, allowing the receiver's system to process it automatically.

1.2 What Is GS1?

GS1 is a neutral, not-for-profit organisation that develops and maintains global standards for business communication. GS1 standards operate on three layers:

LayerFocusExamples
IdentifyUnique identification keys for business entitiesGTIN, GLN, SSCC
CaptureBarcode and RFID data carriersEAN/UPC, GS1-128, EPC/RFID
ShareElectronic exchange of business dataEANCOM, GS1 XML, GDSN

GS1 EDI sits in the Share layer. It integrates electronic information sent between trading partners with the physical flow of goods by using GS1 identification keys (GTIN, GLN, SSCC) as the common language across all messages.

1.3 Common Use Cases

ScenarioEDI Messages Involved
Retail orderingPRICAT → ORDERS → ORDRSP → DESADV → RECADV → INVOIC
Cross-border logisticsIFTMIN → IFTMBC → DESADV → RECADV → IFTSTA
Healthcare supply chainORDERS → DESADV → INVOIC + GS1 Healthcare identifier extension
Transport & warehousingHANMOV → INSDES → DESADV → RECADV → RETANN
Financial reconciliationINVOIC → COMDIS → REMADV → PAYMUL — COACSU

2. GS1 EDI Standards Overview

2.1 EANCOM (UN/EDIFACT Subset)

GS1 EANCOM is a GS1 subset of the UN/EDIFACT standard (United Nations Electronic Data Interchange for Administration, Commerce and Transport). It contains only the message elements required by business applications and mandated by the syntax — omitting optional elements not relevant to GS1 users.

Key characteristics:

Data format: EANCOM messages use the UN/EDIFACT syntax — variable-length records with segment tags and element separators (typically + for element separation and ' for segment termination). The messages are transmitted as plain text files, often compressed and sent via AS2, AS4, or SFTP.

2.2 GS1 XML

GS1 XML is an alternative XML-based EDI standard that provides the same business semantics as EANCOM but uses XML syntax. It is designed for organisations that prefer XML-based integration, offering:

2.3 GS1 eCom

GS1 eCom is the umbrella term covering both EANCOM and GS1 XML. Both standards carry the same business content — the choice is purely a syntax preference. GS1 provides implementation guidelines for both forms.

2.4 Comparison

AspectEANCOM (UN/EDIFACT)GS1 XML
SyntaxFixed format, delimitedXML with XSD schemas
File sizeCompactLarger (verbose XML)
ToolingMature EDI translatorsXML tools widely available
Industry adoptionRetail, transport, healthcareRetail, GDSN
TransportAS2, AS4, OFTP2, SFTPAS4, SFTP, SOAP, REST
Current edition2022 (Syntax 3), Syntax 42022 (Syntax 3), Syntax 4

3. EANCOM Message Structure

3.1 Hierarchy

An EANCOM transmission follows a four-level hierarchy:

Interchange (UNB ... UNZ)
  ├── Message (UNH ... UNT)
  │     ├── Segment Group (SG)
  │     │     ├── Segment (e.g. NAD, LIN, QTY)
  │     │     │     ├── Data Element (e.g. 7140, C186)
  │     │     │     │     ├── Element Value (e.g. "54012345678901")
  │     │     │     │     └── (more elements)
  │     │     └── Nested Segment Groups
  │     └── (more messages)
  └── (more interchanges)

3.2 Interchange Level

SegmentNamePurpose
UNBInterchange HeaderSender/receiver IDs (GLNs), date/time, interchange reference, syntax identifier
(messages)One or more EANCOM messages
UNZInterchange TrailerMessage count, interchange reference

3.3 Message Level

SegmentNamePurpose
UNHMessage HeaderMessage type (e.g. ORDERS), version, release, controlling agency (GS1 = UN)
(segments)Business content organised in segment groups
UNTMessage TrailerSegment count, message reference

3.4 Segment Groups

Segments are grouped into logical clusters called Segment Groups (SG). For example, the ORDERS message uses SG1 for party identification (NAD segments), SG7 for line item detail (LIN, QTY, PRI, MOA), and so on.

3.5 GS1 Keys as Identifiers

A defining feature of EANCOM is the use of GS1 keys to identify entities in the data elements:

GS1 KeyEANCOM UsageExample in EANCOM
GTIN (Global Trade Item Number)Identifies products in LIN and PIA segments05401234567890 (14 digits)
GLN (Global Location Number)Identifies parties in NAD segments (buyer, seller, delivery location)5401234567890 (13 digits)
SSCC (Serial Shipping Container Code)Identifies logistic units in DESADV (PCI + GIN segments)354012345678901234 (18 digits)

4. GS1 EDI Messages by Business Process

The EANCOM Syntax 3 standard defines the following messages, grouped by business process:

4.1 Master Data

MessageNamePurpose
PARTINParty InformationExchange of trading partner details (name, address, GLN, contacts)
PRICATPrice/Sales CatalogueProduct catalogue with prices, descriptions, GTINs
PRODATProduct DataDetailed product specifications and attributes
PROINQProduct InquiryRequest for product information

4.2 Ordering

MessageNamePurpose
QUOTESQuotationSupplier's quoted prices and terms
REQOTERequest for QuotationBuyer's request for pricing
CNTCNDContractual ConditionsFramework agreements and contract terms
ORDERSPurchase OrderOrder for goods or services
ORDRSPPurchase Order ResponseAcknowledgement, acceptance, or rejection of an order
ORDCHGPurchase Order Change RequestRequest to modify an existing purchase order
OSTENQOrder Status EnquiryQuery about order status
OSTRPTOrder Status ReportStatus update on an order

4.3 Transport and Delivery

MessageNamePurpose
DESADVDespatch AdviceNotification that goods have been despatched
RECADVReceiving AdviceConfirmation of goods received
INSDESInstruction to DespatchRequest to release goods for despatch
HANMOVCargo/Goods Handling and MovementInternal warehouse movement or cross-docking
IFTMINTransport InstructionTransport order specifying pick-up and delivery
IFTMBFFirm BookingConfirmed transport booking
IFTMBCBooking ConfirmationAcceptance of a transport booking
IFTSTATransport StatusStatus update during transport
IFCSUMForwarding and Consolidation SummaryConsolidated shipment summary
IFTMANArrival NoticeNotification of arrival
RETANNAnnouncement of ReturnNotification of returned goods
RETINSInstruction for ReturnRequest to accept returned goods

4.4 Financial

MessageNamePurpose
INVOICInvoiceCommercial invoice for goods or services
COMDISCommercial DisputeDispute regarding an invoice
REMADVRemittance AdviceNotification of payment
PAYMULMultiple Payment OrderBulk payment instruction
COACSUCommercial Account SummaryPeriod account summary
TAXCONTax ControlTax-related information

4.5 Report and Planning

MessageNamePurpose
DELFORDelivery ScheduleJust-in-time delivery schedule
SLSRPTSales Data ReportPoint-of-sale or sales data
SLSFCTSales Forecast ReportPredicted future sales
INVRPTInventory ReportCurrent stock levels
MSCONSMetered Services ConsumptionUtility/consumption data
QALITYQuality DataQuality inspection results

4.6 System

MessageNamePurpose
CONTRLSyntax and Service ReportSyntax-level acknowledgement and error report
APERAKApplication Error and AcknowledgementApplication-level acknowledgement
GENRALGeneral MessageFree-format message for non-standard data

5. Key Messages in Detail

5.1 ORDERS — Purchase Order

The most widely used EANCOM message. A buyer sends ORDERS to a supplier to order goods or services.

Key segments:

SegmentRoleExample
BGMBeginning of messageBGM+220::9+ORD-12345+9'
DTMDate/timeDTM+137:20260622:102' (document date)
SG1 (NAD)PartiesBuyer GLN, seller GLN, delivery location GLN
SG2 (RFF)ReferencesContract number, quote reference
SG7 (LIN)Line item — GTINLIN+1++54012345678901:SRV'
SG7 (QTY)Ordered quantityQTY+21:500:PCE'
SG7 (PRI)Net pricePRI+AAA:12.50::KGM'
SG7 (MOA)Monetary amountMOA+203:6250.00'
CNTControl totalTotal line items, total quantity
UNTMessage trailerSegment count + message reference

Example (simplified):

UNB+UNOC:3+5401234567890:14+5098765432109:14+220622:1200+REF001'
UNH+1+ORDERS:D:16B:UN:EAN011'
BGM+220::9+PO-20260622+9'
DTM+137:20260622:102'
NAD+BY+5401234567890::9'
NAD+SE+5098765432109::9'
LIN+1++54012345678901:SRV'
QTY+21:500:PCE'
PRI+AAA:12.50'
MOA+203:6250.00'
LIN+2++54012345678918:SRV'
QTY+21:200:PCE'
PRI+AAA:8.75'
MOA+203:1750.00'
CNT+2:2'
UNT+15+1'
UNZ+1+REF001'

Key point: Each line item ships the GTIN of the product. The buyer and seller are identified by their GLNs in the NAD segments. No textual product descriptions are needed — the GTIN is the master key.

5.2 DESADV — Despatch Advice

The supplier sends DESADV when goods are shipped. It informs the buyer what was shipped, when, how, and on which logistic units.

Key segments:

SegmentRole
BGMBGM+351::9+DES-001' (despatch advice)
DTMDespatch date, delivery date
SG1 (NAD)Despatcher, delivery location
SG4 (RFF)Purchase order reference
SG10 (CPS)Hierarchical packaging structure
SG11 (PAC)Package type (pallet, case, etc.)
SG12 (PCI+GIN)SSCC for each logistic unit
SG14 (LIN)GTIN of despatched products
SG14 (QTY)Despatched quantity
UNTTrailer

Example (simplified):

UNB+UNOC:3+5098765432109:14+5401234567890:14+220622:1400+DES002'
UNH+1+DESADV:D:16B:UN:EAN010'
BGM+351::9+DES-20260622-001+9'
DTM+11:20260622:102'
NAD+SF+5098765432109::9'
NAD+ST+5401234567890::9'
RFF+ON+PO-20260622'
CPS+1'
PAC+1+201:::CT'
PCI+33E'
GIN+SSCC+354012345678901234'
CPS+2+1'
PAC+2+201:::CT'
LIN+1++54012345678901:SRV'
QTY+12:500:PCE'
UNT+15+1'
UNZ+1+DES002'

The CPS/PAC/PCI segments describe the packaging hierarchy — which SSCCs contain which GTINs and quantities. This enables the receiver to verify deliveries against SSCC scans.

5.3 RECADV — Receiving Advice

The buyer sends RECADV after receiving and checking the goods. It confirms what was received, what was accepted, and what was rejected or damaged.

Key segments:

SegmentRole
BGMBGM+631::9+REC-001' (receiving advice)
RFFReference to DESADV and ORDERS
SG2 (NAD)Receiver, despatcher
SG8 (LIN)GTIN of received product
SG8 (QTY)Received quantity, accepted quantity, rejected quantity
SG12 (PCI+GIN)SSCC reference

5.4 INVOIC — Invoice

The supplier sends INVOIC to bill for goods or services delivered.

Key segments:

SegmentRole
BGMBGM+380::9+INV-001' (invoice)
DTMInvoice date, due date, period
SG1 (NAD)Seller (invoicing party), buyer, payer
SG2 (RFF)Purchase order reference, DESADV reference
SG24 (LIN)GTIN of invoiced item
SG24 (QTY)Invoiced quantity
SG24 (PRI)Unit price
SG24 (MOA)Line amount, tax amount
SG33 (TAX)VAT/tax breakdown
SG50 (MOA)Total invoice amount, payment terms

5.5 PRICAT — Price/Sales Catalogue

The supplier sends PRICAT to publish their current product catalogue — GTINs, descriptions, prices, and effective dates.

Key segments:

SegmentRole
BGMBGM+9::9+CAT-001' (catalogue)
DTMEffective dates, expiry dates
SG1 (NAD)Catalogue provider
SG6 (LIN)GTIN of catalogue item
SG6 (PIA)Additional product IDs (e.g. manufacturer part number)
SG6 (IMD)Item description
SG7 (QTY)Pack size, minimum order quantity
SG7 (PRI)Catalogue price, trade discount tiers

5.6 PARTIN — Party Information

Trading partners exchange PARTIN to share GLNs and party details. This is typically exchanged once (or updated when changes occur) before any transaction messages flow.

Key segments:

SegmentRole
BGMBGM+36::9+PIN-001' (party info)
SG1 (NAD)Party GLN, name, address
SG1 (CTA)Contact person
SG1 (COM)Communication (phone, fax, email)
SG2 (RFF)Tax identifier, DUNS number

6. EDI Communication Protocols

EDI messages must be transported between trading partners. The following protocols are commonly used:

ProtocolTypeSecurityReliabilityCommon Use
AS2HTTP(S)S/MIME encryption + digital signatureMDN (Message Disposition Notification)Retail, CPG (Walmart, Target, etc.)
AS4Web services (ebMS)WS-Security + encryptionReceipt + non-repudiationEuropean retail, healthcare
OFTP2TCP/IPEncryption + digital signatureEnd-to-end acknowledgementAutomotive (VDA), European retail
SFTPFile transferSSH key/passwordNone in-protocol — relies on file checkGeneral purpose
SOAP (GS1 XML)HTTP(S)WS-SecuritySOAP responseGDSN, XML-based EDI

AS2 is the dominant protocol in North American retail. AS4 is increasingly mandated for European healthcare and public procurement. OFTP2 is widely used in the German automotive supply chain.


7. Implementation

7.1 Getting Started

The GS1 implementation roadmap follows these steps:

  1. Obtain a GLN for your organisation — this is your identifier in all EDI messages
  2. Assign GTINs to your products (GS1 Company Prefix → GTIN allocation)
  3. Choose your EDI standard — EANCOM (UN/EDIFACT) or GS1 XML
  4. Select a communication protocol — AS2, AS4, OFTP2, or SFTP
  5. Set up an EDI translator — commercial or open-source solution that maps between your internal data format and EDI messages
  6. Exchange PARTIN with your trading partner to share GLNs and contact details
  7. Test and certify — typically an end-to-end test of message pairs (ORDERS ↔ ORDRSP, DESADV ↔ RECADV)
  8. Go live — migrate from parallel paper/EDI to live-only EDI

Implementation guidelines are available at gs1.org/ecom-implementation. GS1 recommends working with a GS1 Member Organisation for local support and certification.

7.2 EDI Translator Architecture

ERP/WMS (your internal system)
    |
    v
EDI Translator (maps data / EDI format)
    |
    +-- Outbound: Internal format → EANCOM/XML → send
    +-- Inbound: Receive → EANCOM/XML → Internal format
    |
    v
Communication Adapter (AS2, AS4, SFTP, ...)
    |
    v
Trading Partner (buyer/supplier)

7.3 Best Practices

PracticeDetails
Use GS1 keys consistentlyAlways use GTIN, GLN, SSCC in all EDI messages — never substitute internal codes
Agree message pair flowsDefine exactly which messages will be exchanged, in what sequence, and expected response times
Validate earlyUse GS1 validation tools before going live with a partner
Handle acknowledgementsAlways process CONTRL (syntax level) and APERAK/ORDRSP (business level) responses
Design for changeGTINs and GLNs change — your system must handle updates via PRICAT and PARTIN
Monitor transmissionLog all send/receive events; MDN receipts for AS2, file detection for SFTP
Plan for 1:ManyA single EDI implementation connects to many trading partners — design for multi-tenant mapping
Respect business cyclesSome partners only process EDI on specific schedules; plan time-windows and deadlines

7.4 Common Pitfalls

PitfallImpact
GTIN/GLN mismatch between EDI and internal systemOrder fails to process — manual intervention required
Incorrect UN/EDIFACT syntax versionReceiver CONTRL error — message rejected
Missing CONTRL/APERAK handlingUnacknowledged messages — no visibility into failures
SSCC not assigned before DESADVInconsistent logistic unit tracking in supply chain
No DESADV before RECADVReceiving team cannot pre-stage for inbound goods

8. References