Here is the thing nobody tells you about EDI for dropshipping: the standard was never designed for it.
Electronic Data Interchange grew up in wholesale. A buyer sends a handful of large purchase orders to a distribution center on a predictable rhythm. Pallets arrive, a receiving team checks them in, and an invoice follows at month end. The whole system assumes bulk, planning, and patience.
Dropship has none of those. Thousands of orders, most of them a single unit, each going to a different person's front door, arriving continuously, with a customer refreshing their tracking page within the hour.
Same five documents. Completely different operating envelope. Understanding where the assumptions break is what separates a dropship program that scales from one that generates apology emails.
EDI for dropshipping is the automated exchange of standardized documents between a retailer and the brands that ship on their behalf, so that orders reach the right supplier and tracking gets back to the customer without anyone handling it manually.
The retailer sells the product. The brand holds and ships it. EDI is what keeps those two facts in sync. Five documents do the work:
Straightforward enough. The difficulty is that each of these documents was specified with a warehouse in mind. If you want the underlying mechanics of how these documents move, our walkthrough of how EDI works follows the full lifecycle with a real annotated file.
In wholesale, the ship-to on a purchase order is a loading dock the supplier probably knows by heart.
In dropship, it is a stranger's house. The order has to carry a full name, street, city, state, postal code, and country, because the brand is shipping directly to someone with no relationship to them. Carro's purchase order specification passes two separate address blocks for exactly this reason: one for shipping, one for billing.
Get this wrong and the parcel goes nowhere. There is no receiving team to sort it out.
A wholesale ship notice tells a receiving dock what is arriving and how it is packed, so they can plan labor.
A dropship ship notice carries a tracking number that gets forwarded to a shopper within minutes. The accuracy and speed requirements changed completely, because the audience changed from a warehouse team to a customer who will email support if nothing arrives.
The structure reflects it. Carro's ship notice nests shipment, order, pack, and item levels, identifies the courier by its standard carrier code, and carries the tracking number in a dedicated field.
This is the one that costs real money.
In wholesale, a stale stock file means a buyer orders something unavailable and has a conversation about lead times. Annoying, survivable.
In dropship, a stale stock file means your storefront sold something that does not exist. Now you are refunding a customer, apologizing, and absorbing a review that will sit there for years.
Carro's stock update specification handles this with two behaviors worth knowing. A full snapshot zeroes out any variant not included in the file, which is unforgiving but accurate. A change-only update leaves omitted variants untouched, which is safer for partial sends. There is also staleness protection: a file dated older than the last one processed gets ignored rather than rolling your inventory backward.
The recommended send frequency is every five to fifteen minutes. That tells you everything about how the tolerance shifted.
Traditional EDI batches many transactions into one file because it grew up around scheduled network delivery windows. Efficient, when data moved overnight anyway. In dropship, batching is just latency you chose. Carro rejects it outright: one transaction set per file, in both directions, with the supplier folder collected every 15 minutes. A file containing multiple transaction sets generates an exception rather than processing.
Automated order routing is the part retailers actually buy. Here is the sequence. A customer checks out. Their basket contains products from three different brands.
The system splits the order into three supplier orders, one per brand, without anyone deciding anything. Carro identifies which supplier holds each line and creates the corresponding order in their system. Each brand receives only their portion, with the customer's shipping address attached.
Each brand's system reads the order and returns an acknowledgement, line by line. If one brand cannot fill a line, that line is rejected and the retailer's system knows immediately rather than discovering it three days later.
Each brand picks, packs, and ships, then sends back a ship notice with the courier and tracking number. The retailer's system updates the customer automatically. Settlement follows. On Carro, invoices generate automatically once a ship notice is accepted and payouts run through Stripe, so nobody reconciles fifty invoices at month end.
Zero human touchpoints across the whole chain. When something does need attention, it queues visibly rather than disappearing.
A customer buys a rain jacket and a pair of trail shoes. Two different brands. Your ops coordinator opens the order and splits it by hand into two emails. Brand A sees theirs the next morning. Brand B replies that the shoes are out of stock, which is news to your storefront, because their last stock file was Tuesday.
You refund the shoes and write an apology. Brand A ships the jacket but forgets the tracking number, so three days later the customer emails asking where it is. Your coordinator chases Brand A, gets the number, and forwards it. Total human touchpoints: nine. Total elapsed time before the customer had tracking: four days.
Same basket. Checkout completes and the order splits into two supplier orders automatically. Both brands receive theirs within the same 15-minute cycle. The shoes were never listed as available, because Brand B's stock update ran twelve minutes ago and the storefront reflected it.
Both brands acknowledge, ship, and return tracking numbers. The customer receives both automatically. Invoices generate on shipment confirmation. Total human touchpoints: zero. The difference is not effort. It is that the second version keeps working when you add brand number twenty.
Everything above is operational. This section is about what the shopper actually sees, which is where dropship programs are won or lost. Four things change for the customer the moment fulfillment moves to partners, and each one is either invisible or infuriating depending entirely on whether the data layer holds up.
A three-brand basket becomes three parcels arriving on different days from different couriers. Handled badly, the customer opens the first box, sees two thirds of their order missing, and assumes something went wrong. Handled well, they receive three tracking numbers with clear expectations at the point of dispatch, and the staggered arrival becomes a non-event they barely register.
The technical requirement behind that is specific: fulfillment has to be tracked per supplier rather than as one binary shipped flag on the order. A system that marks an order shipped when the first parcel leaves will misinform the customer about the other two, and no amount of careful email copy fixes a status that is simply wrong. This is also why per-line acknowledgement matters, since the order record needs to know which items sit with which supplier before it can report on them separately.
The window between "it shipped" and "where is my order" is roughly a day. Beat that window and the customer never contacts you. Miss it and you have a support ticket, which costs more to resolve than the margin on most single-item orders.
Automated ship notices close the gap because the tracking number reaches the customer within minutes of the label being printed, rather than after a coordinator notices the email and forwards it. The difference sounds procedural and is actually commercial: support volume in a dropship program correlates far more closely with notification speed than with delivery speed, because customers tolerate waiting when they know where their parcel is.

When a supplier cannot fill a line, the customer should get a clean partial refund and a clear message the same day, not a confused thread three days later asking them to confirm what they still want. The failure mode here is not the cancellation itself, which customers largely accept, but the ambiguity that follows a badly handled one.
Line-level acknowledgement is what makes the clean version possible. Because a supplier rejects individual lines rather than whole orders, the unavailable item cancels and refunds independently while everything else proceeds untouched. Without that granularity you face a choice between holding the entire order until the problem resolves or cancelling all of it, and both are worse for the customer than the outcome they should have had.
Customers check out once, on your storefront, with your branding, your payment flow, and your returns policy. The fact that three different warehouses in three different states are involved is invisible to them, which is the entire point of the model.
Preserving that is a data question rather than a design question. Branded packing slips, consistent tracking presentation, and a single point of contact for support all depend on your system holding accurate information about what each supplier shipped and when. Where the data layer is unreliable, the seams start showing, and customers who notice they are dealing with three companies rather than one behave like customers of three companies.
Each of these depends on the data layer working. That is the real argument for EDI in dropship: not efficiency, but the fact that the customer experience you promise is only deliverable if the information moves reliably.
Returns are the part of dropship most guides skip, and they are structurally harder than in owned-inventory retail because the goods have to go back to a warehouse you do not control.
Two flows matter:
1. Cancellations before shipment run through the acknowledgement. A supplier who cannot fill a line rejects it, that line cancels, and the customer is refunded for it. Because acknowledgements work at line level, the rest of the order continues without interruption.
2. Returns after delivery run through Carro's platform rather than the document flow. A retailer raises a return request, the supplier receives it and accepts or rejects it, and both sides are notified as the status changes. Carro supports this with dedicated return events, so a retailer's own systems can react automatically rather than waiting for someone to check a dashboard.
The practical guidance for a dropship program is to agree return terms per partner at onboarding rather than at the first return. Who pays return shipping, what the window is, and what condition is acceptable are commercial questions, and settling them upfront prevents the case-by-case negotiation that makes returns expensive to administer.
If you are a brand being asked to support dropship EDI, here is the actual scope.
What you must be able to produce.
Beyond those three outbound documents, the rest of the setup splits into what arrives from the other direction, what you can skip, and what has to exist before anything flows.
The commercial control matters as much as the technical setup. Price lists are yours, built per partner with your own margins, and you approve each retail partner individually. Distribution terms stay in your hands rather than being set by whoever lists your products.
Do not let your first live order be your first real test. Carro provides a sandbox retailer identity so you can round-trip a complete order before any real partner is involved. Its documentation prescribes three scenarios:
1. One order fully accepted and fully fulfilled. The happy path.
2. One order fully rejected. Confirms your rejection handling works and cancellation propagates correctly.
3. One order partially rejected and partially fulfilled. The realistic case, and the one that exposes whether your line-level logic is right.
Test your stock update behavior too, including a deliberate zero-out, so you can see that omitted variants behave the way you expect. Full snapshot files zero out anything not included. Change-only files leave omitted variants alone. Confirming which one you are sending is a two-minute check that prevents a catalog going unexpectedly out of stock.
Carro was built for this envelope rather than adapted to it, and the design decision that matters most is that it treats the two sides of the trade differently.
Suppliers connect by EDI. One connection over SFTP, four documents, ANSI X12 version 004010. Carro returns a functional acknowledgement confirming every file arrived.
Retailers connect natively. Shopify, WooCommerce, BigCommerce, and Magento integrate directly, with an API and webhooks available. A retailer works inside the storefront they already run.
That asymmetry is what makes a mixed network possible. The brand sends the file format their ERP already produces. The retailer sees an order in the storefront they already run.
For a supplier, satisfying one specification makes you transactional with every retailer on the network rather than one. Adding retail partner eleven becomes a commercial conversation instead of an engineering ticket.
Two operational details matter in daily use. Failures land in a queue called TradeOps Issues rather than vanishing. And every order page holds a record of each document sent and received, with its status, a download, and a retry that does not need re-transmission.
What separates Carro from a pure document service is that the supply is included. More than 1,500,000 products from vetted brands, hand-matched by account managers on category, audience, and price point, which is the difference between adding SKUs and adding assortment somebody will actually buy.
As The Gents Store found, the model works as a curation play rather than a volume one: "Carro and Netalico have empowered The Gents Place to add a layer to their customer experience; a curated online store for modern gentlemen seeking luxurious goods."
Three things make Carro different for dropship specifically:
1. It was designed for this order profile. No batching, stock updates every few minutes, consumer addresses in the purchase order, and tracking that reaches the customer automatically. These are not adaptations of a wholesale system, they are decisions made by a system that assumes a live storefront is selling continuously.
2. One connection reaches the whole network. A supplier satisfying four document requirements is transactional with every retailer on Carro, including partners they have not met yet. Adding retail partner eleven becomes a commercial conversation rather than an engineering ticket.
3. The partners are already there. More than 1,500,000 products from vetted brands, hand-matched by account managers on category, audience, and price point. Retailers report up to 3.5 times revenue growth, up to 180% growth in average order value, and up to three times catalog size.
Carro is built for retailers growing assortment without inventory risk, and for brands wanting retail distribution without a wholesale negotiation.
Pricing starts at $149 per month with unlimited partnerships, onboarding is self-serve, and you can round-trip a complete test order, rejection scenarios included, before a single real partner is involved.
EDI for dropshipping is the automated exchange of standardized business documents between a retailer and the suppliers who ship products directly to that retailer's customers. It covers stock levels, purchase orders, order acknowledgements, shipping notices, and invoices. The documents are the same ones used in wholesale, but the operating conditions differ sharply because orders are single units going to consumer addresses. On Carro, four documents make a supplier transactional: the 846, 850, 855, and 856.
Dropshipping EDI differs from wholesale EDI in four main ways despite using identical documents. Purchase orders carry a consumer's home address rather than a distribution center. Ship notices become customer-facing because the tracking number goes straight to the shopper. Stock accuracy tolerance drops from overnight to minutes, since a stale count causes an oversell rather than a backorder. And file batching becomes a liability instead of an efficiency.
Drop ship suppliers need four documents at minimum: the stock update (846), purchase order (850), acknowledgement (855), and ship notice (856). The invoice (810) is often optional because many systems generate invoices automatically from shipment confirmation. Suppliers also need a connection method, unique product identifiers both sides recognize, and a price list assigned to each partner. Carro requires exactly this set and treats invoicing as optional.
Automated order routing splits a customer order across suppliers and delivers each portion to the right one without manual intervention. A basket containing products from three brands becomes three separate supplier orders, each carrying the customer's shipping address. Each supplier acknowledges line by line, ships, and returns tracking, which updates the customer automatically. On Carro, invoices then generate automatically once the ship notice is accepted, with payouts running through Stripe.
Suppliers should send inventory updates every five to fifteen minutes for dropship, which is the frequency Carro's documentation recommends. Anything slower risks selling stock that no longer exists, since a live storefront makes decisions continuously. Full snapshot files zero out any variant not included, so partial sends must use the change-only format. Carro also ignores files dated older than the last one processed, which prevents inventory rolling backward.
Returns split into two flows. Cancellations before shipment run through the acknowledgement, where a supplier rejects a line and that line cancels and refunds independently while the rest of the order proceeds. Post-delivery returns run through the platform rather than the document exchange, with Carro providing dedicated return events so a retailer's systems can react automatically as a supplier accepts or rejects a request. Agreeing return terms per partner at onboarding rather than at the first return is what keeps this manageable.
Dropshipping EDI works with Shopify through a connected service, since Shopify does not speak EDI natively. The merchant continues working inside Shopify while the service handles document exchange with suppliers behind the scenes. Carro integrates with Shopify natively and manages the supplier EDI side, so the retailer never opens a document. The same applies to WooCommerce, BigCommerce, and Magento.
Consistency depends on tracking fulfillment per supplier rather than treating an order as one binary shipped flag. A three-brand basket becomes three parcels arriving on different days, so the customer needs three tracking numbers and clear expectations rather than a single confusing status. Automated ship notices close the gap between dispatch and notification, which is the window where support tickets appear. Because checkout stays on your storefront with your branding, the multi-warehouse fulfillment behind it remains invisible to the shopper.