EDI
Also: Electronic Data Interchange · electronic data exchange
EDI is the automated exchange of structured business data between IT systems. Orders, despatch advices or invoice data are transmitted in an agreed, machine-readable format and can be processed further without being re-entered by hand.
What it is
EDI stands for "Electronic Data Interchange". What matters is that the transmitted data is structured: an invoice sent as a PDF by email is electronic, but its contents are not automatically available as individual data fields. With EDI it is unambiguously defined which information sits where and how it is to be interpreted.
An EDI process usually involves three distinct layers. First the data format, for example EDIFACT, ANSI X12, XML or another structured format. Second the transmission method, such as AS2, OFTP2, SFTP or a platform. Third the mapping, meaning the correspondence between the trading partner's fields and the fields of your own ERP, TMS or warehouse management system.
There are also WebEDI solutions. Here a trading partner provides a portal in which data is entered or confirmed manually. This produces structured data for the operator; on the supplier's or service provider's side a manual step remains.
In practice
The main benefit of EDI lies in end-to-end processes, less manual data entry and better traceability. Data is taken from the originating system instead of being typed in again. That reduces the risk of transcription errors and makes processes less dependent on individual people.
The master-data effort is frequently underestimated. Customer article numbers have to be mapped to your own, units of measure have to match, and depending on the process, prices, delivery locations or further references need to be reconciled. The technical transmission is therefore often only one part of the project.
Defined error handling matters just as much. What happens with an unknown article number, an implausible quantity or a formally invalid message? We design connections so that such cases are logged traceably and presented for review, rather than being silently discarded or interpreted automatically.
When it affects you
A common trigger is a specific EDI requirement from a customer or supplier, often tied to a deadline and to prescribed message types. A second is transaction volume: where data is regularly moved between two systems by hand, it is worth examining whether that break in the chain can be automated.
Organisational dependencies play a role too. If a process only works because particular employees know the necessary mappings and special cases, a structured interface can capture that knowledge within the process itself.
Getting started does not require digitising the entire process chain at once. In many projects it makes sense to begin with one trading partner and one clearly bounded message type, then extend the connection step by step.