What Is an EDI Document? 

“An EDI document is a structured electronic message that adheres to specific formatting rules defined by an EDI standard. It comprises data elements, segments, and envelopes, which work together to convey information efficiently and accurately.”

What Is a Data Element?

Data elements are the fundamental building blocks of EDI documents. They represent individual information within a transaction set, such as city, state, country, item number, quantity, and price.

Each data element is defined by its data type, which specifies whether it’s numeric, alphanumeric, a date, or a time. Additionally, the definition includes details like minimum and maximum length requirements and any applicable code values.

For instance, when using a unit cost data element, it’s essential to include a corresponding currency code element (e.g., U.S. dollars or euros) to indicate the specific currency being used. 

What Is a Segment? 

“A segment is a collection of related data elements in an EDI transaction set, like a section within a form.”  

For example, you’ll find different sections for item details, shipping information, and billing address on a purchase order, illustrated by the diagram below. Each section (here, we have four sections) represents a segment in EDI.

When using the ANSI standard, a purchase order above might include the following segments:

• ST: Segment identifier, indicating the start of the transaction set 

• BEG: Beginning of message, providing details about the transaction 

• N1: Name, defining the parties involved in the transaction 

Each segment begins with a segment ID, followed by data elements separated by a specific delimiter (e.g., an asterisk (*) in ANSI). This structured format ensures that computers can easily interpret and process EDI documents.

ST*850*1001	ST, to indicate the start of a transaction set – in this case, the 850 purchase order
BEG*00*SA*4768*65*20120930	BEG, to indicate the beginning of the PO, specifically	(1)
N1*SO*ABC Company	N1, a name segment	(2)
N3*123 Main Street	N3, to provide street address
N4*Fairview*CA*94168	N4, to provide city/state/zip
PO1*1*100*EA*27.65**VN*331896-42	PO1, to provide line item detail	(3)
CTT*1*100	CTT, to provide summary data for the PO	(4)
SE*8*1001	SE, to indicate the end of the PO

Once all segments are assembled in the correct order, they form a complete electronic document, known as a transaction set. To prepare these transaction sets for transmission to trading partners, they must be enclosed in envelopes.

What Are Envelopes In EDI? 

EDI documents utilize a system of envelopes to organize and transmit transaction sets. Like how physical documents are placed in envelopes for mailing, users structure EDI documents using three types of envelopes:

• Message Envelope: This envelope contains a single transaction set, such as a purchase order or invoice.

• Group Envelope: A group envelope can hold multiple transaction sets of the same type. For example, senders can group several purchase orders within a single group envelope. While optional in EDIFACT, the group envelope is mandatory in ANSI standards.

• Interchange Envelope: Encloses all group envelopes being sent from one sender to one receiver.

Let’s use the EDIFACT standard as an example to illustrate the structure of EDI envelopes. Transaction, group, and interchange envelopes are the three primary levels that surround an EDI message.

• Transaction Envelope: This level contains a single transaction or business document (e.g., a purchase order). It starts with the UNH segment and ends with the UNT segment.

• Group Envelope: This level encompasses multiple related transactions within a single group. It begins with the UNG segment and ends with the UNE segment.

• Interchange Envelope: This is the outermost level that encloses the entire EDI message. It starts with the UNA/UNB segments and ends with the UNZ segment.

The diagram below visually represents these three levels surrounding a single EDI purchase order.

What are EDI Document Standards? 

EDI document standards are the rules and guidelines that dictate the format and structure of electronic business documents. These standards ensure that different computer systems can communicate seamlessly, regardless of the specific software or hardware used.

Several standards are used in the industry, each with its strengths and applications:

ANSI ASC X12 

The American National Standards Institute (ANSI) established the Accredited Standards Committee (ASC) X12 to create standardized rules for electronic data interchange (EDI) across industries. Initially focused on North American businesses, X12 has gained global recognition, with over 300,000 companies adopting these standards worldwide for daily transactions. ASC X12 also contributes to developing UN/EDIFACT messages widely used outside the United States.

UN/EDIFACT

The UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce, and Transport) EDI document standard is a globally recognized system for electronic data exchange. Developed by the United Nations, this standard enables businesses to send and receive structured business documents across various industries and international borders, such as invoices, purchase orders, and shipping notices.

It facilitates seamless data exchange between companies, regardless of location or industry, making it an essential component of global EDI practices.

HIPAA

The U.S. Congress implemented the Health Insurance Portability and Accountability Act (HIPAA) in 1996 to improve the efficiency and effectiveness of the North American healthcare system. A crucial component of HIPAA is the creation of national standards for digital healthcare transactions and national identifiers for health insurance plans, providers, and employers. These standards promote the widespread use of Electronic Data Interchange (EDI) in the U.S. healthcare system.

HIPAA EDI transaction sets follow the X12 standard. Here are some key message types:

• 837: Health Care Claim

• 835: Health Care Claim Payment

• 270/271: Eligibility for Benefits

• 276/277: Explanation of Benefits

• 820: Referral Authorization Information

EANCOM

Based on the UN/EDIFACT standard, EANCOM offers a more detailed and comprehensive approach to data exchange.

Originally designed for the retail industry, EANCOM has expanded to various sectors, including healthcare, construction, and publishing. Today, it remains one of the most widely used subsets of UN/EDIFACT.

VICS

The Voluntary Inter-industry Commerce Standard (VICS EDI) is a widely adopted EDI standard within the North American retail industry. As a subset of the ANSI ASC X12 national standard, VICS EDI is used by thousands of companies, including department stores, specialty retailers, mass merchandisers, and their suppliers.

In 1988, GS1 US took over the management and administration of VICS EDI. GS1 US also oversees other industry-specific standards, such as the grocery industry’s Uniform Communication Standard (UCS) and the Industrial/Commercial Standard (I/C) for the industrial sector.

ODETTE

The ODETTE EDI standard, developed by the Organization for Data Exchange by Tele Transmission in Europe (ODETTE), is specifically designed for the European automotive industry. It allows for exchanging critical business documents like orders, invoices, and delivery schedules between automotive manufacturers and suppliers.

Widely adopted in Europe, ODETTE EDI ensures efficient and precise communication within the automotive sector. Its integration with other global standards enables seamless communication across international supply chains.

Tradacoms

The Tradacoms EDI document standard was an early electronic data interchange system widely used in the U.K. retail sector. Developed in the early 1980s, Tradacoms was one of the first standards designed to facilitate electronic business document exchanges, particularly for retailers.

Initially based on the UN/GTDI syntax, Tradacoms was maintained and extended by the U.K. Article Numbering Association, now known as GS1 UK. Although its development ceased in the mid-1990s in favor of the EDIFACT standard, many U.K. retailers continued to use Tradacoms due to its established presence.

VDA

VDA EDI focuses on essential transactions like orders, delivery instructions, and inventory updates. Widely used across the German automotive industry, this standard supports just-in-time production by ensuring that information flows smoothly and accurately between all parties involved.

The VDA has developed over thirty different messages to meet the specific requirements of major companies like Audi, VW, Bosch, Continental, and Daimler AG.

RosettaNet

RosettaNet is a consortium of major technology and industry leaders that has developed open, industry-wide standards for electronic business processes. These standards create a common language for e-business, enabling seamless collaboration and communication among supply chain partners worldwide. Various industries, including technology, manufacturing, and retail, have widely adopted RosettaNet.

The RosettaNet document standard is XML-based and defines guidelines for message formats, business process interfaces, and implementation frameworks.

SWIFT

The Society for Worldwide Interbank Financial Telecommunication (SWIFT) enables secure communication between banks. It offers software and services for financial institutions, facilitating the exchange of financial documents via its SWIFTNet network. SWIFT uses standards like FIN, InterAct, and FileAct for message encoding.

The SWIFT document standard is a comprehensive framework that covers various financial transactions, including:

• Payments: Transfers of funds between accounts.

• Trade Services: Documentation related to international trade, such as letters of credit and bills of lading.

• Securities: Transactions involving stocks, bonds, and other financial instruments.

• Trading: Messages related to trading activities, such as market data and order execution.

The SWIFT network is widely used by financial institutions worldwide, connecting over 11,000 banks and financial institutions in more than 200 countries. This global reach makes SWIFT an essential tool for international financial transactions.

While EDI document standards provide the framework for electronic data exchange, the specific types of EDI documents determine the nature of the transactions being conducted. Understanding these document types is essential for businesses to effectively leverage EDI technology and ensure seamless communication with trading partners.

EDI Document Types

There are hundreds of EDI document types, each serving a specific purpose in business transactions. These types cover various functions, from purchase orders and invoices to shipping notices and electronic funds transfers.

The exact number of EDI document types can vary depending on industry-specific standards and evolving business needs.

However, some of the most common types include:

EDI 810 – Invoice

The EDI 810 document is an electronic counterpart to the traditional paper invoice. It follows standard EDI formats like X12, ANSI, and EDIFACT. This document, sent by the supplier, informs the buyer of the purchase details, including pricing and quantities delivered. It also contains payment terms and conditions as specified by the buyer.

EDI 812 – Credit/Debit Adjustment

The EDI 812 document is the electronic version of a paper-based Credit/Debit Adjustment. Utilizing formats such as X12, ANSI, and EDIFACT enables trading partners to convey credit or debit adjustments to their suppliers’ accounts. These adjustments may either modify an existing invoice or stand alone as an individual transaction.

EDI 813 – Electronic Filing of Tax Return Data

The EDI 813 document replicates the process of filing tax returns electronically. It adheres to standard EDI formats like X12, ANSI, and EDIFACT and is employed to submit tax return data to federal, state, or local tax authorities.

EDI 818 – Commission Sales Report

The EDI 818 document is the digital equivalent of a paper Commission Sales Report. It uses formats like X12, ANSI, and EDIFACT to enable a retailer to inform a trading partner about commission sales and salary information. This document assists the trading partner in reconciling commission payments and maintaining salary records.

EDI 820 – Payment Order/Remittance Advice

The EDI 820 document replaces the traditional paper Payment Order/Remittance Advice. It can be used for several purposes: to request payment for an outstanding item, to provide payment details to the payee, or to notify the payee of any payment adjustments. Either the buyer or the supplier can initiate this document.

Typically, the buyer sends the EDI Payment Order/Remittance Advice after successfully receiving an EDI 810 (Invoice) from the seller. It often accompanies an invoice payment and marks the conclusion of the order lifecycle.

EDI 829 – Payment Cancellation

The EDI 829 document is an electronic request to cancel a previously initiated payment before funds are released. This document uses standard formats such as X12, ANSI, and EDIFACT, facilitating seamless communication between companies and financial institutions.

EDI 832 – Price/Sales Catalog

The EDI 832 document replicates the electronic version of a Price/Sales Catalog, following formats like X12, ANSI, and EDIFACT. This document allows vendors to provide trading partners with detailed product data for ordering purposes, helping maintain an updated catalog of goods or services.

EDI 837 – Health Care Claim

The EDI 837 document electronically submits health care claim information, replacing the paper Health Care Claim form. Healthcare providers use it to submit billing information and patient encounter details to payers. This standardized format, available in X12, ANSI, EDIFACT, and other EDI standards, streamlines the claims submission process and reduces administrative costs for providers and payers.

EDI 840 – Request for Quotation

The EDI 840 document is an electronic Request for Quotation, following formats such as X12, ANSI, and EDIFACT. It allows buyers to request pricing, delivery schedules, or other relevant seller information.

EDI 841 – Specifications/Technical Information

The EDI 841 document is the electronic version of a Specifications/Technical Information form. It uses standard formats like X12, ANSI, and EDIFACT to exchange specifications, technical details, product descriptions, and engineering changes between trading partners.

EDI 846 – Inventory Inquiry/Advice

The EDI 846 document is the electronic form of an Inventory Inquiry/Advice. Following formats such as X12, ANSI, and EDIFACT, it enables manufacturers or suppliers to notify trading partners about available inventory, often highlighting overstocked items that may be available at a discounted rate.

EDI 850 – Purchase Order

The EDI 850 document represents the digital version of a paper Purchase Order. Standard EDI formats like X12, ANSI, and EDIFACT allow buyers to communicate their specific item, quantity, and pricing needs to suppliers. The document may also include shipping instructions and payment terms.

EDI 855 – Purchase Order Acknowledgment

The EDI 855 document is an electronic acknowledgment of a Purchase Order, following formats like X12, ANSI, and EDIFACT. Sent by the supplier, this document notifies the buyer that their purchase order will be fulfilled as requested. It details items, prices, and quantities and may also indicate any changes or issues, such as stock shortages or discrepancies in terms.

When a seller receives a purchase order, they send an EDI 855 back to the buyer, confirming receipt and acceptance or indicating any necessary adjustments.

EDI 888 – Item Maintenance

The EDI 888 document provides an electronic method for Item Maintenance. Standard formats like X12, ANSI, and EDIFACT enable manufacturers, suppliers, brokers, or agents to communicate detailed information about new products or changes to existing product specifications.

EDI 997 – Functional Acknowledgment

The EDI 997 document is an electronic acknowledgment of receipt for another EDI document. It follows standard formats such as X12, ANSI, and EDIFACT, allowing trading partners to confirm the successful transmission of a document.

The EDI Functional Acknowledgment is an essential part of the EDI transaction process. For instance, when a buyer sends a purchase order, the supplier can respond with an EDI 997, confirming receipt and indicating whether the order is accepted, modified, or rejected.

How EDI Document Works 

The process primarily involves the three crucial steps defined below: 

Step 1: Preparing Documents for Transmission 

The first step in sending an EDI document involves thorough preparation, which includes several vital tasks. One of the most critical aspects is data mapping, where data from the source system is mapped into the relevant fields of the EDI document. Proper data mapping is crucial as it ensures the accuracy and integrity of the information being transmitted. 

Following data mapping, the process moves to data validation. During this phase, the data is checked for completeness and accuracy, ensuring that all required fields are correctly populated, and that the information complies with standards such as those set by the American National Standards Institute (ANSI).  

The final task in this step is EDI testing, which is essential to confirm that the receiving organization can successfully integrate, transmit, and process the data within its systems. 

Businesses can prepare EDI documents by organizing the necessary data using various methods. These include manual data entry, exporting data from spreadsheets or databases, or using software that automatically generates output files formatted for EDI translation.  

Step 2: Translating Documents into EDI Format 

Once the documents are ready, the next step is to translate them into the EDI format. This translation is essential as it converts the data into a standardized format to ensure that the receiving organization can process it without issues. Specialized EDI software typically handles the translation process, automating the conversion and including features for data validation and compliance checks. 

Businesses have the option to manage this translation process in-house using their software, which may require specific expertise in data mapping to ensure the correct correlation between internal data and the EDI format. Alternatively, companies can outsource this task to an EDI service provider, who will handle the translation and ensure the data meets all necessary standards before it is sent to the trading partner. 

Step 3: Transmitting EDI Documents to Business Partners 

The final step in the EDI document processing is the transmission of the translated documents to the business partner. This step involves establishing a secure communication channel, which could be done directly through protocols like AS2 or via an EDI network provider. Once the connection is established, documents are packaged into an EDI envelope and transmitted over the network. It is crucial to monitor this transmission to ensure successful delivery and maintain accurate records. 

Businesses can choose the transmission method based on their specific needs and the preferences of their trading partners. This could involve direct connections, network providers, or a combination of both, depending on the expected transaction volume and the nature of the partnership. 

Automation 

To further streamline EDI operations, businesses often implement automation tools. These tools handle the translation, routing, and validation of EDI messages, ensuring that the data is integrated seamlessly with other business systems. Automation improves the efficiency and accuracy of EDI transactions. It also ensures compliance with relevant file transfer protocols, significantly reducing the manual effort. 

Conclusion 

EDI’s ability to automate processes, ensure data standardization, and integrate seamlessly with existing business systems makes it an invaluable asset for companies looking to optimize their supply chains and improve overall productivity. As businesses expand their global reach and face increasing competitive pressures, the need for reliable and efficient EDI solutions becomes even more critical. 

Astera EDI Connect is an enterprise-grade solution for hassle-free B2B data exchange. The code-free, unified platform covers the entire EDI process—from data extraction and translation to acknowledgment generation and transmission. Its intuitive drag-and-drop interface allows even non-technical users to customize transactions, segments, and validations with ease. 

Astera EDI Connect empowers users to: 

• Create Detailed Trade Partner Profiles: Define unique data mapping requirements, validation checks, and custom transaction sets. 

• Validate Files: Ensure all incoming and outgoing files meet standard and custom validation criteria. 

• Process Complex EDI Documents and Files: Handle files of any size and complexity easily. 

• Define and Automate Workflows: Automatically generate technical and functional acknowledgments upon receipt of EDI messages. 

• Meet Partner Requirements: Seamlessly exchange EDI files using AS2, FTP, and email. 

• Build Hierarchical Transactions: Utilize a library of built-in transformations to construct complex EDI transactions. 

• Real-Time Error Correction: Address mapping errors immediately to maintain accuracy and efficiency.