Electronic Data Interchange

bar.gif (572 bytes)


bar.gif (572 bytes)

MS Word Format

EDI Definition
EDI History
Benefits of EDI
Risks of EDI



This report is intended to provide information about EDI. It is a fulfillment of the original proposal and a continuation and enhancement of the class presentation. The presentation defined EDI and discussed past, present, and future aspects of EDI along with a brief overview of implementation. This report will cover the same information at a more detailed level.

Top of page


Electronic data interchange (EDI) is often defined as the transfer of information, especially business documents, through electronic means. EDI can also be defined as the computer-to-computer exchange of business documents between companies, using a public standard format. Rather than preparing paper and sending it through the mail, or using other communications methods such as fax, EDI users exchange business data directly between their respective computer systems. EDI is the closest option to implementing a paperless office.

These business documents are often notices of shipments, invoices, and purchasing orders, which are used to communicate information between organizations. An example of the use of EDI is when a retail vendor uses EDI to make shipment requests from its suppliers. This method is used in substitution for the usual method of communication where paper documents are physically carried from department to department, or mailed or faxed from one organization to another, and manually re-entered into the computer of the recipient.

One important distinguishing feature of EDI is that it is a computer-to-computer process. This automated process allows electronic data to be transferred without human intervention, transferring data that only computers can make sense of. Humans cannot decipher the content of such messages. The information can be transmitted immediately and accurately into a computer-processing format.

There are some common misconceptions about what EDI is. For example, e-mail is not considered EDI. E-mail is used to send information between humans that humans understand, whereas EDI is a computer-to-computer process. Similarly, facsimiles such as electronic bulletin boards and modems are not EDI. Also, sharing files through a network such as a LAN, WAN, or MAN is not considered EDI. Lastly, sharing files over networks does not conform to the EDI definition because EDI often requires the translation of data into special formats. EDI is generally an automated process.

The use of EDI is not limited by differences in computer or communications equipment among trading companies. It bridges the previous information gap that existed between companies with different computer systems.

EDI is also independent of users' internal computerized application systems, since it interfaces with those systems rather than being integrated with them. However, the degree of effectiveness of the EDI operation itself, as well as the internal management information available from its use, will certainly be greater if application systems are up-to-date and efficient.

EDI is based on the use of message standards, ensuring that all participants use a common language. This is unlike e-mail and electronic bulletin boards which require that the document be sent in an agreed upon format by the sender and receiver. The application in which the document was produced must be the same for the sender and receiver, in order to accurately transfer the document. With EDI, a message standard consists of uniform formats for business documents, which have been adopted for electronic transmission purposes. It also includes security and control elements, and other rules and conventions relating to the use of transaction sets that all users agree to follow.

How do EDI standards actually work? It is a one directional transmission of information, e.g., purchase orders are generated by a retailer to a supplier; subsequently, the supplier can send an invoice to the retailer.

EDI transmission typically involves the following process. The sender uses internal computer files to assemble the data needed for the transaction. This data file then becomes input to a software module that generates the transaction into the EDI standard format. The resulting data file is then transmitted to the receiver. At the receiving end, this data file is input to a software module that translates the data from an EDI format into a file that can be entered into the receiver's computer application systems.

The above process includes a number of control and security procedures. Data security is maintained through the use of user identification numbers and passwords. EDI

translator software is available from commercial suppliers and typically includes extensive data editing and error-checking routines. This facility ensures that the data is valid at the time of transmission and that it is also valid when it is received. EDI standards also allow the receiver to acknowledge successful receipt of the transmission by sending an acknowledgement message back to the sender. EDI, then, is at least as secure and accurate as the exchange of paper documents.

Top of page


EDI has been under development in the U.S. in one form or another since the mid-1960s. It first appeared within a few large companies that had their important suppliers dial-in and download orders. This eventually created a problem. Each company had their own format which caused suppliers to program differently to fit the document format for each supplier the company had connections with. Finally, in 1968, the transportation industry realized that there were large amounts of paperwork that needed to be completed as business transactions. Shipments of products were being slowed down because of all the paperwork that had to be filled out. A group of railroad companies concerned with the quality of inter-company exchanges of transportation data formed an organization to study the problem and to improve it. To resolve this issue, the transportation industry organized a committee, known as the Transportation Data Committee (TDCC). They were designed to develop a standard format to exchange business documents and information. The first EDI documentation was released in 1975.

At about the same time, individual companies such as General Motors, Sears, and

K-Mart were also addressing the inefficiencies of inter-corporate document movement

by using their own electronic (but proprietary) systems with their major trading partners.

By the mid 1980's, K-Mart's system, EPOS, was being used by over 500 companies.

Where was the problem then? The problem lay in the fact that each system was specific to the company that in a proprietary sense had no standard concept. A hypothetical company in the late 1960s doing business with GM, Sears, and K-Mart therefore needed three different system interfaces.

The story with the grocery industry was different. One EDI historical example is Super Valu, a large American grocery chain. Because they had to first deal with larger "within-the-company" EDI issues, Super Valu recognized early on the need for industry specific standards. They felt that a universal standard was impractical and unnecessary for the technology levels that were available and the extent of their needs.

In the 1970's, several industries sponsored a shared EDI system that they usually turned over to a third party network. In some cases, the shared system was developed by the third party for the group of common companies or industry trade group. Examples of this early sharing include IBM IVANS, which the U.S. property and casualty insurance industry sponsored. Another was ORDERNET, sponsored by the pharmaceutical industry. These industry trade group systems had the same disadvantage as the company proprietary EDI system. They were standard, but limited in scope, and unable to communicate with other trade group EDI systems. ORDERNET, for example, could not communicate with the transportation carrier's EDI system. In 1973, the TDCC decided to develop a set of standards for EDI between companies and to invent a so-called "living standard"-ie: a standard that included standards on how to change the standards! This resulted in the first inter-industry EDI standard in 1975, covering air, motor, ocean, rail, and some banking applications. What evolved included generic formats for general business ANSI X12, first published in 1981; a WINS format for the warehouse industry; and a UCS format for the food and drug industry; and for TDCC. Throughout its history, EDI has encountered many changes to account for the growing needs of the industries in which it is used.

Top of page


The use of standards is required to successfully implement EDI. EDI is very different from e-mail or sharing files through a network or modem. The direct transfer of computer files from one computer to another requires that the computer applications of both trading partners agree upon the format of the document. The sender must use an application that creates a file format identical to your computer application.

What exactly is a standard format? A great example of the use of a standard format is the United Nation’s translation process. In the United Nations, languages are not translated from one to another, rather they are first translated into English and then from English to other languages. This is an example of a real-life standard format.

Before EDI standards were developed and widely used, exchanging data electronically with numerous trading partners was very difficult because of differing document formats. Early electronic interchanges were based on exclusive formats agreed upon by two trading partners. Hypothetically, before national standards, doing business with four different companies would require four different system interfaces.

The first attempt at common data formats was made in the 1960s. These formats were the result of a cooperative effort of different industry groups and were intended primarily for inter-industry use. In the late 1970’s, the American National Standards Institute began developing national EDI standards. In 1979, ANSI created the Accredited Standards Committee (ASC) X12 standard, of which the Data Interchange Standards Association (DISA) is the secretariat. The X12 standard provides specifications of the uniform EDI standards for business documents. It has been widely adopted within the United States, but is currently limited internationally.

The United Nations developed the Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT) standard to fulfill the need for international EDI standards. EDIFACT was accepted by the International Standards Organization in 1987, but is mostly used in European countries today. In the future, ANSI X12 and EDIFACT are predicted to continually align until they are universally compatible.

An EDI message contains a string of data elements, each of which represents a single fact, such as a price. These data elements are separated by delimiters. A delimiter is a character that identifies the beginning or the end of a character string. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set. The transaction set is the EDI unit of transmission, which is the entire EDI message.

Trading partners must agree upon the standards to be used and must specify three main components for the data format. First they must identify unique codes for various data items. UPC codes are an example. Second, they must agree on the meaning of the codes. Finally, trading partners must determine the sequence in which data is to be sent. By establishing these basic rules, trading partners can be certain that information is correctly translated back and forth.

Standards are one of the most important aspects of Electronic Data Interchange. They allow information to be transferred easily and correctly. Also, if a standard is used among all trading partners then, theoretically, the addition of a new trading partner should be simple. Standards for data communication have evolved over the years and will continue to evolve with our changing technologies.

Top of page


There are numerous benefits associated with the implementation of EDI. Some of these include saving time and money, improving data integrity and security, improving customer service, expanding a company’s customer base, and complying with government regulations.

One of EDI’s greatest benefits is its ability to save money. After the initial investment involved in implementing EDI, an EDI system will save a company money in many different ways. First of all, EDI can save a company money by cutting paper costs. The cost of paper alone is a large cost for smaller companies and can be enormous for larger companies. EDI will also save money by eliminating needed labor hours. First of all, since EDI is paperless, there is no need for a mail department to process the business document, and there is no need for a courier to deliver the business document. Also, since an EDI business document is sent directly from computer to computer and is received in a usable format, there is no need to re-key information. EDI is a paper-less process which eliminates all paper along with its processing costs. Nabisco estimates that processing a paper purchase order cost the company $70.00. However, processing an EDI purchase order brought that cost down to $0.93. This is a real-life example of EDI’s huge money-saving abilities. Not only does implementing EDI eliminate many material costs, it can save money in other ways, too. Today, many larger companies offer discounts to trading partners who use EDI.

EDI is a time-saving system. Processes that would traditionally be carried out in several steps, including paper processing and data entry on both ends, can now be completed directly between computers. EDI’s time-saving ability enables companies to use just-in-time inventory programs. Previously, in order to meet a deadline, a company would be required to take into account a document’s physical transfer time. However, using EDI to facilitate a just-in-time inventory program would allow a company to wait until the very last minute before sending a document electronically.

Implementing an EDI system will also improve data integrity. As mentioned earlier, because EDI sends information directly from one computer to another in a useable format there is no need to re-key information. This reduction of human intervention in both re-keying information and handling documents dramatically reduces the overall error rate.

It has been suggested that using EDI also improves data security. EDI provides a more secure transmission of data in comparison to the paper delivery of a business document. With EDI, the information passes directly from one computer to another, eliminating human intervention. Data security is maintained through the use of user identification numbers and passwords. EDI also allows the sender of the data to control the exchange, including knowing when and if the message was received.

Another benefit of EDI is its ability to improve a company’s customer service. With EDI, business documents are transferred immediately, allowing orders to be placed and filled much faster than the traditional paper document method. Also, the reduction in errors allow for less mistakes, which speeds the entire ordering/filling process. Both these factors work to improve customer satisfaction. K-Mart and other retailers have implemented a Vendor Stock Replenishment (VSR) program. VSR sends stock as a customer’s EDI system reports it is necessary and automatically bills the client. It has cut days from the order process and ensures that needed products are always in stock.

EDI will also allow you to expand your customer base. When evaluating a new product to carry or a new supplier to use, the use of EDI can give your company a competitive edge over companies not using EDI. And, in fact, many large manufacturers and retailers today are requiring their trading partners to use EDI.

Use of EDI allows you to comply with government regulations. Use of EDI has become mandatory when doing business with the government. In the Federal Information Processing Standard for Electronic Data Interchange, the United States government committed to using the X12 and the EDIFACT standards in the exchange of business information with trading partners already using EDI. Clinton also signed a memo requiring federal agencies to implement the use of electronic commerce in federal purchases.

Top of page


As with any other system, EDI does involve some risks and disadvantages. These include dependence on trading partners to use EDI, a financial disadvantage for smaller companies, and difficulty to agree on standards.

First of all, for your EDI system to be useful, your trading partners must also have an EDI system. Your company may have one of the best EDI systems available, but if none of your trading partners use EDI then your system is absolutely useless. Also, it is extremely important that your trading partners use their EDI system effectively. For example, suppose your company has just implemented a new EDI system. The system checks your inventory levels daily and sends out requests for inventory to your suppliers nightly. However, your suppliers only check their EDI system weekly. This could cause your store to run under-stocked, hurting your business.

Another downfall to EDI is that larger companies may have an advantage over smaller companies when implementing a new EDI system. Often smaller companies do not have the resources to initially implement EDI as many larger companies do. This could make implementing EDI much more costly for smaller companies. However, the emerging use of the Internet to provide EDI services may prove to be an affordable option for smaller companies wishing to implement EDI.

Finally, perhaps the largest risk in implementing EDI is the fact that it is often difficult to agree on standards. Though there are widely-accepted and widely-used standards, there is no way to force trading partners to accept these standards. There must be a constant cooperation between trading partners in order to develop common rules. Also, even when standards are agreed upon, they must be defined extremely well, or there is still the risk that trading partners will interpret them in different ways.

Although there are some risks associated with the use of EDI, the benefits greatly outweigh these risks. EDI can improve a company’s overall performance levels both within the company itself and amongst its customers. Although risks should be carefully considered, implementing an EDI system should greatly benefit any company no matter what its size, as long as its EDI system and that of its trading partners is used effectively.

Top of page


There are several approaches to EDI implementation. There is not a "best" way, but there are some recommended ways. The following explains one way to implement EDI. The first part of installation is setting up your database. The database contains all the tables with the necessary business data. Examples of database package providers are Oracle, SAP, and Peoplesoft. In this example, we will be using Oracle products. The next piece is the gateway. Oracle provides the EDI Gateway, which allows the user to interact with a command prompt or a GUI interface. The gateway extracts the relevant data from the database for each transaction. For example, if you wanted to create an Outbound Purchase Order, "850", the gateway would pull information such as part numbers, quantity, price, and any relevant information in regards to the trading partner. All code conversions and trading partner definitions are stored in the gateway. At this point in installation, you will need to contact your trading partners and decide on standards, codes, and any other relevant information. All company addresses and contacts should be included in the gateway.

Once the Purchase Order is created, it is then extracted to the translator. There are several options when choosing a translator provider. A few of the top companies are Sterling, Harbinger, and St. Paul Software. If working with Oracle, Sterling is recommended because of their seamless integration with Oracle products. Sterling and Oracle are continuously working together to improve the EDI system.

The translator provides the API mapping and converts the extracted EDI transaction into an accepted standard. The most accepted standard now is ANSI, which uses a numbering convention for the transactions. For example, an "810" is an Inbound Invoice and an "830" is an Outbound Planning Forecast. After the translator stamps the transaction with a standard, the file is ready to be sent to the trading partner. One proven advantage of EDI is that the translator converts the transaction into a standard, which means that companies do not have to have compatible software or vendors in order to work with each other. The translator standard works when sending and receiving EDI transactions.

After the file passes through the translator, there are several ways for transmitting the file to the trading partner. One is to use point-to-point, either over the Internet or FTP. Any FTP software package can be used, and the user logs on as "anonymous". Currently, the most used method is store-and-forward, which utilizes a VAN, a value added network. The VAN acts as a simple post office for the trading partners. The VAN receives the file and holds it until the trading partner dials in to the VAN and asks for any files. A VAN provides more security than the Internet or FTP. There are other reasons why a VAN is preferred over the Internet.

It was clear from the outset that any organization, committed to EDI, would have a requirement to communicate with a large number of different organizations, whether these be suppliers, distributors, banks etc. The function of the VAN therefore was to provide a single channel to facilitate this type of communication.

The VANS support links to their networks for all of the main computer hardware and software operating environments. When you join a VAN you need only be concerned about your link to the network whether it be from a PC, mini, or mainframe computer. What your customers or suppliers use to connect to the network need not concern you at all, as the VAN will take care of all these individual connections to their services.

Until recently, there was a limiting factor, in that there were no connections between networks. As a result, the early development of user communities tended to focus around a particular VAN. If you are in the retail sector the most widely used VAN is the INS TRADANET service, the automotive industry on the other hand developed around the AT&T Easylink network. If your organization had trading partners on different networks you had no option other then to join more than one.

Now all of the networks support interconnections with each other. It is possible, therefore, to join one network and communicate with trading partners on any of the networks via these interconnections. It should be noted, however, that the current nature of these interconnections means that the full end-to-end Audit Trail capabilities of VANS outlined below do not exist when you send data across more than one network.

In addition to providing the benefits of a single communications link to multiple trading partners, VANS fulfill the following functions:


Mailboxing At its core the VAN is essentially an electronic post office. It receives electronic messages, which may be orders, invoices, etc., reads the addressing information contained in the EDI envelope surrounding these messages, and posts them into the mailbox of the recipient.

All of this can be accomplished within a matter of seconds ensuring that critical business documents can be received by trading partners within minutes.


Security Because of the commercial sensitivity of some of the documents transmitted, e.g. invoices, the VANS suppliers have ensured that high levels of security are maintained. Access to VANS services are password controlled and most VANS offer Trading Relationship validation as a means of ensuring that only authorised messages or documents may be transmitted. Therefore, if you wish to send an order electronically to a supplier you will have to specify this in detail and set it up on the VAN. Equally your supplier will have to set up his side of the relationship and thus accept receipt of that order document. Only when matching relationships have been set up will the network allow transmission and receipt of the document by the consenting parties.

In addition to password and trading relationship control, some networks check the integrity of each transmission into their service. This level of checking ensures that the transmission conforms to the mandatory data elements of the EDI standard being used (see the section on EDI Standards). Also if the transmission is incomplete, perhaps due to failure of the communications link, it is usually possible either to re-send the missing data or to re-send the whole transmission. The networks do not allow duplicate transmissions and will therefore automatically discard any of the data, which has previously been delivered to the recipients mailbox.


Audit Control It will be obvious from the above that it is essential for the VANS to provide the end user with a full audit trail, so that users have information at their disposal with which to manage their use of such services. These facilities are now generally available as a function both of the networks themselves and the software packages that are available for connection to the networks. As previously stated, however, detailed end-to-end audit is not available via most of the available network interconnections.

In general, there can be no doubt that the overall levels of security maintained by the VAN operators is very high and that sending important business documents electronically is much more secure than using paper based systems.

The following are EDI software selection factors.


Ease of upgrade: As an EDI trading relationship matures there is likely to be a requirement for enhancement of the existing system. This may arise as a result of additional messages, changes to existing messages or standards, addition of new trading partners and their individual messaging requirements, inclusion of additional network connections or an increase in the number of business applications to be integrated.


Network connectivity: Some EDI software packages are restrictive since they do not allow users to be connected to all of the major EDI networks. This is the exception to the rule since most of the popular packages have multi-network connectivity.

Multi-standards capability: In cases where a supplier is faced with a situation in which two or more trading partners require EDI messages to be transmitted using different standards the software must be able to accommodate this need.


Print/report generator: Many SMEs will not be integrating their EDI application with their in-house systems and will require a hard copy print of any incoming EDI messages. This facility must be available on the software under consideration.

After implementing EDI, it is important to join a user group, which will allow you to access other companies using EDI. Oracle provides a user group entitled EDI SIG. It is important to select a user group that is familiar with the products that you are using. Even though most companies will guarantee product support, it may sometimes be easier to access help from other companies who might have experienced the same problem.

The diagram at the end of this report (page 20) provides a visual example of how the above implementation works.

Top of page


Where is EDI going? It is possible that there might be a day when a business will refuse to serve others because they do not participate in EDI. EDI is becoming a crucial part of everyday business activities. Trading partners are offering discounts to their customers if they convert to EDI. EDI is so convenient that it saves both participants money. It is also convenient that neither one of the trading partners are required to use the same software for their everyday business transactions. The translator is responsible for converting the transaction into the standard, which makes setting up EDI even easier.

The question of whether to use a VAN or the Internet depends on several factors. The VAN provides more security than the Internet. On the other hand, the Internet is cheaper and faster. Some VAN providers charge for each file that is stored in the VAN and sometimes for the length that it remains there. The combination of both the Internet and a VAN might be ideal in the future. Depending on which company you are trading with, using a VAN for larger quantities of transactions would be good. Using the Internet for quick transactions would prove beneficial.

EDI will continue to improve in the future. Currently there are two main standards as mentioned above. There is a possibility of creating another EDI standard that is used along with a mark-up language. XML/EDI provides a standard framework to exchange different types of data. For example, an invoice, healthcare claim, or project status can be in a transaction format, which is exchanged via an Application Program Interface (API), web automation, database portal, catalog, a workflow document, or message. It can also be searched, decoded, manipulated, and displayed consistently and correctly by first implementing EDI dictionaries and extending vocabulary via on-line repositories to include business language, rules, and objects. Thus, by combining XML and EDI, a new powerful paradigm is created that is different from XML or EDI. In the future, it is possible that there will be one standard for everyone to use, even from an international standpoint. API mapping will be simpler, and all the pieces including the database, gateway, and translator will all be included in one package. Trading partners will be able to provide a file that will populate their other trading partners’ databases in order to complete code conversions. If this is possible, installing EDI will be much easier. With all of the advances in technology, and with companies competing for the lead in the industry, there will soon be a complete seamless integration to EDI.

Top of page

back.gif (2329 bytes)