The Transfer Between Branches That Never Arrived
Stock and documents move between sites and one of them forgets. The multi-location version of a transfer in transit, where one site has recorded a movement the other has never heard of.
A transfer is the only routine in a multi-site business where the record is created twice, by two different people, on two different days, and it only means something when both halves are true. Outward at one site, inward at the other. Until both exist, there is a quantity that is neither here nor there, and it sits on somebody's conscience until it is found.
The awkward version is not the short van. It is the branch that records the movement and the branch that is never told. One system shows stock leaving. The other system has no idea anything is coming, and the goods arrive on a shelf in a state that disagrees with the records at both ends.
This is the multi-location version of a transfer in transit, and the interesting part is not the delay. It is that a transfer can be perfectly documented at the sending site and completely absent from the receiving site, which means the record looks complete to the person who made it.
A constructed exampleThe arithmetic of a transfer that does not add up
Here is a worked example we constructed for this article. The product, the quantities, the dates, and the landed cost are invented so that you can check the arithmetic by hand. Where a value appears, it is at an assumed landed cost we made up for the example, and it is not a valuation, a rate, or advice about how anything should be recorded.
A single stock item, one unit, exists at Branch A only. Branch A opens the period with 40 units on hand. On 5 April, Branch A dispatches 25 units to Branch B. Branch A's records now show 40 − 25 = 15 units. Those 25 units are, at this point, in transit: they are out of A, not yet into B, and no site is wrong.
On 7 April, Branch B receives and records 22 units. B's records show 22. Add them: 15 + 22 = 37. Opening stock was 40. The network is short 40 − 37 = 3 units.
At a constructed landed cost of ₹340 a unit, those 3 units are ₹3 × ₹340 = ₹1,020 of stock that the records place nowhere. We are not going to print what that is as a percentage of anything. The reader is already thinking it, and a rate here would compare one invented shipment against nothing.
Notice what the arithmetic does and does not prove. It does not prove the 3 units were lost. There is an innocent explanation: the van took three, they were damaged, they were returned, or the receiving count was simply short and nobody counted twice. The arithmetic only proves that the records and the physical world disagree, and that the disagreement is worth an afternoon.
The one-sided movement: recorded here, unknown there
A short van produces a quantity problem. A forgotten phone call produces a structural one, and it is far more common than a shortage.
Consider the branch that dispatches stock at the end of a busy day, hands the papers to whoever is leaving, and does not call the receiving branch. The sending site records the movement. The receiving site never knows stock is coming, so nobody puts anything away, so nobody counts anything, so nothing is recorded. On the receiving side, the stock that arrived is not in the system. It is on a shelf, or in a corner, or in the back of a vehicle, and it is invisible to every report.
This is worse than a shortage, and it fails in both directions at once. At the sending site, stock is overstated as gone: the business believes it has 15 units when it has 40, because 25 of them are standing in Branch B. At the receiving site, stock is understated as available: the business believes it has 22 when it physically has 25 and cannot sell any of them through the system, or believes it has nothing when it has a pallet it does not know about. Both sites are individually wrong, in opposite directions, and neither report shows it.
The one-sided movement is also the shape that hides best. A quantity that is short by three invites a count. A record that exists at one end and not the other invites nothing, because the sending site has a complete, valid, dated document and no gap anywhere in its own view. The person who could close the gap is the person at the other site, and they have no reason to know the gap exists.
The documents move too, and they are worse at travelling
A stock movement has a paper equivalent, and the paper travels worse than the goods. A delivery challan is written at one site, signed by a driver who may not be the person who receives, and handed to somebody who files it in a drawer at the other end. The goods are counted at the moment of unloading. The document is filed three days later, if it is filed.
The result is a common and awkward pattern: the document lives at the receiving site, the stock record lives at the sending site, and the person who needs both to answer a question is neither. When somebody later asks why Branch A's stock fell by 25 on 5 April, the answer requires a document that is in a drawer at Branch B. When somebody asks what Branch B received on 7 April, the answer requires a system that never learned about the movement.
There is a further trap in this, and it is a trap of naming. The same physical item is frequently known by two names at two sites. Branch A calls it a 500 ml pack of one formulation. Branch B calls the same thing a small pack, or by a supplier code, or by a name someone typed into a quick-add field at 6pm. Two items with two names is not a data-quality complaint. It is the ordinary, predictable consequence of asking two sites to name things independently, and it is the reason a transfer between them can be recorded against two different item records on two different days.
The vocabulary for all of this is written out in the [inventory and commerce glossary](/glossary/
Four shapes this failure takes
The table is illustrative. It is a way of naming what you are looking at so that two people at two sites can talk about it, not a diagnostic tool. Every one of these looks like something else until you ask the question in the middle column.
Illustrative: four transfer failure shapes and the question that identifies each
| Shape | What you see | The question that settles it |
|---|---|---|
| Legitimate in transit | Outward at A, nothing at B, for a day or two. | Does the sending record name a person who is expecting a receipt, and does that person have a way to raise it if nothing arrives? |
| One-sided movement | Outward at A, nothing at B, for a week. Stock may physically be at B. | When was the receiving branch last told that anything was coming, and by whom? |
| Mismatched quantity | Outward at A for 25, inward at B for 22, both recorded correctly. | Was the receiving count done once by one person, or counted and recounted by two? A 3-unit gap on 25 is a count question before it is a theft question. |
| Same thing, two names | Both halves recorded, no gap in quantity, and the network total still disagrees. | Are the two item records the same physical item, or two records that happen to share a label at one site? |
The check that closes the class of problem
Individual transfers are worth fixing. The class of problem is worth preventing, and the prevention is one line of arithmetic that any site can perform without any software at all: across the network, opening stock plus receipts minus issues minus transfers out minus adjustments must equal closing stock. If that identity does not hold for a site, the site's own records are wrong before any transfer is even considered.
Then the transfers themselves need to be a closed loop rather than a notification. A movement is not done when it leaves. It is done when the receiving site has recorded an inward movement against the same item, and the two records can be put next to each other and shown to agree on item, quantity, and date window.
In NoxOrigin, stock movement and purchasing live in Commerce. A transfer is a movement, not a purchase and not a sale: it does not create a vendor bill and it does not create customer revenue, and a system that models it as either of those will produce a network total that is wrong in a way no amount of consolidation can repair. The practical consequence is that receiving has to be a real record created at the receiving site, by somebody who knows they are receiving, rather than an assumption that stock arriving is stock received.
One thing this system deliberately does not do is combine things on its own. Where two records look like the same customer, or where a duplicate looks likely, detection flags candidates and a human reviews them; nothing merges automatically. That matters here more than it does anywhere else, because a quietly merged item record or customer record at a two-site business is indistinguishable from a tidy database until the month it is not.
Illustrative: making a transfer a closed loop between two sites
- Decide who is allowed to dispatch and who is allowed to receive. These are two permissions, not one, and a business where the same person holds both at both sites has no loop, only a habit.
- Make the receiving record a record, not a notification. Somebody has to enter an inward movement with a quantity, or the transfer is not finished by any measure that will help you later.
- Agree the window. A transfer that is outstanding beyond a set number of days is an exception somebody has to look at, with a name against it. Without a window, in-transit is a permanent state.
- Agree who owns an outstanding transfer at the end of the period. Not the sending site and not the receiving site by default, but a named person, because an unowned in-transit quantity is the same as a missing quantity with extra steps.
- Reconcile the network identity at each period end: opening plus receipts minus issues minus transfers out minus adjustments, equal to closing, per site and in total. A site that fails its own identity cannot be trusted to receive anything.
- Check that item naming is decided once. If two sites are allowed to name items independently, expect two names and plan the review for it, because the naming will not be the problem that shows up, the arithmetic will be.
- Keep the paper with the side that has the gap. If the document is in a drawer at the other site, the site holding the mismatch cannot resolve it without a phone call, and the phone call is the thing that was supposed to stop being necessary.
- On tax treatment, ask your own chartered accountant. Whether a movement of goods between two branches of your business is a supply in the sense the law means, and how it should appear, is not a question this article answers, and it is not a question software should answer for you.
The one-line version.
- A transfer is recorded twice: outward at one site, inward at the other. Until both exist, the quantity is between sites.
- The worst version is not short. It is documented at one end and absent at the other, so the sending site has no visible gap.
- Stock movement and purchasing live in Commerce. A transfer is neither a purchase nor a sale.
- Duplicate detection flags candidates; a human reviews. Nothing merges automatically.
- Tax treatment of an inter-branch movement: ask your chartered accountant.
Where this sits with the rest of the multi-location problem
A transfer is a record that crosses a boundary, which makes it the clearest example of a wider question: what is supposed to happen when a record moves between two sites that are configured differently. The companion articles in this cluster are worth reading alongside it.
The [multi-location closing and exception review](/blog/the-branch-that-closes-its-books-differently) is where an outstanding transfer shows up as an exception in a period close, and where the review learns to distinguish a recurring exception from a site that simply closes differently. If two branches are not producing comparable numbers, the transfer exception is often the visible symptom of a larger disagreement about the business day itself.
That disagreement is the subject of [two branches, two sets of numbers](/blog/two-branches-two-sets-of-numbers), where the two sites measure the same day differently and the total hides it. The permission and discount-rule version of the same problem is [the branch that closes its books differently](/blog/the-branch-that-closes-its-books-differently), which is relevant here because a receiving site with different permissions is a receiving site that records things differently. And whether two sites should be in one system at all, particularly when the item naming and the customer records are not actually shared, is the honest test in [when two locations are really two businesses](/blog/when-two-locations-are-really-two-businesses).
For the broader operational framing, the [multi-location business management](/multi-location-business-management-software) page describes how sites are held apart and consolidated, and [multi-location billing](/multi-location-billing-software) covers the billing side of the same arrangement. Neither of them claims that a transfer closes itself.
Frequently asked questions
How do I find transfers where one site recorded a movement and the other never did?
Run the network identity at period end: opening stock plus receipts minus issues minus transfers out minus adjustments, equal to closing stock, per site and in total. Then list every outward movement that has no matching inward movement beyond your agreed window, and treat each of those as an exception with a name against it. The one-sided movement is the one that will not show up in a per-site report, because the sending site has no gap of its own.
Our two sites name the same product differently. Is that a data problem?
It is the predictable result of letting two sites name items independently, and it is worth fixing deliberately rather than complaining about. Decide the item names once, keep them in one place, and expect a review period where existing records are reconciled. Where a duplicate is detected, candidates are flagged and a person reviews; nothing merges automatically.
Should a stock transfer between branches create a purchase or a sale?
No. A transfer is a movement, not a purchase and not a sale. It should not create vendor billing or customer revenue, because a system that treats it as either will report a network total that is wrong in a way consolidation cannot repair.
How is a transfer between two branches of our business treated for tax?
Ask your own chartered accountant. Whether a movement of goods between branches of one business is a supply in the sense the law means, and how it should appear, is a determination we do not make and this article does not attempt. NoxOrigin does not file GST returns or any other statutory return.
What if the receiving count is short?
Count it again with a second person before treating it as a loss. A short receiving count on a single-person receipt is more often a counting question than a missing-stock question, and the two lead to very different conversations.
Sources and further reading
- NoxOrigin: inventory management for small business — multi-location stock, adjustments, and movements in Commerce
- NoxOrigin: multi-location billing — location-aware invoices, staff access, and stock transfers
- NoxOrigin: inventory and commerce glossary — the vocabulary behind a counter that can be reconciled
- Institute of Chartered Accountants of India