EDI or an Integration Hub? What UK Wholesalers Actually Need

What EDI Actually Is

A buyer at a large retailer says "you'll need to be EDI capable." Here is what that sentence does and does not mean, and what it costs to answer it honestly.

EDI — Electronic Data Interchange — is one of the oldest ideas in trade and one of the most misunderstood. It predates the web by decades, it is not going away, and a great many wholesalers are told they need it without ever being told what it is.

So, plainly: EDI is an agreed format for sending routine trade documents between two companies' systems without a human retyping them. Purchase orders, order acknowledgements, despatch notes, invoices. The point is not the technology. The point is that both sides agreed the format in advance, so a document arriving from your customer's system can be understood by yours with nobody reading it.

Why a Retailer Asks for It, and Why That Ask Is Not Negotiable

When a large retailer or grocer says you must be EDI capable, they are not expressing a preference. They are describing how their purchasing works. Their systems raise thousands of orders and match thousands of invoices without human intervention, and a supplier who cannot participate is a supplier who has to be handled by hand.

Two consequences follow, and neither is negotiable by argument:

• The format is theirs, not yours. They will specify the standard, the document types, the fields, and frequently the transport as well
• Compliance is commercial, not technical. Late or malformed documents can attract charges, and in some trading agreements repeated failures affect the trading relationship itself

If you are in this position, this article is not really for you — you need EDI, the requirement is written down somewhere, and the only question is who implements it. The last section says plainly what we do and do not cover.

What People Mean When They Say "EDI" and Do Not Mean EDI

This is the useful part, and it is where a lot of money gets spent unnecessarily.

"EDI" is used loosely to mean any automated exchange of trade documents. But there is a real distinction underneath, and it decides what you have to buy:

• True EDI means a formal standard — EDIFACT in the UK and Europe, X12 in North America — usually moved over a dedicated transport such as AS2 or through a value-added network. Rigid, mature, expensive to get wrong, and non-optional when a large retailer mandates it
• Structured file exchange means an agreed CSV, XML or JSON file dropped somewhere agreed, on an agreed schedule. It solves the same business problem for two willing parties. It is dramatically cheaper. It is also what a great many "EDI projects" turn out to actually need
• API integration means the two systems talk directly, in real time. Better where both sides support it, and irrelevant where your customer's purchasing system was specified in 2003

The question worth asking before you buy anything is: who is imposing the format? If the answer is a named customer with a written specification, you are in the first category and your options are limited. If the answer is "we just want orders to stop arriving as email attachments", you are very probably in the second, and the cost difference between the two answers is large enough to be worth ten minutes of checking.

Where an Integration Hub Does the Same Job

An integration hub sits between your ERP and everything that needs to talk to it, and applies one set of rules to all of it. For document exchange with a trading partner, it can do most of what people want from EDI: receive an order in an agreed shape, validate it, put it into the ERP as a real order, and send the acknowledgement, despatch note or invoice back out in whatever shape was agreed.

Where it does not substitute for EDI:

• When the standard is mandated. If a retailer requires EDIFACT over AS2 with their message specification, that is what has to be produced. A hub can be part of that, but it does not remove the requirement
• When certification or a network is part of the deal. Some trading relationships require testing against the partner's own certification process, or membership of a specific network
• When the volume justifies dedicated tooling. At a certain number of partners and documents, an EDI platform built for exactly this is the right purchase, and we would tell you so

Three Questions to Ask Before Buying Either

• Who is asking, and is it in writing? A named customer with a specification is a requirement. "We should probably do EDI" is a preference, and preferences have cheaper answers
• How many partners, and how alike are they? One partner is an integration. Fifteen partners with fifteen specifications is a platform, and pretending otherwise gets expensive around partner four
• What happens to a document that fails? The unglamorous question that predicts the cost of ownership better than any other. Someone has to notice, decide, and fix it — and if that person is not named at the start, it becomes whoever happens to be looking

The same three questions decide the price of any integration, not just this one. We set out the six drivers that move an integration cost, and the questions that make competing supplier quotes comparable, in our ERP integration cost model.

Where We Fit — and Where We Are the Wrong Answer

Worth being precise, since the distinction above is the whole point of the article.

What we build is structured file exchange, not EDI. Our integration hub moves orders, stock, prices and invoices between an ERP and the systems around it. Where that involves files, they are agreed CSV or spreadsheet formats on an agreed schedule — and in practice it has been built for partner applications, such as getting orders from a field sales app into the ERP without anyone retyping them, rather than for retailer-mandated document standards.

We do not do EDI in the strict sense, and you should hear that from us rather than find it out later. No EDIFACT or X12 message sets, no AS2, no value-added network, no certification against a retailer's onboarding process. If your customer's supplier agreement specifies any of those, we are not the right supplier for that piece — buy a dedicated EDI service, and be wary of anyone who tells you a general integration tool covers it.

Where we are useful is the part that comes next, and it is the part most often underestimated. However the document arrives — from an EDI provider, a file drop, a marketplace or a storefront — it still has to become a real order in your ERP, against the right customer, at the right price, with the right stock treatment and the right credit decision. That is the same problem every other channel presents, and it is the one we solve.

Plenty of businesses end up running a specialist EDI provider for their mandated retailer traffic and a hub for everything else. That is usually cheaper and more robust than making either one do the other's job.

EDI for Wholesalers: Common Questions

What is EDI in simple terms?

An agreed format for exchanging routine trade documents — orders, despatch notes, invoices — directly between two companies' systems, so neither side retypes them. The value is in the prior agreement about the format, not in any particular technology.

Do I need EDI to sell to a large UK retailer?

Usually yes, if they ask for it. Large retailers and grocers run automated purchasing and matching, and a supplier who cannot exchange documents that way has to be handled manually. The requirement normally appears in the supplier agreement, and it specifies the standard and the document types.

What is the difference between EDI and an API integration?

EDI is a document standard, usually asynchronous and batch-oriented, designed so parties who have never spoken can exchange paperwork reliably. An API integration is two systems talking directly, usually in real time, and requires both sides to support it. They solve overlapping problems, and which is appropriate is usually decided by whichever partner has the older purchasing system.

Can we avoid EDI with a file feed instead?

Often, if the other party agrees — and that is the deciding condition. Where the exchange is between two willing parties with no external mandate, an agreed CSV or XML file on a schedule solves the same business problem far more cheaply. Where a retailer has specified a standard, a file feed is not a substitute, however well it works.

How much does EDI cost?

It varies too widely for a headline figure to be honest, and the recurring costs matter more than the setup. The parts to price are: implementing each partner's specification, the transport or network if one is required, testing and certification, and — the one most often left out — who investigates a failed document on a Friday afternoon.