A warehouse manager at the Coventry site dispatched 480 cartons of flexible packaging to the Bristol production line on a Tuesday afternoon. The driver took the paperwork, the forklift loaded the truck, and the stock was marked as gone from Coventry in the inventory sheet. Bristol expected the shipment on Wednesday morning. By Thursday, nobody could tell you where the 480 cartons were. Not lost, exactly. Just not yet received, not yet counted, not yet owned by anyone in the system. On paper, the stock had already left Coventry. In reality, it was on a loading dock somewhere in the middle of the country, waiting for someone to confirm it. Bristol scheduled a production run assuming the packaging was available. Coventry dismissed a low-stock alert assuming the dispatch had cleared. Neither was correct, and nobody knew.
This is phantom inventory, and it is the single most common failure mode in multi-site warehouse operations. It happens when transfers are treated as one event instead of four. Visit falorb.com if you have ever lost a day of production because a shipment was in limbo between two systems.
Why Single-Event Transfers Break Down
The simplest way to move stock between locations is to subtract it from the source and add it to the destination in one step. That model works when every transfer is instantaneous and guaranteed, which is to say, never. In a real multi-site warehouse operation, a transfer passes through at least three hands after creation. Someone authorizes it. Someone physically picks and dispatches it. Someone receives and counts it. Each of those actors exists in a different place and acts at a different time. Compressing all of that into a single inventory adjustment erases everything that happens in between.
The consequences accumulate quietly. Stock that has been approved for transfer gets picked by another order because the system does not know it is spoken for. Stock that has been dispatched gets counted as available at the destination hours or days before it physically arrives. Stock that arrives short gets reconciled silently, with no record of who noticed the gap or when. Over a quarter, these small gaps compound into the kind of inventory drift that surfaces during the annual count and cannot be explained. Proper inter-site transfer management has to acknowledge that the movement of physical goods takes time, and the system has to represent that time accurately.
The alternative is a transfer state machine, a model that treats every transfer as a workflow passing through explicit stages, each with its own rules about what the stock counts as and who can act on it next.
The Four States That Map to Reality
A transfer state machine reflects what actually happens on the ground. The pending state captures the intent: someone has requested that stock move, but no physical action has been taken and no stock has been committed. The approved state captures authorization: a manager has confirmed the transfer is valid, and the stock is now reserved at the source, which means it cannot be used by another order even though it has not yet moved. The dispatched state captures the physical departure: stock has been deducted from the source and is now in transit, owned by the transfer itself rather than by either location. The completed state captures arrival: the destination has confirmed receipt, stock has been added, and the transfer closes out.
Two alternate paths handle the things that actually go wrong. A rejected state lets a pending transfer be declined with a mandatory reason, so the request does not disappear silently. A flagged state handles the case where received quantity does not match dispatched quantity, freezing the transfer until someone with authority resolves the discrepancy on the record.
Each transition between states is an event with an actor, a timestamp, and a change to the underlying stock. The transfer does not skip states. You cannot mark something as dispatched if it has never been approved. You cannot complete a dispatch that does not exist. These constraints are not bureaucratic. They are the reason the inventory numbers stay correct over time.
Reservation at Approval: The Quiet Hero
The most underappreciated step in this workflow is reservation at approval. When a transfer moves from pending to approved, stock is not yet physically gone from the source, but it is committed. That commitment has to be visible to the rest of the system, because otherwise a production order at the source location might try to consume the same stock that is about to be shipped out.
A good inter-site transfer management system separates available stock from reserved stock at every location. Reserved stock counts as present but unavailable. When a production supervisor checks material availability for a run, reservations are deducted from the quantity on hand. When the restock intelligence engine evaluates whether a location has surplus, reservations pull the surplus down. This is the same principle that underlies accurate available-to-produce calculations. We wrote about that principle in detail in the real meaning of the available-to-promise metric on the factory floor, and the logic carries directly into transfer reservations.
Without reservation, approved transfers create a race condition. The first order to grab the stock wins, and the transfer that was approved yesterday finds itself short of material today. With reservation, approval is a binding claim on inventory, and every downstream calculation respects it.
Transit Stock as Its Own Category
Once a transfer is dispatched, the stock has left the source but has not arrived at the destination. For some period, ranging from minutes on a campus to days on a long-haul shipment, it belongs to neither location. This transit stock needs to be a first-class concept in the system, not an implicit gap between two movements.
When the state machine marks a transfer as dispatched, the stock is deducted from the source and tracked as in-transit inventory associated with the transfer itself. Reports that roll up organization-wide inventory can include transit stock explicitly, so the total count reconciles. Reports that show location-level availability can exclude it, so operators do not commit to production runs based on stock that has not arrived. This dual view is impossible to produce if dispatch and receipt are a single operation.
Transit stock also shows up in alerts. If a transfer has been in the dispatched state for longer than the expected transit time, the system surfaces it for investigation. Someone needs to find out whether the shipment is delayed, misdelivered, or lost. The flagged state handles mismatches at receipt. The overdue transit alert handles shipments that never arrive to be received at all. Both failure modes are invisible in a single-event transfer model.
Receipt with Discrepancy Flagging
The final state transition is where accuracy either holds or breaks down. The receiving team opens the shipment, counts the cartons, and either confirms the dispatched quantity or reports a variance. A robust inter-site transfer management system supports partial receipt as a normal case, not an exception. If 480 cartons were dispatched and 478 arrive, the operator enters 478. The transfer does not close out quietly. It transitions to a flagged state, and both the dispatch record and the receipt record remain intact for review.
Flagging matters because discrepancies are signals. A persistent pattern of short receipts on shipments from one supplier, one carrier, or one source location points to a specific cause that can be fixed. Silent reconciliation, where the receiving operator adjusts the number to match the system or the dispatching operator updates the dispatch to match the receipt, destroys the evidence needed to identify that pattern. The flagged state forces the question onto the record. Someone with authority decides whether to resolve the transfer as short-received, as miscounted at dispatch, or as requiring further investigation. The resolution itself becomes part of the transfer history.
This entire model depends on the underlying ledger being trustworthy. If stock quantities could be edited directly, flagged transfers would be resolvable by changing a number somewhere else and calling it even. The reason the state machine works is that it sits on top of an immutable movement ledger, where every state transition creates a permanent record. We covered the ledger principle in depth in why every movement matters and the immutable audit ledger that makes it possible, and transfers are the clearest case where that principle earns its keep.
Phantom Inventory Is a Modeling Problem
The Coventry-to-Bristol scenario that opened this post is not a process failure or a discipline failure. It is a modeling failure. The system those warehouses were using treated a transfer as a single event, and the space between dispatch and receipt was invisible by design. No amount of operational rigor can fix a model that erases the thing it needs to track. Once a proper state machine replaces the single-event model, the same team behaves correctly because the system now gives them somewhere to put the information that was previously falling on the floor. Approved transfers show up as reservations against source stock. Dispatched transfers show up as transit inventory until received. Flagged transfers surface for resolution instead of quietly being squared away. None of this requires more effort from the warehouse team. It requires a system that represents the work they are already doing.
Inter-site transfer management is one of the highest-leverage places to eliminate phantom inventory, because the flow of goods between locations is where the gap between paper and reality is widest. Companies that move from spreadsheet-based transfer logs to a proper state machine typically see inventory accuracy improve within a single cycle count, not because anyone is working harder, but because the system has stopped hiding the truth. The principle generalizes. Any operation where stock changes hands and changes hands again benefits from treating each handoff as a first-class event with its own state. That is the shape of a model that matches the work.
FalOrb helps manufacturers eliminate phantom inventory with an inter-site transfer state machine, reservations at approval, transit tracking, and an immutable movement ledger under every state change. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation.