EDI software, mapped

The map in one paragraph

Networks and platforms carry documents between you and your trading partners as a service. VANs are the older mailbox arrangement doing a narrower version of the same job. Translators turn X12 into data your systems can use and back again. And ERP connectors put the whole conversation inside the system where your orders, stock and invoices already live.

Most suppliers under a mandate end up with two of the four: something that moves the documents, and something that lands them.

Networks and platforms

SPS Commerce, TrueCommerce, Rithum and their peers. The retailer is usually already connected on their side, which is why mandate letters name them: your customer wants you on rails they already run. The platform manages the formats, the partner tests and the transport, and charges by subscription, by document, or both.

What a platform does not do is touch your ERP. Its cheapest tier is a web portal where a person retypes everything, and the step up from that portal is precisely where an integration begins.

The platform routes in detail: SPS Commerce, TrueCommerce, Rithum, and the portal tier, honestly assessed.

VANs, the arrangement that predates the platforms

A value-added network is a store-and-forward mailbox. Each trading partner connects once to the VAN, drops documents addressed to the other, and collects what arrived. Before the internet made direct connections cheap, this was how EDI moved, and a great deal of traffic still runs this way between long-established partners.

New mandates rarely point at a bare VAN any more. Where one appears in your letter, it behaves like a transport: the mailbox moves the files, and everything about landing them in your system remains open.

Translators, and the mapping inside them

A translator converts X12 segments into structured data and back. Every route involves one somewhere: inside the platform, inside the connector, or standing alone in front of an ERP that speaks only its own language.

The software is the smaller half of that job. The larger half is mapping, the per-partner decisions about which of their fields becomes which of yours, and mapping is work a person does once per trading partner regardless of whose translator runs it. Buying a translator does not buy the mapping.

ERP connectors, where the documents actually land

A connector embeds the conversation in the system of record. The 850 arrives as a sales order, the 856 leaves from a validated delivery, the 810 is born from the same chain, and the inventory feed reads live stock. No screen in the middle, no retyping, and the people who run orders today keep working in the system they already know.

Connectors are the category we work in, on the Odoo side, and the reason is structural: every failure mode in this trade, the mismatched invoice, the late ship notice, the oversold feed, is a gap between the documents and the ERP. Closing the gap is the product.

Choosing, which is mostly recognising

The honest version of a best EDI software list is short: the best platform is the one your mandate names, the best transport is the one your customer accepts, and the best connector is the one built for the ERP you actually run. The category question answers itself once the letter and the ERP are on the table.

What deserves real evaluation is the seam between them: who owns the mapping, who runs the partner tests, and who answers when a document fails after go-live. Those are service questions wearing a software costume.

What the service half involves: EDI integration services, and what a provider actually does.