Start here

What is EDI, in plain language

EDI stands for electronic data interchange: businesses exchanging orders, ship notices, invoices and the rest as structured documents their computers read directly, with no person retyping anything in between.

That is the whole idea. Everything else, the numbered documents, the platforms, the acronyms in your customer's letter, is machinery built around it.

The short answer

A purchase order used to be a phone call, then a fax, then a PDF in an email. Every one of those needs a person to read it and type it into a system. EDI replaces the reading and the typing: the order leaves the buyer's system as a structured file, in a format both sides agreed on, and lands in the seller's system as data.

In North American retail that agreed format is ANSI X12. Each document type has a number: an order is an 850, a ship notice is an 856, an invoice is an 810. The numbers are just names.

Why retailers mandate it

  • Scale

    A large retailer trades with thousands of suppliers. Keying that volume by hand does not survive arithmetic, so they standardised the paperwork out of existence and made the standard a condition of doing business.

  • Their operation is planned around it

    Receiving docks schedule against ship notices. Payables systems match invoices to orders without a person. When your document is late or wrong, their machine stops, which is why mandates come with windows and scorecards.

  • Enforcement is financial

    Most programmes enforce by deduction. The fine arrives as a line on a remittance advice weeks later, coded, and the chargebacks guide covers what those lines cost.

The documents, briefly

A retail relationship usually runs on a handful: the 850 purchase order coming in, the 855 acknowledgment answering it, the 856 ship notice going out before the truck, and the 810 invoice that has to match the order. Grocery programmes run the same conversation under their own numbers, the 875 among them, and dropship and 3PL arrangements add a few more.

Each number has its own page here, written for the person who just met it.

The full set, each in plain language: the X12 catalog.

How the documents travel

Three ways, broadly. A platform such as SPS Commerce, TrueCommerce or Rithum carries the documents between you and the retailer as a service. A direct connection moves them over AS2 or SFTP with nothing in the middle. And a VAN, the oldest arrangement, is a store-and-forward mailbox between trading partners that predates the modern platforms and still carries plenty of traffic.

Which one you use is usually decided for you. The mandate letter names a platform, or names a transport, and the choice that remains is how the documents get into and out of your own system.

The routes in detail: the software landscape, mapped, and direct over AS2 or SFTP.

What your letter is actually asking

A mandate letter asks for named documents, inside named windows, structured to that retailer's own guideline. It rarely says any of that plainly. It says a platform name, a list of numbers and a date.

The half the letter never mentions is your side: how an order becomes a sales order in your system, how your shipment becomes their ship notice, and who notices when a document fails at seven in the morning. That half is the work, and it is the half we do for suppliers running Odoo.

Holding a letter with numbers on it

The Requirement Check takes two answers: who mandated you and where you stand today. You get back a plain readout of which documents that customer asks for and what has to change inside your Odoo. It is free and it commits you to nothing.

Book a 30-minute call