Why transfers go wrong.
A branch-to-branch transfer is two events, not one. The source branch ships and the destination branch receives. Most cheap POS systems treat the transfer as a single instant event, which means if the truck takes three days, your inventory is double-counted for three days.
A correct transfer system has three states: shipped, in-transit, received. Stock leaves the source on ship and arrives at destination only on receive. Anything in-transit is its own bucket, not floating between two branches.
The three-state transfer model.
When the source branch ships 50 units, source stock goes from 250 to 200, and a transit ledger of +50 appears. When the destination receives 48 units (two damaged), destination stock goes up by 48, transit ledger goes to zero, and 2 units land in a Damaged Goods account.
In Nonari every transfer creates a TransferOrder with shipped quantity and received quantity as separate fields. Transit is a real account on the balance sheet. The destination branch can flag short or damaged items at receive without breaking the source branch numbers.
- Source branch: stock decreases on ship event
- Transit account: stock increases on ship, decreases on receive
- Destination branch: stock increases on receive event, not ship
- Variance (damaged, lost) goes to a separate account at receive
Cost transfers correctly with weighted average.
When you transfer goods between branches, the cost goes with them. If Berlin bought 100 shirts at €8 each (WAC = €8) and ships 50 to Munich, Munich now has 50 shirts at €8 cost basis, not at the latest purchase price or some made-up number.
If Munich already had 30 shirts at €8.50 WAC, the new WAC after receiving 50 at €8 is ((30 × 8.50) + (50 × 8)) / 80 = €8.19. The system has to do this math. If you are doing it in a spreadsheet, you are wrong about half the time.
When a transfer crosses tax jurisdictions.
In most VAT regimes, transfers between branches of the same legal entity are not taxable events. But transfers between separate legal entities (separate VAT numbers, separate Tax IDs) are sales. Many chain retailers operate a separate legal entity per country for VAT reasons, which means cross-border transfers are sales with VAT.
Get this wrong and your tax authority will treat your inter-branch transfers as undeclared sales. Get it right and you produce a tax-compliant invoice for each cross-entity transfer with full traceability. Configure your POS to know which branches share a Tax ID and which do not.
The receive-without-ship problem.
Sometimes Munich receives goods that Berlin never marked as shipped — driver picked up an extra box, or warehouse staff did not log the outbound. Your destination scan-in shows stock that has no source. Resist the temptation to ignore the source side.
A receive without a matching ship is a reconciliation event that needs investigation. Either the source missed a shipment (fix on source side) or this stock came from somewhere else (purchase order, return). Letting the destination system absorb mystery stock is how you lose audit trail.
Stock-take across branches without a shutdown.
A 12-branch retailer doing a year-end stock count traditionally shuts every branch for a day. That is €40,000-80,000 in lost sales. The modern way is rolling stock-take: one branch counts on Monday, another on Tuesday, none of them shut.
For rolling stock-take to work, transfers must be frozen during the count window for the counting branch. Otherwise a transfer-in mid-count throws off the numbers. Most POS systems do not enforce this — yours should.
The reorder-from-branch trap.
Your Berlin Mitte branch is out of a hot SKU. Berlin Charlottenburg has 40 units. Instead of asking the supplier (4-day lead time), the branch manager calls Charlottenburg and asks for 10 units. Great for the customer, terrible for the data.
These informal transfers are how branch numbers diverge from system numbers. Make every transfer a system transaction even if the operational decision was a phone call. Nonari has a quick-transfer screen with two clicks: source branch, destination branch, items. No back-office app needed.
Reporting that shows you reality.
The reports that prevent transfer chaos: per-branch in-stock by SKU, in-transit by SKU, received-this-month by source, transfer variance (shipped minus received) by month and route. If any of these are missing in your POS, your real inventory position is unknown.
Look at transfer variance monthly. If Berlin-to-Munich consistently shows 2% shrinkage, that is either bad packing, theft in transit, or a counting error pattern. Two percent of €400,000 in transfers is €8,000 per year. The report pays for itself.