Part of mPorts OMS
Connect to retailers the way they require.
Large retailers specify how they will trade with you: purchase orders arrive in their format, and acknowledgments, shipment notices and invoices are expected back in it. mPorts connects to retailers over EDI and operates the orders those documents create in the same place as every other channel, so EDI is not a second system your team has to watch.
Why EDI is usually somebody else’s problem, and then yours
EDI is not a thing most businesses choose. It is a condition of trading with a large retailer, and it arrives as a requirement with a deadline attached.
The usual answer is a separate EDI system: documents land there, someone re-keys or exports them, and the orders they represent start their real life somewhere else. That works, and it puts a translation step between you and every order that matters most.
A purchase order, end to end
The same lifecycle every other order runs — it simply starts as a document rather than an API call.
- 01
Purchase order in
The retailer sends an order in the format they specify.
- 02
Acknowledgment back
Confirmation that the order was received and what you will do with it.
- 03
Operate the order
Inventory, fulfillment and shipment run in mPorts OMS, alongside every other channel.
- 04
Shipment notice
What shipped, from where, with what tracking.
- 05
Invoice
Billed back in the format the retailer requires.
EDI is not a separate place to work
The point is not that mPorts speaks EDI. Several systems do. The point is that the order a retailer sent you by EDI is operated in the same queue, with the same inventory and the same fulfillment rules, as the order that arrived from a marketplace API.
When a retailer order is late, it is late in the same view as everything else — not in a system somebody has to remember to open.
- Purchase orders in, acknowledgments back
- Shipment notices and invoices in the format the retailer requires
- The resulting orders operated alongside every other channel
- One place to look when a retailer says a document never arrived
What we are not claiming
We are not telling you EDI is free. mPorts is paid software, and large retailers commonly require a connection through a third-party network that you contract with directly — that cost is real and it is not ours to waive.
We are not publishing a list of transaction sets as though every one is live for every retailer. Retailers differ, some trade in formats other than X12 at all, and what is connected for your specific retailers is a question we will answer rather than assume.
Onboarding a new retailer is work, not a switch. It involves their credentials, their identifiers and, usually, their certification test plan.
Questions buyers ask
- Do we still need a separate EDI provider?
- Often yes — many large retailers require you to trade through a particular network, and that relationship is yours. What changes is that the orders arriving through it are operated in mPorts rather than in a second system beside it.
- Which retailers are already connected?
- Ask us and we will tell you which of your specific retailers are connected today. That is a real answer with a real list behind it, and it is a better conversation than a logo wall.
- Is EDI included in mPorts OMS, or priced separately?
- Retailer document exchange is part of what mPorts operates for you rather than a separate product you buy from us. What we cannot include is any third-party network fee your retailer requires — that is contracted by you, and we will not imply otherwise.
- What about retailers who use an API instead?
- Those connect too, and they end up in the same place. Whether an order arrived as a document or an API call stops mattering once it is in the operation.
Tell us which retailers you trade with.
We will tell you what is connected today and what would need building — before you sign anything.