Inventory

Syncing Ecommerce, Wholesale, and Retail Sales Data: The Mid-Market Apparel Playbook

Syncing Ecommerce, Wholesale, and Retail Sales Data: The Mid-Market Apparel Playbook
By Ruchit Dalwadi · Reviewed by Ronnell Parale · · 7 min read

Synchronising sales data across ecommerce, wholesale, and retail channels is usually framed as a technical problem — which API, which middleware, how often to sync. For most mid-market apparel brands, that framing is wrong. The problem is not the sync frequency. It is what the channels are syncing to.

If every channel syncs to its own inventory view and those views reconcile to each other via exports or middleware, the sync will never be good enough. If every channel syncs transactionally to one inventory ledger, the sync is irrelevant as a concept — there is nothing to reconcile, because every write hits the same record.

The architecture that fails (and why)

The architecture most apparel brands arrive at between $5M and $20M looks like this:

  • Shopify owns the DTC orders and a view of inventory (its own)
  • A wholesale tool (JOOR, NuOrder, a B2B portal, a spreadsheet) owns wholesale orders and another view of inventory
  • A marketplace tool owns Amazon/Zalando/Mirakl listings and a third view of inventory
  • The 3PL portal owns the warehouse's physical count and a fourth view of inventory
  • A POS system owns retail store inventory and a fifth view
  • QuickBooks or Xero owns finance and the invoice state

Each of these tools is, on its own, a reasonable piece of software. The problem is that there is no primary inventory ledger. Every tool thinks it is the source of truth for the slice it owns. The "sync" between them — usually every 5 or 15 minutes, sometimes via Zapier, sometimes via a middleware vendor — is a best-effort reconciliation between views that are, by design, divergent.

The failure modes this architecture produces, in order of frequency:

  1. Oversell at peak. DTC sells a unit, wholesale allocates the same unit, the sync hasn't caught up. Both customers think they've got it. The brand picks which to disappoint.
  2. Stale marketplace listings. Amazon sees an inventory number that was correct an hour ago. A unit sells through DTC; Amazon doesn't know yet; Amazon oversells and gets penalised.
  3. Wholesale rep quoting wrong availability. Rep at a trade show is reading yesterday's export. Two reps quote the same units to different customers.
  4. Warehouse picking against a committed unit. The picker pulls a unit; the system doesn't know it's allocated to a different channel.
  5. Reconciliation failure at month-end. Finance imports sales from each channel; the numbers don't add up to the physical inventory count; a spreadsheet gets built to explain the variance.

Each of these is a real cost. The labour to reconcile, the refunds from oversells, the marketplace penalties, the lost wholesale relationships. None of them is the "fault" of any single tool. They are all consequences of an architecture that has no primary ledger.

The architecture that holds

A unified system of record for operational data — product, inventory, orders, warehouse — with channels as readers and writers against that system, rather than parallel systems. Concretely:

  • One product master. Style, colour, size, images, BOMs, attributes live in one place. Shopify pulls from it. Marketplaces pull from it. The wholesale B2B portal pulls from it. Any field update flows out, never in.
  • One inventory ledger. Physical units by location, committed versus available, in real time. Every transaction — a DTC sale, a wholesale allocation, a warehouse pick, a marketplace adjustment, a return — updates the same ledger transactionally.
  • One order queue. DTC orders, wholesale POs, marketplace orders, B2B portal orders land in the same queue, against the same inventory, with channel as an attribute rather than a system.
  • One warehouse workflow. Pickers work against one order queue; the inventory decrement happens at pick, not at ship. The 3PL either integrates natively or via a file-based connector that writes to the same ledger.
  • Channels as endpoints, not systems of record. Shopify runs the storefront and captures DTC orders. Amazon runs the marketplace listing. JOOR runs the showroom relationship. The B2B portal runs wholesale self-service. None of them owns inventory; they all read from one.

In this architecture, "sync" is not a process that runs every 15 minutes. Every write from a channel is a transaction against the ledger in real time. Every read reflects the current state. The failure modes above cannot occur, because the data they depend on is a single record, not several records being reconciled.

What the practical move looks like

For a mid-market apparel brand currently on the fragmented architecture, the move to a unified one is operational, not just technical. It involves:

  1. Picking the system of record. For apparel brands in the $5M–$100M range, this is typically an apparel-specific ERP that natively handles style-colour-size inventory, wholesale trading terms, and multi-channel allocation. Generic ERPs work but require apparel customisation.
  2. Reclassifying the existing tools. Shopify stays as the DTC storefront. Amazon stays as the marketplace channel. JOOR or NuOrder stay as the wholesale showroom front-end if they're in use. The difference is that none of them holds inventory any more — they are channels against one ledger.
  3. Moving the wholesale spreadsheet. This is usually the hardest internal change. The sales team has been running wholesale pre-book in a spreadsheet for years. Moving it into the new system is a workflow change, not a data-migration task. It requires the wholesale leads to work against the system, not against a sheet that gets reconciled to it.
  4. Retiring the middleware. If there is a sync vendor keeping Shopify and the 3PL aligned, it becomes unnecessary. If there is a reconciliation spreadsheet that finance runs at month-end, it becomes unnecessary. Retiring these is the point at which the new architecture starts paying for itself.

Specific integration patterns that matter

Shopify ↔ apparel ERP

Shopify is the DTC channel for most mid-market apparel brands. The integration pattern that works: the apparel ERP pushes product data to Shopify, Shopify handles the storefront, inventory updates in real time via webhook on every sale, and orders flow back to the ERP transactionally. Batch syncs introduce oversell risk; real-time webhook-based syncs eliminate it.

Marketplaces (Amazon, Mirakl, Zalando, The Iconic)

Marketplaces are sensitive to listing accuracy — overselling on Amazon has direct account-health consequences. The integration pattern that works: the apparel ERP maintains per-marketplace listings, pushes inventory updates in real time, and auto-pauses listings when stock drops below a configurable safety threshold. This is the opposite of the typical mid-market architecture where marketplaces pull from a stale export.

Wholesale B2B

Wholesale orders come in through three surfaces: direct (rep or sales team entering into the system), B2B portal (customer self-service), and showroom tools like JOOR. The integration pattern: one order queue inside the ERP, with the three surfaces as write points. The B2B portal reads live availability. The rep app reads live availability. JOOR integrates with the ERP for product data and order flow.

Retail / POS

For brands with physical retail or showroom stock, the POS (Shopify POS, Vend, Lightspeed) is a channel that reads from and writes to the same inventory ledger. Retail stock is a location in the warehouse ledger, not a separate system. This means retail sell-through reports against the same data as DTC and wholesale, without reconciliation.

3PL

3PL integration is where the architecture most often breaks. The pattern that works: the 3PL receives pick tickets, ASNs, and product data from the ERP automatically, and sends inventory updates and tracking back. For 3PLs with direct connectors (ACR Supply Partners, Bergen Logistics, Microlistics, Mintsoft) this is native. For others, file-based integration over SFTP or EDI covers the same workflow. The 3PL is not a separate system of record; it is a physical execution location reporting to the ledger.

The operational benchmark

A mid-market apparel brand running ecommerce, wholesale, and retail sales data in sync hits these operational numbers:

  • Oversell rate below 0.5% across all channels
  • Shopify / marketplace inventory refresh in real time, not on a 5- or 15-minute batch
  • No reconciliation spreadsheet between channels at month-end
  • Every channel's inventory view matches the warehouse's physical count within a single-digit percentage of variance (not the 10–20% typical of fragmented operations)
  • Leadership reports sell-through and margin from one source, not three exports

If your operation is not hitting these numbers, the sync is not the problem. The architecture is. The 6 Breakpoints of apparel operations describes the progression — Breakpoint 3 (inventory truth weakens) and Breakpoint 4 (order flow becomes harder to trust) are the specific signals this architecture is engineered to eliminate.

For a walk-through of what the system consolidation looks like against your specific channel mix, start with a discovery conversation. Related reading: Running wholesale and DTC together, Shopify integration, Multi-warehouse and 3PL.

R
Written by
Ruchit Dalwadi
Head of Product, Apparel Operations, Uphance

Ruchit writes about product strategy for apparel operations, covering how mid-market fashion brands use connected workflows to manage product development, inventory, orders, warehouse execution, and reporting.

R
Reviewed by
Ronnell Parale
Head of Customer Success and Onboarding, Uphance

Ronnell writes about onboarding, adoption, and operational readiness for apparel brands moving to a connected platform. His articles focus on what it takes to go live with confidence and sustain strong execution across channels, warehouses, and teams.

More from the blog