Electronic Data Interchange (EDI)

What is EDI

EDI (Electronic Data Interchange) is a standard created for businesses to exchange documents. It is designed for machine-to-machine, not as a human-readable format, to exchange purchase orders, invoices, shipping notices, and any type of follow-up document required by the business. This was traditionally done over email, or a different kind of human-initiated communication, which you can already guess is inefficient and prone to error.

Smaller companies are still doing it this way, or the companies that do not handle too much paperwork to support their business. Still, once you get into the serious document exchange, you quickly become inefficient and “choke” the delivery to support bureaucracy. I bet you can all give an example when you “lost it” with the different kinds of companies looking for your warranty, invoice, order, or lost goods in transport. Now you can understand why.

The EDI format is supposed to replace manual correspondence with structured, machine-readable data, all of which is standardized. As usual, it’s easy to say but hard to achieve.

Standard vs Blueprint

If the EDI is standardized, what is the problem then? Although EDI uses official standards (with some weird numbers, each company implements them slightly differently. And here you see the issue.

The common misconception is that if it is a standard, it must be identical everywhere. Not really, it is a STANDARD, but not the BLUEPRINT!

Think of it like ISO 9001 standard. It is a standard with well-defined requirements, but each company can design its own implementation guide to meet them. Similary, EDI standards define the structure, but each business defines its implementation.

FedEx and UPS are two of the largest logistics companies in the world, and both use EDI (Electronic Data Interchange) to manage their operations. However, their EDI implementations differ.

Theory vs Practice

What We Expect

In theory, all the relevant parties (two or more companies doing business together) use the same standard that EDI provides. It gives the flexibility to choose what to use, and the data has some standard and predictable schema that can be validated and used for the data mapping. In theory, Company A can parse the document from Company B in the same way they are parsing documents from companies C, D, and E. What a beautiful world to live in. Onboarding new business partners is a walk in the park. We only have to agree on a data exchange channel, and the business is on. Yes, but in theory.

What We Get

In practice, we have something that none of the newcomers imagine as a standard when they are first introduced to EDI. This standard has existed for many years and has evolved, so many companies use different standard versions for starters. If it is only the version, that would not be a problem, that’s why “for starters.” The more significant issue is that the standard is so flexible that the companies can choose which fields to use, which to omit, and which validation is required.

Case Study: EDI in Logistics

How Logistic Companies Cooperate

Imagine two logistics companies doing business together. We will name them Company A and Company B for the sake of the example. They cooperate to deliver packages worldwide, but one company covers 1/2 of the world, and another covers another 1/3 of the world. The idea is to pass the parcel on to another company and let them handle the delivery in their area, so we do not reject customers who want to use our service. It’s the strategy to keep them tied to us. Now, we will use EDI to provide the partner company with information about the destination, size, weight, and all other relevant info.

Similarly, they will send us an invoice for the service they did on our behalf and the packages that need to be delivered to the area where we operate. Again, we need to send them the invoice for our services. The business exchanges thousands and millions of packages over the year, so tracking them all down manually would be impossible.

Data Exchange

The practical issue here is that they use different fields and validations and customize the documents according to their needs. For example, one company can use CODE=01 for the shipped packages, while another can use the same CODE for the received packages. We must customize the mapping to their standard and integrate them into our system. The same applies to their team. Let’s not mention localization issues (not the language), with the different accounting rules and taxes the government may require for goods to pass customs.

Scaling the Problem

Suppose we have finally integrated those two companies. We have a new opportunity to expand to the rest of the world that we don’t cover by signing similar contracts with Company C. Perfect, let’s integrate our EDI. Imagine the developers’ surprise when they realize that the company C is using something completely different regarding validations and field definitions. So, they implemented another mapping. They also need to send company B tracking information about the package when using their services, but company B does not integrate with Company C. There goes another implementation and service to maintain.

At some point, there is a company D that company B is using for the deliveries as a subcontractor, and they want them to send the information about the delivery or tracking information directly to company A… you get the point.

Imagine this with 100s of businesses working together, and it will become clear how Stedi raised 100 million dollars in venture capital.

Real Word example of the data Exchange

EDI (Electronic Data Interchange) is widely used by major logistics companies to streamline and manage their operations. Although many companies adopt EDI as a standard, each logistics provider has its own specific implementation tailored to their operational needs and infrastructure.

For example, consider a shipment process handled by a large logistics company operating extensively within North America. When a shipment is scheduled from Chicago to Dallas, the company’s system initiates an EDI 204 (Motor Carrier Load Tender) transaction. This document electronically informs the carrier about the details of the shipment, including pickup and delivery locations, expected dates, and cargo information.

Upon receiving the load tender, the carrier sends back an EDI 990 (Response to a Load Tender) to confirm their acceptance or rejection of the shipment. Once the cargo is physically loaded onto the truck, the carrier sends an EDI 214 (Transportation Carrier Shipment Status Message), updating the logistics provider about the shipment’s progress at key points such as: departure from Chicago, transit through Memphis, and arrival in Dallas.

Finally, after the delivery in Dallas, an EDI 210 (Motor Carrier Freight Invoice) is transmitted electronically by the carrier to the logistics provider, detailing charges and enabling financial reconciliation.

Although the basic structure of these transactions remains consistent across the logistics industry, the precise implementation and handling of these EDI documents can vary significantly from one company to another, influenced by their internal workflows, technology infrastructure, and customer-specific requirements.