EDI (Electronic Data Interchange)
EDI (Electronic Data Interchange) is the automated, structured exchange of business documents – such as purchase orders, dispatch advices and invoices – directly between the IT systems of two companies, without anyone re-keying documents or sending them by email.
EDI (Electronic Data Interchange) is the automated exchange of business documents in a standardized, machine-readable format directly between the IT systems of two companies. Instead of sending a purchase order as a PDF by email that the recipient re-types into their ERP by hand, EDI transfers the same order as a structured data set that the target system reads in and processes further without human intervention. Typical EDI documents are purchase orders, order confirmations, dispatch advices, invoices and inventory reports.
The core idea of EDI is to avoid media breaks: because sender and recipient have agreed on a common message format and fixed field meanings, one company’s software can understand the other’s data directly. EDI is therefore older than today’s web and yet highly relevant – in trade with large retail chains, in the automotive industry and in logistics, an EDI connection is often the basic prerequisite for becoming a supplier at all.
At a glance
- EDI = automated exchange of structured business documents between company IT systems
- Typical documents: purchase order, order confirmation, dispatch advice, invoice, inventory report
- Most-used standards: UN/EDIFACT (worldwide), ANSI X12 (USA), VDA (automotive, DACH)
- Goal: no re-keying, no media breaks, fewer errors, faster throughput times
- Often a mandatory prerequisite for becoming a supplier to large retail chains or OEMs
How EDI (Electronic Data Interchange) works
EDI replaces the paper or email document with a standardized message. So that two systems understand each other, every document is translated into a defined format in which each piece of information – item number, quantity, price, delivery address – sits in a precisely defined place. This translation is handled by a so-called converter or an EDI subsystem: it transforms the ERP’s internal data into the agreed EDI format (outbound) and incoming EDI messages back into the format of the company’s own ERP (inbound).
The messages are transported over defined communication channels, such as AS2, OFTP2, SFTP or a value-added network (VAN). Many mid-sized companies do not operate this infrastructure themselves but use an EDI service provider or an EDI clearing center that sits as an intermediary between the partners, converts formats and monitors delivery.
Message standards: EDIFACT, ANSI X12 and VDA
The most widely used standard worldwide is UN/EDIFACT, maintained by UN/CEFACT. It defines message types such as ORDERS (purchase order), ORDRSP (order confirmation), DESADV (dispatch advice) and INVOIC (invoice). In the USA, ANSI X12 dominates instead. In the DACH automotive industry, the VDA messages and industry-specific EDIFACT subsets such as ODETTE or VDA 4938 are additionally common.
Because there is room for interpretation even within a single standard, large trading partners usually define their own message profile (“Message Implementation Guideline”) that prescribes exactly which fields are to be filled and how. A new EDI connection therefore almost always begins with reconciling these specifications.
EDI in the ERP system
In EDI, the ERP system is the central data source and sink. An incoming EDI purchase order is created directly as a customer order, an incoming dispatch advice generates an expected goods receipt, an incoming EDI invoice moves into accounts payable. Conversely, the ERP triggers outgoing messages: as soon as an order is confirmed or goods are shipped, it automatically generates the matching ORDRSP or DESADV.
For this coupling, the ERP needs either an integrated EDI module or a connection to EDI middleware via an interface or API. A prerequisite for clean EDI is well-maintained master data: item numbers, GTIN/EAN and partner identifications must be mapped unambiguously between the systems, otherwise automatic processing fails. That is precisely why a clean field mapping between the EDI fields and the ERP fields is the most demanding part of every EDI project.
Why EDI matters: benefits and relevance
The main benefit of EDI is the automation of recurring document processes. Where employees used to re-key purchase orders and reconcile invoices, the data now flows through without manual intervention – this lowers error rates, saves staff time and significantly shortens the throughput time from order to delivery. With high document volumes, for instance in trade with large chains, EDI is often the only economically viable solution.
There is also the access aspect: many retail groups, automotive manufacturers and logistics providers accept suppliers only with a working EDI connection. For these companies, EDI is not an efficiency bonus but a hard business condition. Anyone who does not provide the connection is not listed as a supplier.
Distinction: EDI vs. API and e-invoicing
EDI is frequently confused with other forms of integration. An API is a flexible, often web-based connection point through which two systems exchange data in real time – ideal for coupling an ERP with a shop, payment or shipping. EDI, by contrast, is more strongly standardized, batch- and document-oriented and designed for B2B communication between companies with fixed trading relationships. In practice, both exist side by side: web APIs for the dynamic e-commerce world, EDI for the standardized document exchange with large partners.
There is also a close but not identical relationship with the e-invoice. The EDI message INVOIC is a recognized electronic invoice format, but the modern e-invoice under the EN 16931 standard relies more on XML-based formats such as ZUGFeRD and XRechnung as well as transport channels like Peppol. EDI and e-invoicing overlap in their goal – structured, machine-readable invoices – but differ in format and regulatory background.
EDI, EDIFACT and data format
It is important to separate concept and format: EDI denotes the principle of electronic data interchange, while EDIFACT is one of the concrete data formats in which EDI messages are expressed. A company can therefore run EDI via EDIFACT, via ANSI X12 or via XML-based formats – the concept stays the same, only the syntax of the transmitted message changes.
DACH specifics and typical pitfalls
In the DACH region, the automotive industry above all shapes the EDI landscape: VDA and ODETTE messages with delivery schedule and just-in-time call-off logic (DELFOR, DELJIT) are standard here and go far beyond the simple purchase order. In the food and consumer goods trade, by contrast, GS1-based EDIFACT subsets such as EANCOM dominate, closely interlinked with GTIN/EAN item identification.
The most common pitfall in EDI projects is not the technology but data quality and mapping. If the internal item number deviates from the GTIN stored at the partner, or mandatory fields from their message profile are missing, messages are rejected. An EDI project should therefore clean up master data early, examine the partner profile closely and secure the connection with test messages before live operation starts.
Example
Example: connecting a supplier to a retail chain via EDI
A mid-sized manufacturer of household goods wants to supply a large drugstore chain. The chain makes the EDI connection a condition: purchase orders will in future arrive exclusively as EDIFACT ORDERS, the dispatch advice must come back as a DESADV with pallet labeling, and the invoice as an INVOIC.
The manufacturer brings in an EDI service provider that mediates between the ERP and the retail chain. When an ORDERS purchase order arrives, the provider converts it and hands it over to the ERP, which automatically creates a customer order. After shipping, the ERP generates the dispatch advice, the provider converts it into a DESADV and delivers it to the chain. Where two employees used to maintain purchase orders and delivery papers by hand, the entire document flow now runs automatically – with a significantly lower error rate.
Frequently asked questions
Matching ERP systems
Related services
Questions about EDI (Electronic Data Interchange) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.