Using Counterpoint transfer orders to keep ecommerce stock flowing

Counterpoint has long been the back-of-house engine for Australian specialty retailers who run a shopfront plus a website, and transfer orders are the quiet workhorse that keeps the two talking to each other. When you drop a pallet of ceramic dinnerware into your Brisbane warehouse and your Sydney flagship is going gangbusters on tableware, a transfer order is what moves that stock into the bin your Shopify or Magento site is looking at. Without it, the online listing shows "out of stock" while the floor has crates of it.

For retailers still wrapping their heads around the shift away from NCR Retail Online, understanding how Counterpoint handles inter-location replenishment is one of the most useful skills to lock in. The same logic that powered the old platform still works today; you just have to drive it through Counterpoint rather than a separate ecommerce add-on.

What transfer orders actually do in Counterpoint

A transfer order in Counterpoint is a document that records stock moving from one location to another within your business, and it's distinct from a purchase order (which is stock coming in from a supplier) or a sales order (which is stock going out to a customer). Think of it as the internal logistics paperwork: you nominate a source location, a destination, the SKUs, and the quantities, and the system adjusts the on-hand figures at both ends the moment you post the document.

For ecommerce replenishment specifically, the order's job is to push inventory into the bin your online storefront reads from. Most Australian retailers running Counterpoint with a Magento or WooCommerce site through an NCR Counterpoint partner will have a designated "web" or "fulfilment" location, and that location needs to be fed by the bricks-and-mortar stores when it's running low.

The reason this matters more in Australia than in denser markets is distance. A buyer in Cairns ordering a gift set has to wait for something to leave a Melbourne DC or a Perth store, and if the web bin is empty, the order either bounces or gets routed somewhere expensive. Transfer orders give you a controlled way to top up that web bin from anywhere in the network.

Setting up the stock locations that drive replenishment

Before transfer orders do anything useful, the location structure in Counterpoint needs to reflect how your online channel actually sources stock. Most stores start with one location per shopfront plus a warehouse, then add a virtual "web" location that the storefront integration treats as the default source. Without that virtual bin, the integration often pulls from the wrong store and floods one site while starving another.

A common Australian setup is a flagship in Sydney's CBD, a warehouse in western Sydney or the western suburbs of Melbourne, and a web location flagged as the fulfilment hub. Smaller chains sometimes collapse warehouse and web into one physical site, but the virtual distinction still helps because it lets you run replenishment rules without messing with the floor counts your store managers rely on.

Spend time on the naming conventions early. Calling the web location something like "WEB-MAIN" or "ONLINE-FC" makes every transfer order readable at a glance, and it stops your team from accidentally transferring between two retail stores when they meant to feed the online channel. Once the locations are clean, the transfer order workflow becomes a lot less prone to typos.

Creating a transfer order from store to warehouse

The actual creation of a transfer order in Counterpoint is in the Inventory or Stock Control menu under Transfer Orders, and the screen layout has barely changed in years, which is handy if your team was trained on an older version. You pick the source location, the destination, then either scan or type in the SKUs and quantities. Save and post, and the document adjusts on-hand at both ends the second it finishes.

For a homewares retailer who keeps the likes of dinnerware and serving pieces at a central warehouse, the typical pattern is to bulk-in from the supplier into the warehouse, then transfer smaller quantities to each store as needed. Reverse transfers go the other way when a store has surplus, which is common after EOFY clearance or a slow Boxing Day trade.

One trick worth knowing: Counterpoint lets you generate transfer orders from a replenishment suggestion report, and that report looks at minimum-stock thresholds and sales velocity. For Australian retailers with seasonal swings such as Melbourne Cup, Christmas, or back-to-school in late January, running that report weekly stops the warehouse-to-store flow from becoming a fire drill every Monday morning.

Syncing the transfer order with your online storefront

Posting the transfer order in Counterpoint is only half the job; the destination bin needs to be the one your ecommerce integration listens to. With most NCR Counterpoint partner setups running Magento or WooCommerce, the integration polls Counterpoint on a schedule (often every few minutes) and pulls available-to-promise quantities for each SKU at the configured web location.

The thing to watch is timing. If you post a transfer at 4:55pm AEST and the integration only polls on the quarter-hour, your men's casual shirts won't appear online until the next sync. For retailers running flash sales or limited drops, that lag matters, so it's worth confirming the polling interval and whether the integration supports near-real-time pushes.

Also keep in mind that the transfer order affects "on-hand," but available-to-promise can still be eaten by allocated quantities on open sales orders or unposted pick lists. If your online stock counts look wrong after a transfer, check the allocation tab before assuming the integration has broken.

Handling multi-site retail across Australian time zones

Running a multi-site operation from Hobart to Darwin means your team is rarely all online at once, which makes workflow rules around transfer orders more important than the software itself. A practical pattern is to restrict who can post transfers from store locations (usually only the warehouse manager or ops lead), while letting store staff generate suggested transfer orders that need a second approval.

The three-hour spread across the eastern seaboard tends to mean WA stores operate almost in isolation, so transfer orders to and from Perth often batch up at the start and end of the day. Building that batching into your SOPs avoids the situation where a Perth transfer gets missed, the store stays oversold, and a customer in Subiaco waits an extra day for a click-and-collect that could have been ready arvo.

For retailers using Australia Post eParcel or Shippit, remember that the transfer order's destination bin determines which DC the carrier routes from, not where the customer lives. If your web location is set to your Brisbane warehouse, a Melbourne customer's order still leaves Brisbane unless you've built zone-based routing into the integration.

Common mistakes when replenishing from physical stores

The most frequent error is treating a transfer order like a sale, which collapses the margin reporting on whatever was moved. Transfers are internal movements and should post at cost or zero-value depending on your accounting setup, not at retail. A surprising number of businesses only catch this during the quarterly stocktake and end up with a half-day of cleanup.

Another trap is letting store managers transfer stock between stores to "help out" without flagging the online channel. The customer's experience of a stock transfer that never reaches the web location is the same as if you never transferred at all — the listing stays out of stock. Make sure the SOP says explicitly: if the destination is a web fulfilment bin, double-check the SKU is online-active before posting.

Finally, watch for backdated transfers. Counterpoint lets you backdate the document date, which is fine for month-end adjustments, but the on-hand figures move from the post date, not the document date. For retailers running a loyalty campaign or a click-and-collect promotion starting tomorrow, an off-by-one error here can quietly undermine the launch.

Reporting on transfer orders to tighten the replenishment loop

Once transfers are flowing, the report worth living in is the Transfer Order History under Inventory Reports. It shows every movement between locations, with quantities, values, and the staff member who posted it. Over a quarter, this report tells you which stores are constantly feeding the web bin and which are net donors, which is the basis for a proper hub-and-spoke replenishment policy.

Pair that with a turnover report filtered to the web location only, and you'll see how fast ecommerce stock is moving relative to your transfer cadence. A web location turning over every 14 days with transfers posted fortnightly is a tight loop; the same turnover with monthly transfers means you'll spend half the month with gaps on the site.

For retailers who want to go deeper, the logic that drives allocation in Counterpoint isn't far removed from how service platforms manage their own stock pools. The way a reservation-style architecture holds capacity for a confirmed booking is the same pattern Counterpoint uses to hold allocated-on-order qty against a sales order before it ships.

The fastest way to internalise all of this is to run a single, real transfer end-to-end with your team watching: pick a slow-moving SKU sitting in your flagship store, create a transfer order into the web bin, post it, and time how long until the storefront reflects the new quantity.