EDI (Electronic Data Interchange) is the standardised electronic exchange of structured business documents – such as orders, despatch advices and invoices – directly between the IT systems of business partners. Common standards include UN/EDIFACT in Europe and ANSI X12 in North America.
EDI replaces paper, fax and PDF attachments in business transactions: orders, delivery notes and invoices travel as rigidly structured data records directly from computer to computer. Think of a standardised form that sender and recipient systems fill in and read out automatically – with no retyping at all.
Why do I need EDI?
Business between companies generates many similar documents every day: orders, order confirmations, despatch advices, invoices. If these are exchanged by e-mail or fax, someone on each side has to capture the data manually – slow and error-prone. EDI automates this document flow completely: the customer's ERP system generates an order as an EDIFACT message of type ORDERS, the supplier's system processes it without human intervention and responds with a despatch advice (DESADV) and an invoice (INVOIC), for example.
Many large retail chains, industrial companies and automotive manufacturers frequently require EDI capability from their suppliers. If you want to be listed there, the topic is usually unavoidable.
Practical relevance for shop owners
EDI becomes relevant above all in B2B e-commerce: when business customers want to send orders directly from their own procurement systems, or when you want to connect wholesalers and manufacturers in an automated way. Technically, EDI docks onto the ERP or merchandise management system via a converter that translates between EDI messages and internal data formats – a classic case for an ERP integration. E-invoicing is closely related in content: formats such as XRechnung and ZUGFeRD structure invoice data in a similarly machine-readable way, but are independent standards with their own rules.
Typical mistakes in EDI projects
EDI projects rarely fail because of the technology itself, but because of coordination details:
- Partner specifications underestimated: Many business partners use their own EDIFACT subsets with individual mandatory fields – one mapping rarely fits all.
- Mapping errors: If EDI segments are mapped to the wrong ERP fields, faulty orders or invoices are the result.
- Acknowledgements not evaluated: Confirmation and error messages such as CONTRL or APERAK go unread – transmission errors then surface too late.
- Weak master data: Missing or incorrect GLN numbers and product mappings cause matching problems on the partner side.
- Test phase too short: Without thorough tests with each partner, edge cases such as partial deliveries only go wrong in live operation.
What to look out for
Clarify early on which message types and subsets your partners actually require, and plan a dedicated test and acceptance phase per partner. Strategically, the question is whether to run your own EDI converter or use a specialised EDI service provider (clearing centre) – the latter usually reduces your own operational effort but creates an additional dependency. For smaller partners without EDI infrastructure, a REST API or a web portal can be a useful complement. Our integrations overview shows the connections we implement.
Under certain conditions, the German B2B e-invoicing rules continue to permit EDI procedures, provided the required invoice data can be extracted correctly. You should clarify the details for your individual case with your tax advisor.