Stock moving between warehouses is counted in both places

A transfer has three custodies, not two locations

During a transfer, every unit is in one of three states: still at the origin and not yet released, released from the origin and in transit, or received at the destination. The double count appears when systems or reports treat the in-transit state as belonging to both ends at once — the origin still showing the units because the transfer is not 'finished,' and the destination already showing them because the transfer was 'created.' Both screens can look authoritative while describing the same physical units twice.

Shopify's transfer workflow makes the intended separation explicit: drafting a transfer, committing stock at the origin, displaying it as incoming at the destination, and receiving it are distinct stages, and received inventory is what becomes available at the destination. Incoming is a visibility state, not an availability state. Note the limit of the documentation: a transfer status is not physical proof of receipt, so the reconciliation ends at event records and counts, not at screen labels.

Anchor the reconciliation on one transfer's identity

Do not start from location totals; totals are where the double count hides. Start from a single transfer record: its transfer reference, the product and quantity it carries, its origin and destination, and its current stage with timestamps. If your operation moves stock through several transfers for the same product in the same week, reconcile each transfer separately before summing anything.

For that transfer, write down what each system currently claims: the origin's available and committed figures for the product, the in-transit or incoming quantity shown anywhere, and the destination's available figure. Disagreement among those claims is the finding. Averaging them, or trusting whichever screen a manager opened first, converts a traceable discrepancy into invisible error.

Compare release, transit, and receipt in order

Walk the transfer's timeline. First, the origin release: did the origin commit or deduct the units, and when? Shopify's model commits origin stock as part of processing the transfer, so after that point the units should no longer be sellable from the origin. Second, the in-transit quantity: what does the transfer record itself say is moving, and is that quantity appearing as available anywhere it should not? Third, the destination receipt: is there a receiving event, created at the time, recording what actually arrived and was counted?

The availability rule follows the events. Units not yet released remain origin stock. Units released but not received belong to the transfer — visible as incoming, allocatable nowhere. Units received become destination stock. If a location's available figure violates that rule, the correction targets the specific claim: an origin count never decremented, a destination count incremented at creation instead of at receipt, or a report that adds incoming units into on-hand.

Classify discrepancies and name their owners

When received quantity differs from released quantity, classify before adjusting. A documented partial receipt leaves the remainder open on the transfer as still in transit or still owed. A receipt with no matching physical count is an unverified event, and the units stay unresolved until someone counts. Units neither received nor still recorded in transit are a loss investigation, which the inventory owner opens — not a silent write-down at whichever location complains first.

Ownership is divided. Each warehouse lead verifies the physical counts at their own site. The inventory owner reviews the records for both locations together and authorizes adjustments to recorded availability, correcting only what the evidence proves wrong: a one-sided error gets a one-sided correction, and a record that checks out is left unchanged. If an integration between the warehouses is double-writing movements, the integration owner repairs it after confirming what it actually posts.

Keep reports honest after the correction

The standing safeguard is structural: reports that sum availability across locations should exclude in-transit quantities or show them as a separate line, so the business can see stock in motion without selling it twice. Where the storefront draws availability from more than one location, confirm which pool each location feeds before assuming a transfer will restore sellable stock at the selling location on a particular day.

If the double count traces to how the storefront, warehouse systems, or their integrations are configured and you want that concern scoped, a Prism consultation can discuss the setup you describe. Summarize the transfer flow and the discrepancy without internal exports or credentials, and confirm scope, responsibilities, fees, and terms before any work begins.

Transfer custody reconciliation

Complete one sheet per transfer. Each quantity must cite its event record and date; a screen status without an underlying event stays unverified. The availability row is the decision output and must follow the events, not the labels.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.