For retailers whose stock spends a week being nowhere

Store Replenishment and Stock Transfers: Moving Stock Without Losing It

Every multi site retailer and wholesaler has the same quiet problem. Stock leaves the warehouse, and for the next two days to two weeks it exists on a docket and in nobody’s system. Stores reorder what is already on a truck. The website refuses to sell units that are sitting in a pallet cage in Adelaide. At stocktake, the difference is written off as shrinkage when much of it may never have been lost.

This page is about the plumbing that fixes it: how replenishment quantities get calculated per location, how transfer requests and approvals flow, why in transit has to be a real inventory state rather than a gap, how variances get resolved instead of absorbed, and what changes when your branches are separate legal entities rather than one.

Book an Inventory Call (03) 9003 0111

The Numbers That Matter

2 to 10 days

Transit from an east coast warehouse to a WA or NT store

Varies with carrier, service and destination, and legs this long are why in transit stock has to be visible rather than missing

3 states

Per location: on hand, in transit and available to sell

Without the in transit state, stores reorder stock that is already on a truck

2 parties

Every transfer has a sender and a receiver

Until both have confirmed, the units belong to the transfer, not to either location

No GST

On movements inside one legal entity

Registered GST branches are an exception, and between separate entities it is a supply unless both are in the same GST group

Four Decisions Behind Every Working Transfer Process

Most transfer problems turn out to be data problems. These four decisions determine whether the records match what actually moved.

Whether replenishment is pushed or pulled

Push means head office decides what each store receives, based on sales velocity, presentation minimums and a ranging plan. Pull means the store asks. Push scales, keeps ranging coherent and stops favourite stores hoarding; pull captures local knowledge that no algorithm has, like a trade customer who buys forty of one line every winter. Most retailers need both: a scheduled push for core lines and a request path with approval for everything else. What fails is having neither written down, which is how you end up with a phone call culture and an inventory ledger nobody trusts.

Whether in transit is a real inventory state

A common design fault is treating a transfer as an immediate decrement at one location and an increment at the other, or worse, as a decrement now and an increment whenever someone gets around to receipting. Stock needs three states per location: on hand, inbound in transit with an expected date, and available to sell. Get this right and stores stop double ordering, the website can honestly say two days rather than out of stock, and stocktake variances stop absorbing units that were only ever on a truck.

What a transfer does to cost and margin

A transfer costs freight and handling, and how those costs are treated shows up in your ledger. Where cost is held per location, moving units changes average cost at the receiving location, and whether freight is capitalised into stock value or expensed changes every store margin report you produce. Between separate legal entities in a group it is a supply, needing an intercompany invoice, the right tax code and an elimination at consolidation. If both entities are in the same GST group, the supply is ignored for GST, but the intercompany accounting is still needed. Decide the treatment with your accountant before build, because retrofitting it means restating store performance.

Who owns the variance when counts disagree

Sooner or later a store receipts nine of a line that was dispatched as ten. If there is no process, the difference sits in the ledger as unexplained and eventually becomes shrinkage. A working design captures the dispatch count and the receipt count separately, raises the gap as an exception with both numbers and the scans attached, and routes it to a named person with a time limit. What you learn is useful: whether you have a picking problem, a receipting problem, a freight problem or a theft problem.

The Six Parts of a Replenishment and Transfer Integration

You rarely need all six at once. Visibility of in transit stock and scanned receipting are the two that change behaviour fastest.

Suggested quantities

Replenishment calculation

Minimum and maximum levels per location rather than one national rule, driven by recent sales velocity, presentation minimums for the shelf, pack and carton rounding, and lead time to that specific site. Store clusters matter: a flagship, a regional shop and a trade counter with the same turnover need different shapes of stock. The output is a suggestion a merchandiser can adjust, not an order that fires blind.

Auditable

Store requests and approvals

A structured way for a store to ask for stock, with the reason attached, routed for approval above a threshold and against a check that the requested units are actually available to promise. Replaces the phone call and the group chat, which cost nothing until two stores are promised the same six units. Requests become documents, so refusals and priorities can be explained later.

Known quantity

Dispatch, scan and advise

Picking and packing against the transfer, scanned at carton level so the dispatch quantity is recorded rather than assumed, with a despatch advice sent ahead to the receiving site listing what to expect and when. The receiving store scans against that advice instead of counting into a spreadsheet, which is what turns receipting from a chore into a control.

Reconciled

Receipt and variance handling

Receipts confirmed by scan, partials handled properly so a split delivery does not close the transfer early, and any gap between dispatched and received raised as an exception with both counts attached. Damage and wrong item receipts get their own reason codes, because aggregating everything into one variance number hides the pattern that would let you fix the cause.

Honest promises

In transit and online availability

Inbound units visible at the destination with an expected date, excluded from what the website may sell as immediately available, and included in what a store can promise for later collection if you choose to allow it. This is where transfer data meets the storefront, and where the rules have to be explicit: inbound stock is expected and is not yet on the shelf.

Stock unstuck

Reverse and lateral flows

Store to store transfers to fill a click and collect order or complete a size run, returns of slow movers to the warehouse, and consolidation of the tail of a line into one site for markdown. These flows are usually manual and undocumented, which is why aged stock sits in the wrong postcode for a season longer than it should.

What Changes on the Ground

Task	Traditional	Integrated Properly	Notes
Replenishing a core line	Manual review, one national rule	Per location min and max	Store clusters matter more than most head offices expect, especially across regional and metro sites.
A store needs stock urgently	Phone call to the warehouse	Request, approval, allocation	The problem is that the phone call leaves no record.
Knowing what is on the truck	Nothing until it is receipted	Inbound visible with a date	This change reduces double ordering and false stockouts.
Receipting a delivery	Counted onto a printed docket	Scanned against a despatch advice	Also produces the data you need to tell shrinkage from miscounting.
Ten dispatched, nine arrive	Absorbed at stocktake	Exception with both counts	Reason codes are what turn a variance number into a fixable cause.
Filling a click and collect order	Cancelled or refunded	Lateral transfer between shops	Worth the freight on higher value lines, rarely worth it on low value ones. Model it per category.
Slow stock in the wrong store	Discovered at end of season	Flagged and consolidated	Earlier consolidation usually beats a deeper markdown later, but it needs the movement data to be trusted.
Transfer between group entities	Treated as an internal move	Invoiced and eliminated properly	Separate entities make a supply for GST purposes unless they are in the same GST group. Agree the treatment with your accountant before build, not after.

Where Transfer Processes Quietly Fail

In transit stock is invisible

If a transfer decrements the sender immediately and only appears at the receiver on receipting, units vanish from the business for the length of the freight leg. Stores reorder them, planners exclude them from availability, the website declines sales it could have made, and stocktake treats the discrepancy as loss. Model inbound as a first class state with an expected date, and show it wherever people make ordering decisions.

Receipting without scanning

A receipt confirmed by ticking a docket does not record what was actually counted. Once that tick is in the ledger you have no way to tell whether a gap came from picking, freight or the shop floor, so every variance becomes shrinkage and nothing gets fixed. Scanning at both ends is a low cost control, and the despatch advice is what makes it quick enough that staff actually do it.

Transfers between separate legal entities treated as internal moves

Many Australian groups run stores or branches under different ABNs, for franchising, partnership or historical reasons. A movement between two entities is a supply, not an internal transfer: it needs an invoice, the right tax code, consistent transfer pricing and an elimination at consolidation. If both entities are members of the same GST group, supplies between them are ignored for GST, but the invoice, pricing and elimination are still needed for the accounts. Getting this wrong shows up at BAS time or in an audit, long after the integration was signed off, and unwinding it means restating numbers people have already reported.

Nobody decided how freight and cost move

If freight is capitalised into stock value, every receiving location carries a slightly different cost for the same item and margin reports differ by store. If it is expensed, store margins look cleaner and the freight bill lands somewhere that may not be accountable for it. Both are defensible. Choosing by accident is not, because the choice shapes every store performance conversation for years.

Min and max set once and never revisited

Levels calculated at go live drift out of usefulness within a season or two as ranging, store mix and demand change. Without a review cycle, the symptoms are predictable: stores overloaded with lines that stopped selling, and constant manual overrides that quietly replace the system. Build a scheduled review with actual sell through data in front of the person adjusting them, and expect to tune rather than set.

Staff route around the system

If raising a transfer takes longer than sending a message, staff will send the message, and your movement data becomes an approximation. Treat this as a design problem. Make the supported path the fast path, put it on the device people already hold, accept a short reason instead of a long form, and make the resulting visibility obviously useful to the person doing the entering.

How Yes AI Approaches Replenishment and Transfers

Inventory states modelled before anything is built

On hand, inbound, allocated, available to sell and available to promise, defined per location and agreed with whoever owns stock accuracy. Many transfer problems come from a missing state, and no amount of extra syncing compensates for that.

Scanning that fits the way the site works

Carton level where that is enough, unit level where value justifies it, on the handhelds or phones your staff already use. We would rather have a fast scan that always happens than a thorough one that gets skipped in the last hour before close.

Built, hosted and monitored by us

The flows run on a managed cloud automation layer that we operate, with same day alerting and a record of every movement. When a receipt fails or a despatch advice does not arrive, someone knows that day rather than at the next count.

Straight advice about what your ERP already does

Plenty of ERP and point of sale platforms have competent transfer modules that are simply switched off or unused. If yours does, the honest answer is to configure and train rather than build, and we will say so. Integration earns its keep in the gaps: connecting warehouse scanning, storefront availability and a second system your ERP will never speak to.

How the Work Runs

Five steps. In transit visibility alone is typically live within a month.

Follow real stock movements

We trace a handful of actual transfers end to end, including one that went wrong, and note every point where a count is recorded, retyped or assumed. Freight legs, receipting habits and the informal phone culture all get documented, because they are what the design has to survive.

Define states, cost treatment and entities

Inventory states per location, whether freight is capitalised, how intercompany movements are invoiced if your branches are separate entities, and who owns variances. Signed off by whoever owns stock accuracy and whoever owns the ledger before build.

Specify the flows in plain English

Replenishment logic and its inputs, request and approval thresholds, dispatch and receipt confirmations, variance routing, and the rules for what the website may sell. Written so a merchandiser and a store manager can both check it.

Build, pilot in two sites, then extend

Built against official APIs with idempotent writes so a retried receipt does not double count. Piloted with two stores, ideally one easy and one difficult, before the network goes live, with the old process kept running alongside for a short overlap.

Monitor, tune levels, extend flows

Same day alerting on failures, a short exception queue for variances, and a scheduled review of min and max against real sell through. Lateral and reverse flows are usually added after the core is trusted.

FAQ

What does in transit visibility actually require?

Three things. A transfer document that exists as a record rather than a docket, so there is something to attach quantities and dates to. A dispatch confirmation that records what actually left, ideally by scan. And an expected arrival date per destination, which can start as a simple lead time table by lane and improve later. Once those exist, showing inbound units at the destination is straightforward.

Should inbound stock be sellable on the website?

Not as immediately available, and usually yes as a dated promise. If you show inbound units as on hand, you will sell them and then explain the delay, which costs more in service than the sale was worth. A safer pattern is to keep in transit out of the available number but allow it to back a clearly dated promise, a preorder or a collect later option, with the date driven by real lead times rather than optimism.

How do we decide min and max levels per store?

Start from recent sales velocity for that location, add a presentation minimum so the shelf does not look picked over, round to pack or carton quantities, and pad by the lead time to that specific site. Then cluster your stores, because a flagship, a regional shop and a trade counter with similar turnover need different shapes of stock. Treat the first set as a draft, review it against sell through after a season, and expect to tune. Any vendor who says the levels will be right at go live is guessing.

Our branches are separate companies. Does that change the integration?

Significantly. A movement between two legal entities is a supply, so it needs an invoice, a consistent transfer pricing basis, and an elimination when the group consolidates. For GST it is treated like a sale to any other customer and needs the correct tax code, unless both entities are members of the same GST group, in which case transactions between members are ignored for GST and no tax invoice is needed. It also changes who owns the stock while it is in transit, which matters for insurance and for the balance sheet at period end. This is a conversation with your accountant before design, not a configuration detail to sort out afterwards.

Can we do this without scanning?

You can move stock without scanning, but you cannot control it. Without a recorded dispatch count and a recorded receipt count, every discrepancy is unattributable and becomes shrinkage by default, so you never learn whether the cause is picking, freight or the shop floor. If handheld scanners are a step too far, start with phone camera scanning at carton level against a despatch advice, which costs little and is enough to make variances meaningful.

Is a store to store transfer worth the freight?

It depends on margin and on what the alternative is. For higher value lines, moving one unit across town to save a cancelled click and collect order is usually worth it, and so is completing a size run so the remaining sizes can sell. For low value, high volume lines the freight and labour often exceed the margin, and the better answer is a refund and a restock. Model it per category with real freight costs, then encode the rule so staff are not making the judgement per order under pressure.

Does our ERP not already do all of this?

Often it does more than the team realises, and if so the right answer is configuration and training rather than a build. Where ERP transfer modules fall short is at the edges: warehouse scanning hardware, showing inbound stock in the storefront, requests from staff who have no ERP licence, lateral transfers triggered by an online order, and reporting that crosses a system boundary. That is where an integration layer earns its place, and we will tell you plainly which side of that line your problem falls on.

Stop Losing Stock Between Sites

Book a call. We follow your actual transfers, show where the counts and the visibility break down, and give you a priced plan starting with the change that pays back fastest.