Costco.com Dropship for Suppliers and Brands: Connecting Orders to Your ERP

This guide is for suppliers and brands who want to sell through Costco.com on a dropship basis, shipping each order from their own stock straight to Costco’s customer. It is not about reselling Costco products. It covers how the dropship hub fits between Costco and you, what the order flow looks like, and why the connection belongs in your own ERP.

Costco.com dropship usually runs through CommerceHub, part of Rithum. CommerceHub is a hub: it aggregates a retailer’s supplier network and presents one interface to each side. So as a supplier you are not connecting to Costco directly. You are connecting to the hub.

The arrangement is worth understanding before you integrate with it, because it changes who sets the rules and who you talk to when something breaks.

What a dropship hub is doing

In a conventional wholesale relationship, the retailer buys your stock and ships it to customers itself. In dropship, the retailer takes the customer order and you ship directly to that customer’s address. The retailer never holds the goods.

That creates a coordination problem. The retailer needs to know, per order, whether you can fulfill it, when it shipped, what the tracking number is, and what to pay you. It needs that from every supplier in its network, in a consistent format, and it does not want to build a separate integration for each one.

A hub solves that problem for the retailer. It defines one specification, onboards suppliers against it, validates what each supplier sends and delivers it to the retailer. The hub does not translate your documents. Your own system has to produce them in the format the specification asks for, and the hub checks them and passes them on. For you as the supplier, that makes the hub the party whose rules you implement and whose validation rejects your documents.

The practical consequence: the specification is theirs and it moves. Document requirements, field validation and onboarding steps are set by the hub and the retailer together and get revised, so treat whatever you are told today as the current specification to check rather than a fixed standard.

The flow, in order

Whatever the transport, the shape of a dropship cycle is consistent.

An order arrives, one customer order at a time rather than a bulk purchase order, carrying the ship-to address of the end customer. You acknowledge it, confirming what you can actually fulfill, because a dropship order you cannot ship is worse for the retailer than one you decline early. You ship it and send a shipment notice with the carrier and tracking details, which is what the retailer uses to tell its customer the parcel is on the way. Then you invoice for it.

Each of those is a point where things go wrong in a specific way. Orders that arrive and are not acknowledged in time. Shipment notices that disagree with what physically shipped. Invoices that do not reconcile against the shipment. The failure modes are the same ones that affect any trading-partner exchange, which is unsurprising, because the documents are doing the same jobs.

Why the connection belongs inside the ERP

The alternative to integrating is the hub’s supplier portal. Someone logs in, reads the new orders, types them into your system, ships them, then goes back and types the tracking numbers in.

That is a reasonable way to handle your first dozen orders and a bad way to handle your hundredth. The cost is not only the typing. It is that the portal becomes a second source of truth: the order exists there before it exists in your system, and your system never learns anything the person did not carry across.

Built into the ERP, orders land in the same order queue as every other channel, allocate against the same inventory, and their ship notices and invoices reflect what actually shipped. Nothing is re-keyed, and the order’s history lives where the business already looks. If your current system cannot take this on, that is the kind of gap custom ERP development closes.

Our delivered Costco work is on the wholesale side: we run Costco Wholesale EDI through SPS Commerce for a US consumer electronics brand. That connection is described in Costco EDI integration through SPS Commerce. Costco.com dropship through CommerceHub is a different program with its own specification, and we build it with the same approach: the files are read and generated inside your ERP.

Whichever route you take, make the jobs visible. A dropship channel you cannot see the status of is a channel you find out about from the retailer.

Monitoring is not optional on dropship

Dropship raises the cost of a silent failure, because the person waiting is the retailer’s customer rather than the retailer’s warehouse.

If an order feed stops, you are not short of paperwork, you are failing to ship orders somebody has already paid for. So the jobs need to be visible: when each last ran, whether it returned anything, what was rejected and why. A dashboard showing job status and exceptions is what turns a rejected document into something diagnosed rather than escalated.

The same discipline applies to acknowledgments. On a dropship program the retailer is usually measuring how fast you confirm and ship, and those measures are theirs to define and to change, so check what your own program is currently held to.

EDI, API, or the hub’s own interface

You may be offered more than one way in, and the choice is usually not yours. If a hub or retailer runs on X12 documents, you implement those. If it exposes an API, you call it. Some offer both and the decision comes down to what your system already does well.

What does not change is where the data has to end up. We have written about that choice in more detail in X12 EDI vs API integration: the transport is an edge concern, and an order arriving as a file and an order arriving from an API call are both orders that belong in the same table.

If you already ship dropship orders for Amazon, the pattern will be familiar. Amazon’s version is Amazon Direct Fulfillment EDI, one of the Vendor Central programs covered in Amazon EDI integration.

Where to start

Get the specification before you estimate anything. Which documents, which fields, which validation, what the acknowledgment expectations are, and whether there is a certification step before you go live. Onboarding against a hub usually takes longer than building the mapping, and that is worth knowing at the start.

Then decide where the orders will live. If the answer is a portal, you have a staffing plan rather than an integration. If the answer is your ERP, the work is the mapping and the monitoring.

We build these connections as marketplace integration and, where the documents are X12, as EDI integration inside the ERP, with every file read and generated using the EdiFabric .NET library. If you are a supplier or brand that has just been handed a Costco.com dropship specification, get in touch and tell us one thing: when an order arrives, does anything in your own system know about it before a person reads it?

Common questions