EDI with a large retailer: no EDI, no customer

You have a product, a first buyer and a delivery date. And then it turns out the biggest unknown in your whole system project is not your accounting, not your stock and not your webshop, but three letters: EDI. Anyone who wants to supply a large supermarket chain soon discovers that electronic message exchange is not a wish but an entry requirement. No EDI, no customer. This is how it works, why there is no generic EDI connection, and why you start here.

It is not a feature, it is an entry requirement

With most system questions you get to choose. Want a webshop? Want project administration? Fine, we will switch it on. EDI works differently. A large retailer exchanges its orders, despatch advices and invoices electronically following the GS1 standard, and expects you to connect to it. If you do not, you are not a supplier. It is that simple.

That changes the order of your project. EDI is not something you add once the rest stands, it is the thing you start with, because it is the only part where somebody else sets the pace.

Three messages, and where they come from

The core of the GS1 standard is more manageable than the jargon suggests. Three messages genuinely matter:

ORDERS - the order. The retailer sends it to you.
DESADV - the despatch advice. You send it to the retailer, before the goods arrive.
INVOIC - the invoice. It goes from you to the retailer.

Alongside those there is usually an acknowledgement (APERAK), so both sides know a message landed. And there are timing requirements: EDI providers connecting to Ahold Delhaize document, for instance, that the DESADV must be in at least an hour before the goods reach the delivery location. That is not a detail. It means your despatch advice has an operational deadline that moves with your logistics.

The surprise: it is not two parties, but three

This is where most estimates go wrong. You picture EDI as a line between you and the retailer. But as soon as you have outsourced your storage and shipping - and for a young brand that is the rule rather than the exception - the chain runs through three parties.

The order arrives with you and must flow automatically to your logistics provider, because they pick and ship. The despatch advice does not originate with you but with that logistics provider, at the moment a pallet is actually ready, and must go from there to the retailer. The invoice does go back from your system to the retailer.

Look at that for a second. The message with the strictest timing, the DESADV, is precisely the message you do not create yourself. You depend on data from a party that does not work for you. That is why the question “what can your fulfilment partner do, and over which interface” shapes your scope as hard as the retailer does. How you set that up is covered in selling without your own warehouse.

Odoo does not do EDI itself, and that is fine

A common question: can Odoo do this natively? Towards a specific retailer: no. Odoo handles the content excellently - an incoming order becomes a sales order, a shipment becomes an outgoing delivery, an invoice is an invoice - but the translation into the GS1 message format and the transport to the retailer runs through an EDI provider or VAN. That party is the interpreter between your system and the retailer.

That sounds like a detour but is a blessing. You do not want your ERP to know every buyer’s EDI specifications; you want one specialised party to know that, and your system to talk to that one party. Odoo connects to the provider, the provider talks to the retailer. If a second retailer arrives tomorrow, that is an extension at your provider rather than a rebuild of your ERP.

There is no standard EDI connection

This is the sentence we get the most pushback on, and the sentence that saves the most money: there is a standard, but no standard connection. GS1 is the language. But every retailer has its own specifications, its own mandatory fields, its own timing, its own test track. “An EDI connection” does not exist in general, only per buyer.

What follows is practical: you cannot estimate an EDI track without that retailer’s specifications and that provider’s capabilities. Anyone who quotes you a number anyway is guessing. We would rather say we do not know yet and that finding out is step one, because this part is usually the biggest unknown in the entire scope - often the combination of EDI provider and fulfilment partner determines the bulk of what the project becomes.

And then the retailer tests your connection

The last part people underestimate: you are not done when it works on your side. Large retailers test and certify the connection themselves, at their own pace and in their own queue. That is lead time you cannot recover by working harder or adding people.

If you have a hard date - a shelf moment, a launch, a season - that is the reason to put EDI at the front and run the rest of your configuration in parallel. Accounting, product data and stock you can do at your own speed. For the retailer, you wait.

In short

With a large retailer, EDI is not a feature but an entry requirement. Three messages carry it: ORDERS in, DESADV out before the goods arrive, INVOIC afterwards. As soon as your logistics is outsourced there are three parties rather than two, and the message with the tightest deadline comes from somebody else. Odoo does the content, an EDI provider does the translation. And because there is a standard but no standard connection, every honest track starts with that one retailer’s specifications, and it starts early, because the retailer tests it itself.

About to supply a large retailer and not yet sure what your system needs to do? Schedule a no-obligation Quickscan and we will map your EDI track, your fulfilment partner and your administration - including what is standard and what becomes an integration.

Frequently asked questions

Do you need EDI to supply a supermarket chain?

In practice, yes. Large retailers exchange orders, despatch advices and invoices electronically following the GS1 standard, and expect a supplier to connect to it. It is rarely a preference and usually a condition of being allowed to supply at all. That means your EDI track does not come after your system choice, it is part of it.

Which EDI messages does a retailer use?

Three form the core, from the GS1 standard: ORDERS (the order the retailer sends you), DESADV (the despatch advice you send the retailer before the goods arrive) and INVOIC (the invoice). There is often an acknowledgement (APERAK) alongside. Retailers also set timing requirements: EDI providers connecting to Ahold Delhaize document, for example, that the DESADV must arrive at least an hour before the goods reach the delivery location.

Can Odoo do EDI with a retailer natively?

Not out of the box towards a specific retailer. Odoo handles the orders, deliveries and invoices fine, but the translation into the GS1 message format and the transport to the retailer runs through an EDI provider or VAN. That party is the link between your system and the retailer. Odoo connects to the provider; the provider talks to the retailer.

Is there a standard EDI connection?

No. There is a standard (GS1/EANCOM), but no standard connection. Every retailer has its own specifications, its own fields, its own timing and its own test track. "An EDI connection" does not exist in general, only per buyer. That is exactly why you need that one retailer's specifications before you can estimate anything.

How long does an EDI track take?

Count on not being the only one in control. The retailer usually tests and certifies the connection itself, and that takes lead time you cannot compress by working harder. That is why you start with EDI rather than with the rest: it is the one part where a third party sets the pace.

Recognize this from your own setup?

A 30-min scan turns hunches into a concrete view, what stays standard Odoo, what becomes custom, what doesn’t need code at all.

Get in touch ← Back to blog