Multichannel inventory sync for Australian sellers explained

If you sell the same product on Shopify, Amazon.com.au and eBay AU, you are running three storefronts against one pile of physical stock. Each channel thinks it owns that stock. None of them talk to the others by default. So the day you sell your last unit on eBay, Amazon and Shopify are still happily taking orders for it.

That gap, the lag between a sale on one channel and the stock count dropping on every other channel, is where multichannel inventory sync earns its keep. This post is the practical version: how a single stock pool actually works, how Amazon's FBA and FBM split complicates it, where GST lands when your finance system stays put, and the honest line on when you need a sync app versus a full warehouse system.

The oversell and stockout problem, stated plainly

There are two failure modes and they pull in opposite directions.

Oversell: you sell more than you have because two channels both committed the last unit. Now you are cancelling an order, refunding a customer, and on Amazon.com.au specifically, eating an Order Defect Rate hit that can throttle your Buy Box eligibility. eBay AU tracks the same kind of seller-performance signal. A handful of out-of-stock cancellations and your account standing slips.

Stockout, the cautious overcorrection: to avoid overselling you pad every channel down, holding back buffer stock per storefront. Now you are sitting on inventory that looks unavailable everywhere, missing sales you could have made, tying up cash in stock that reads as zero.

Both come from the same root cause: each channel maintains its own available-to-sell number, and those numbers drift the moment an order lands anywhere. The fix is not faster manual updates. It is a single source of truth that every channel reads from.

How a single stock pool actually works

A stock pool is one authoritative on-hand figure per SKU, held in a system that sits above your channels rather than inside any one of them. Each storefront becomes a listener and a reporter: it reports sales in, and it listens for the new available count out.

The mechanics, in order:

• Every SKU maps to one master record. Channel-specific listing IDs (Amazon ASIN, eBay item number, Shopify variant) all point back to it.
• A sale on any channel decrements the master on-hand, then pushes the recalculated available number to every other channel.
• Receiving, returns and stock adjustments update the master directly, and the new figure fans back out.
• A buffer or safety threshold can be set per SKU so fast-moving lines never quite hit zero on a channel before the sync catches up.

The two things that make or break this in practice are latency and the unit of truth. If sync runs every fifteen minutes, a popular SKU can oversell inside that window. Near-real-time, event-driven updates close that gap. And the unit of truth has to be physical, sellable stock in a known location, not an accounting figure, which is exactly why this lives in operations rather than your ledger.

Amazon.com.au: the FBA versus FBM pool split

Amazon is where most Australian multichannel setups get tangled, because the same SKU can be fulfilled two ways and those two ways draw from different physical stock.

FBA (Fulfilled by Amazon): units you have shipped into an Amazon fulfilment centre. That stock is physically gone from your warehouse and Amazon controls it. It must not appear in the pool your own warehouse sells from, or you will commit stock you no longer hold.

FBM (Fulfilled by Merchant): units you hold and ship yourself. This stock is part of your shared pool and competes directly with Shopify and eBay for the same units.

So the rule is that FBA inventory is reconciled, not pooled. You read Amazon's FBA on-hand for visibility and reordering, but you do not let your sync system sell it on other channels. Your own warehouse stock feeds the shared pool that covers FBM, Shopify, eBay and Catch. Treating FBA and FBM as one undifferentiated number is the single most common multichannel inventory mistake we see, and it is a slow oversell generator.

eBay AU, Catch and Shopify in the same pool

Once the Amazon split is clear, the other three are more straightforward, with their own quirks.

• eBay AU: variation listings (size, colour) each need their own SKU mapping, or sync writes the wrong count to the wrong variant. eBay is unforgiving on out-of-stock cancellations against seller standards, so it benefits most from a tight buffer.
• Catch: a marketplace model where listing and order flows are more batch-oriented than Amazon's. Plan for slightly less real-time behaviour and lean on a safety buffer on shared lines.
• Shopify: usually the cleanest integration and often the natural home for your richest product data, but if you also run Shopify POS in a physical store, that till is another channel drawing on the same pool. It has to be wired in too, or your shopfront and your online channels will fight over the same units.
• The marketplaces (Amazon.com.au, eBay AU, Catch) and the platforms (Shopify, WooCommerce, BigCommerce) all hang off the same master record. The pool does not care how many channels you add, as long as each one maps cleanly to a SKU.

GST and orders: keep the ledger where it is

Multichannel selling multiplies your order sources, not your accounting needs. GST on a sale is GST regardless of whether it came from eBay or your own Shopify store, and your BAS does not care which channel sourced the line. So there is no reason to rebuild your finance system to sell on more channels.

The cleaner architecture is to keep your finance system (Xero, MYOB or NetSuite) as the system of record for GST, invoicing and BAS, and run the operations layer separately. Orders flow in from every channel into one operations view, get picked, packed and shipped from one stock pool, and the financial side of each order, including GST treatment, syncs to your ledger. You are not migrating your accounts to add a sales channel; you are adding an operations layer above accounts that already work.

One thing worth getting right early: tax treatment can differ by channel. Some marketplaces collect and remit in certain scenarios; your own store does not. Map who is responsible for GST on each channel up front so the figures landing in your ledger are clean, rather than reconciling it line by line at BAS time.

Sync app or warehouse system: the honest split

Not everyone needs a warehouse system to fix oversell. Be honest about where you sit.

A lightweight inventory sync app is the right call when you are a single location, your SKU count is modest, fulfilment is one person picking from shelves, and your real problem is just keeping channel counts aligned. A focused sync tool solves that well and you should not over-buy.

You have outgrown the sync app, and need a proper warehouse and operations system, when several of these are true:

• Multiple locations, or a 3PL plus your own stock, where you need to decide which location fulfils which order.
• Real picking complexity: wave or zone picking, bin locations, batch or expiry tracking, cycle counting instead of full stocktakes.
• Stock accuracy problems that sync cannot fix because the underlying counts are wrong at the bin.
• Returns volume that needs proper grading and restock workflows before units re-enter the sellable pool.
• Kitting, bundles or assembly, where one sold listing draws down several component SKUs.

If your pain is purely channel counts drifting, a sync app is the better fit and we would tell you so. If the pain is the warehouse underneath the channels, syncing faster just spreads bad numbers around quicker.

Shipping the orders once they land

A unified pool only pays off if you can dispatch from it cleanly, and dispatch is where carrier reality matters. Here it is straight: NZ Couriers is the one live carrier API today; every Australian carrier (Australia Post, StarTrack, Sendle, Toll, DHL, Aramex, CouriersPlease and the Shippit aggregator) is wired during rollout, by direct API, aggregator or file-based connection, confirmed during scoping. So when you consolidate channels into one pool, you also consolidate dispatch: orders from Shopify, eBay AU, Catch and Amazon FBM hit one fulfilment queue, get picked from one pool, and ship on whichever carrier connection is confirmed for your setup. Full carrier detail lives at /integrations.

How OpsUI fits

Multichannel inventory sync is, at its core, an operations problem wearing an ecommerce costume: the master stock figure, the FBA-versus-FBM split, the per-channel buffers and the dispatch queue all live in the warehouse layer, not the ledger. OpsUI runs that layer as a la carte modules, so you take inventory-management and order-management for the pool and the unified order view, add shipping-outbound for the dispatch side, and bolt on receiving-inbound, returns-management or cycle-counting only as your warehouse complexity actually demands it.

Your finance system stays exactly where it is. Keep Xero, MYOB or NetSuite as the GST and BAS system of record and let OpsUI sit above it as the operations layer; bidirectional NetSuite sync is live in production today, and Xero and MYOB sync is wired during rollout through the finance-accounting module. Flat modular pricing from A$399/module/mo, full breakdown at /pricing.

If you want to see a single stock pool driving Shopify, Amazon.com.au and eBay AU against your real SKUs, book a walkthrough at /book-demo, look at the channel and carrier connections at /integrations, and read how the warehouse side works under /products/inventory-management.