EDI (Electronic Data Interchange) is the automated exchange of business documents such as purchase orders, despatch advices and invoices between companies' systems in an agreed standard format, with no retyping. Instead of someone keying an emailed order into your ERP, your customer's system sends it straight to yours; the confirmation, shipping notice and invoice travel back the same way.
Which sectors and businesses need EDI?
EDI is common wherever large buyers deal with many suppliers: retail and FMCG, automotive, logistics and foreign trade, and pharmaceutical and medical distribution. In most manufacturers, wholesalers and distributors, the starting picture looks familiar. A large customer emails its order as a PDF or spreadsheet, someone in sales support types each line into the ERP, and the confirmation goes back by email. At shipping time, the same details are entered again: on the delivery note, on the labels and in the customer's supplier portal.
That works while you have a handful of customers ordering now and then. As accounts grow, two things happen: order frequency climbs, and one day a customer writes, "From next quarter, we'll send orders via EDI." That sentence is rarely a polite request. It is usually a condition of staying on the approved supplier list.
The workload is only half the problem. Every line copied by hand is a chance for a typo, a delay or a missed revision. We cover disconnected systems in general in our guide to API integration; EDI is the same problem between companies, solved with a shared, standardised language.
What is EDI and how does it work?
It helps to think of EDI in three layers: the document, the format and the transport. The document is the business event: an order, an order response, a shipping notice, an invoice. The format is how that document is written so a machine can read it, and the transport is how the file gets safely from one company to the other.
A typical flow runs like this. Your customer's ERP raises a purchase order, a translator converts it into a standard EDI message, and the message is sent over the agreed channel. On your side, the translator reads the message, maps each field to your own customer, item and price codes, and creates the sales order; an automatic acknowledgement goes back and nobody opens a PDF.
That mapping step is where most of the effort in any EDI project goes. Your customer's part number rarely matches your stock code, and their units of measure rarely match yours. This is why EDI struggles without a clean master data management discipline behind it.
The common standards and messages
Two families dominate. UN/EDIFACT, maintained under the United Nations, is the norm across Europe and Türkiye, while ANSI X12 dominates North America. Alongside them sit XML-based formats and industry subsets such as VDA in automotive or GS1 EANCOM in retail.
| Business document | EDIFACT message | X12 equivalent | Direction |
|---|---|---|---|
| Purchase order | ORDERS | 850 | Customer → supplier |
| Order response | ORDRSP | 855 | Supplier → customer |
| Despatch advice (ASN) | DESADV | 856 | Supplier → customer |
| Invoice | INVOIC | 810 | Supplier → customer |
| Delivery schedule | DELFOR | 830 | Customer → supplier |
| Stock and sales report | INVRPT / SLSRPT | 846 / 852 | Retailer → supplier |
On the transport side, the usual options are AS2 (encrypted, signed delivery over the internet with a receipt), SFTP, OFTP2 in European automotive, and VANs, the value-added networks that deliver messages on your behalf. In practice, your largest trading partner usually decides which one you use.
EDI vs API, e-invoicing and supplier portals
"Isn't EDI old technology? Won't an API do?" is a fair question. The short answer is that they do different jobs. An API works in real time, request and response, and is normally designed around one software vendor's rules; EDI is a batch, document-based business language shared by a large community of companies.
| Criterion | EDI | API | Turkish e-Invoice (UBL-TR) | Supplier portal |
|---|---|---|---|---|
| Purpose | Business documents between firms | Live data between systems | Tax-compliant invoice | Entering data on the customer's screen |
| Standard | EDIFACT, X12, industry subsets | Vendor-specific (REST, JSON) | Set by the Revenue Administration | Customer-specific |
| Automation | Full, system to system | Full, system to system | Full via an integrator or direct link; manual on the portal | Low, manual entry |
| Who decides? | Usually the large customer | The software vendor | The tax authority | The customer |
| Typical use | Orders, ASNs, schedules | Stock, prices, parcel tracking | Statutory invoices | Low-volume suppliers |
Türkiye adds a local twist. For taxpayers within the scope set by the Revenue Administration (GİB), domestic invoices and delivery notes already have to be issued electronically in a structured format, handled through e-invoice integration and the e-Waybill scheme. EDI covers what sits before and around those statutory documents: the order, the confirmation, the schedule, the shipping notice and a foreign customer's own invoice message.
The cost of staying manual
Selling through electronic channels is spreading in Türkiye. According to TÜİK's 2026 ICT Usage in Enterprises survey, the share of enterprises selling via the internet or EDI rose from 13.6% in 2024 to 17.1% in 2025. Among firms with 250 or more employees, it reached 29.7%. The indicator includes web sales, so it does not measure EDI alone, but it does show order traffic shifting to electronic channels.
The tax side shows that structured document exchange is already mainstream:
According to the Revenue Administration's 2025 Annual Report, at the end of 2025 some 1,848,492 taxpayers issued e-invoices through private integrators and 86,828 through the GİB Portal, while only 1,988 had connected their own systems directly to GİB.
There is a useful lesson in that split: the vast majority of firms hand the outside connection to an intermediary rather than build it themselves, and EDI is usually no different. The real work lies in wiring that intermediary cleanly into your ERP.
Standards keep moving, too. According to VDA's publication page for "VDA 4987 – Despatch Advice with EDI V3.1", version 3.1 of the EDIFACT DESADV-based despatch advice recommendation was published on 18 July 2023 and replaces the legacy VDA 4913 message. A supplier still working by hand or with old flat files has little time to adapt once a customer makes the switch mandatory; our automotive EDI integration guide covers that sector in depth.
The hidden costs are scattered: staff hours spent keying orders, wrong shipments caused by a miscoded line, revisions spotted too late and a slipping score on the customer's supplier scorecard. None arrives as a single bill, but all of them come out of margin.
A 7-step framework for adopting EDI
Whatever your sector, a sound EDI project follows roughly this order:
- List your partners and messages. Which customer or supplier wants which document, in which standard and version, over which channel? Collect each partner's implementation guide.
- Choose a transport model. Will you run your own AS2 or SFTP connection, or use a VAN or managed EDI provider? The number of partners and your in-house capacity drive the decision.
- Clean your master data. Customer part numbers mapped to stock codes, units, delivery locations (GLNs) and tax IDs should live in one table. Dirty data turns EDI into an automatic error generator.
- Write the mapping and business rules. Document the ERP target of every message field, the mandatory fields and the exceptions: missing price, unknown item, partial shipment.
- Pilot with one partner. Start with your highest-volume or most demanding partner, test end to end with real messages and get their sign-off.
- Build monitoring and an error queue. Every rejected, unmapped or unacknowledged message must land on someone's screen. An order that silently disappears is more dangerous than one typed in by hand.
- Roll out and secure it. Add partners from the same template, and track certificate renewals, access rights and partners' security expectations with the same rigour as a third-party security assessment.
Are you ready? A quick checklist
| Question | If yes | If no |
|---|---|---|
| Are item and customer codes unique in your ERP? | Move on to mapping | Clean the data first |
| Has the customer shared its implementation guide? | Confirm message scope | Ask for it |
| Can your ERP accept orders from an external system? | Integrate directly | Middleware or an ERP review |
| Is shipping done with barcode scanning? | ASNs can be generated automatically | A warehouse management system comes into play |
| Is someone named to watch error messages? | Go live | Assign ownership first |
How Digital Bridge delivers EDI integration
We don't sell off-the-shelf packages; every EDI engagement starts with discovery and a needs analysis. In the first sessions we map your trading partners, their implementation guides, your ERP's ability to accept external data and the screens an order passes through today. The outcome is a written proposal setting out scope, phases and fees.
On the technical side, we build the bridge between the EDI translator and your ERP as part of our API integration service. If your ERP cannot take external orders directly, our system integration team designs the middleware, message queue and error screen. Where the ERP itself lacks order, pricing or shipping fields, our ERP development work fills the gap.
Our aim is for every order to land in one order structure in your ERP, whichever channel it came through. Smaller customers who will never run EDI can order through a B2B e-commerce and dealer portal connected to the same ERP flow, so orders from EDI and the portal are tracked on the same screen; the design behind that is explained in our B2B e-commerce ERP integration article.
For logistics and trading firms, EDI is also part of the container and paperwork chain, which we cover in port logistics document digitalisation.
Whether to buy a packaged EDI tool or build a tailored integration is a judgement we weigh using the criteria in our custom vs off-the-shelf software guide. For more on this topic, browse our software development guides.
Next step: pin down your EDI requirements
If a customer has asked for EDI, or order entry is eating your team's week, the right first move is a partner and message inventory. Share your customer's implementation guide and the name of your ERP, and we'll work out together what can connect directly and what needs middleware.
Get in touch through our contact page, on +90 552 380 25 25, or at info@digitalbridge.com.tr.