Integration

EDI for SMEs: Connecting to Retail Chains

EDI for SMEs: message types ORDERS, DESADV, INVOIC, GLN/GTIN, converter vs. provider, costs and pitfalls when connecting to retail chains.

Fabian17. August 20268 min read
edi for smesedifactretail chainsgtinb2bintegration

First things first: EDI (Electronic Data Interchange) is the automated, standardized exchange of business documents – orders, dispatch advices, invoices – directly between two companies' ERP systems. For SMEs, EDI becomes a must above all when you supply large retail chains or industrial customers: they expect documents in a fixed format, not a PDF or paper. This guide covers the key message types, converter versus EDI provider, the role of GLN and GTIN – and what the connection realistically costs.

Why EDI is not a nice-to-have for SMEs

As a supplier trying to join a large retail chain's range, the rules are usually dictated to you. Orders don't arrive by email but as a structured EDI message straight into the system; deliveries must be announced electronically and invoices transmitted in the agreed format. Without a working EDI connection you often simply won't be listed – or face deductions when documents don't arrive cleanly.

The benefit runs both ways: your data lands directly in the partner's inventory system without manual entry, and you stop re-keying orders. This reduces errors, speeds up order processing and makes the collaboration scalable. EDI is therefore less an IT project than a basic prerequisite for B2B trade with larger partners.

For context: EDI is a specialized interface. Unlike an open REST API it is highly standardized for document exchange between partners, which makes it more rigid and harder to onboard.

The key EDI message types

The most widely used international EDI standard is EDIFACT (UN/EDIFACT). It defines fixed message types for each document category. For trade with retail chains, three matter in particular, mapping the classic order-to-cash flow.

ORDERS – the purchase order

The ORDERS message is the trading partner's electronic purchase order to you. It contains line items, quantities, requested delivery dates and the ID numbers of articles and locations. From an incoming ORDERS, your ERP ideally creates a sales order automatically, with no re-keying. It is often followed by an ORDRSP (order response) back to the partner.

DESADV – the dispatch advice

The DESADV (Despatch Advice) is the electronic delivery notification. It tells the trading partner what you will deliver, when, and in which packaging structure – often linked to an SSCC code on the shipping label that goods-in scans. A correct DESADV is mandatory at many chains: if it's missing or doesn't match the goods, you risk complaints or contractual penalties.

INVOIC – the invoice

The INVOIC is the electronic invoice. It transmits invoice data in structured form into the recipient's system, replacing the paper or PDF document. But note: an EDIFACT INVOIC is not automatically a legally compliant e-invoice in the German sense. For the B2B e-invoicing obligation, a format compliant with EN 16931 is decisive – more below.

Beyond these are dozens of further message types (such as PRICAT for price lists or SLSRPT for sell-out data). To get started, ORDERS, DESADV and INVOIC are usually all you need.

GLN and GTIN: the ID numbers behind EDI

EDI only works if both sides speak the same language for locations and articles. Standardized GS1 numbers provide it.

  • GLN (Global Location Number): uniquely identifies a business partner or location – the central warehouse, an individual store or the billing address. In the ORDERS, this pins down exactly where to deliver and where to invoice.
  • GTIN (Global Trade Item Number): uniquely identifies an article. The GTIN is the successor to the EAN and sits in every retail barcode. Without a correct GTIN, the trading partner can't match your goods.

In practice: before the first EDI document flows, your master data has to be clean. Every article needs its GTIN, every partner location its GLN, and both must match the partner's data exactly. Poor data quality is the most common reason EDI projects stall during testing.

Converter or EDI provider? The two paths to a connection

Raw EDIFACT messages are practically unreadable for humans and initially foreign to your ERP. Between your system and the partner's format, you therefore need a translation and transmission layer. There are two fundamental approaches.

Your own converter (in-house EDI)

With your own converter you run the EDI software yourself – on-premise or in your cloud. It translates between EDIFACT and your ERP's internal data format (the field mapping); transmission runs via protocols like AS2, OFTP2 or SFTP directly to the partners.

  • Strengths: full control, no transaction-based fees, deep integration possible.
  • Limits: you need EDI know-how in-house and handle every new partner, format maintenance and operations yourself. For most SMEs, this only pays off at very high document volumes.

EDI provider (managed/web EDI)

An EDI provider (also EDI service provider or clearing centre) handles conversion and transmission as a service. You send data in a simple format, it converts that into the respective partner format and delivers it – and vice versa. For smaller volumes, web-EDI portals let you edit documents in the browser, without your own ERP connection.

  • Strengths: little in-house know-how needed, the provider knows the chains' format quirks, fast onboarding of new partners.
  • Limits: ongoing costs depending on the model (base fee plus transaction or per-partner charges), dependency on the service provider.

For SMEs, the provider route is usually the more pragmatic entry point. Many cloud ERPs ship with ready-made connectors or EDI-provider partnerships for exactly this. Which EDI and middleware options a system supports out of the box is visible in the ERP directory and the comparison – enterprise suites like SAP S/4HANA Cloud or Dynamics 365 Business Central bring extensive EDI ecosystems, while cloud-native systems like xentral often handle EDI via connected providers.

Connecting to a retail chain step by step

Every chain has its own requirements, but the process is similar. A typical EDI onboarding looks like this:

StepWhat happensWhat to watch
1. Clarify requirementsChain provides EDI guideline and message specWhich types (ORDERS/DESADV/INVOIC)? Which protocol?
2. Prepare master dataReconcile GLN per location, GTIN per articleExact match with partner data
3. Set up mappingConnect fields between ERP and partner formatMap tax rates, units, prices correctly
4. Test phaseExchange test documents and have them checkedChain gives formal go before live operation starts
5. Go-live & monitoringProduction operation, error notificationsMonitor acknowledgements (CONTRL)

For an initial onboarding, realistically plan several weeks – the bottleneck is rarely the technology but the data preparation and the partner's sign-off. If you don't want to tackle EDI alone, structured support with ERP integration coordinates mapping, testing and operations.

Weighing costs and benefits realistically

There are no flat-rate prices – they depend on the connection type, volume and number of partners. Think in three cost blocks:

  • Setup (one-off): mapping, testing and onboarding per partner. The effort rises with the number of retail chains, because each has its own guidelines.
  • Ongoing operation: with a provider, base fee plus transaction or per-partner charges; with your own converter, licence, maintenance and staff.
  • Internal effort: master data maintenance, monitoring, error handling – often underestimated.

Against this stand concrete benefits: no manual order entry, fewer mis-postings and complaints, faster throughput and – often decisive – the very ability to get listed with large customers. For a solid calculation, weigh annual document volumes and the entry time saved against setup and operating costs. At high, recurring volumes, EDI usually pays for itself quickly.

Common pitfalls – and how to avoid them

A few stumbling blocks recur in practice:

  • Messy master data: wrong or missing GTIN/GLN are the number-one source of errors. Clean up before the project starts.
  • DESADV doesn't match the delivery: if the advice deviates from the actual goods, contractual penalties loom. Warehouse and shipping must generate the data cleanly.
  • Format quirks per chain: "EDIFACT" is not always EDIFACT – every chain interprets fields slightly differently. This is exactly where a provider helps.
  • Confusing EDI with e-invoicing: an EDIFACT INVOIC does not automatically satisfy the German B2B e-invoicing obligation. What matters is a structured format compliant with EN 16931, such as XRechnung or ZUGFeRD. Legally, the obligation to receive B2B e-invoices has applied since 1 January 2025. The obligation to issue them is staggered – in principle from 1 January 2027 for companies above €800,000 in prior-year revenue, and from 1 January 2028 for everyone else. When in doubt, ask your tax advisor how your ERP maps both worlds.
  • No monitoring: EDI runs in the background – until a message fails. Without monitoring the acknowledgements, you only notice when the customer complains.

Conclusion

EDI is not an end in itself for SMEs but the entry ticket into supply relationships with large retail chains and industrial customers. Whoever masters the three core messages ORDERS, DESADV and INVOIC, keeps GLN and GTIN master data clean and picks the right path between an own converter and a provider builds a stable foundation. The most common reason projects fail is not the technology but poor data quality and underestimated operational effort. And don't forget: EDI and legally compliant e-invoicing are two separate tasks your ERP ideally covers cleanly.

Fabian

Fabian

ERP Consultant & E-Commerce Practitioner

After building our own logistics business (€3.5M revenue, around €35M in customer volume processed digitally), we now advise SMEs on ERP selection, implementation and integration — vendor-neutral. Practitioner knowledge, not theory.

10+ years of ERP & e-commerce practiceRollouts across multiple ERP systems
More about us

Questions about this topic? We're happy to help — free of charge and without obligation.

Book a free consultation

Questions about this topic?

We're happy to help — free of charge and without obligation. Let's find out in a short call which ERP and which path fits you best.