Keep customer-owned stock separate inside a shared warehouse

Two clients use SKU code A100. Client A's case contains twelve units, while Client B's case contains ten. The warehouse stores both in the same building and an integration maps the code without the client. The total stock report looks plausible until a receipt is converted using the wrong pack size.

Protect customer-owned stock by keeping owner, item identity and unit mapping together at every handoff. A customer column in a report is too late if the allocation engine has already treated the stock as one interchangeable pool.

Define the identity before deciding the layout

Use an internal item identity mapped from the combination of client and client item code. Add the packaging and unit version where conversions can change. Record ownership separately from physical custodian, billing customer and delivery consignee; those parties need not be the same.

Microsoft's external-ERP warehouse guidance discusses inventory ownership and source-system integration. Use the documented model supported by the deployed system, with an explicit mapping to each client's records. Microsoft Dynamics 365 — Integrating warehouse management with an external ERP

Agree who may create or change a mapping. If a client reuses an old SKU code for a new pack, the integration should flag the change rather than applying the old conversion to new receipts. Store effective dates and the source authorisation.

Owner identity must survive returns, adjustments and transfers, not just normal receipt. A manual movement screen that defaults to the last-used customer can undo an otherwise careful interface.

A shared code with two different quantities

In this illustrative warehouse, both customers send ten cases labelled A100.

Total custody is twenty cases and 220 eaches, but the eaches are not automatically a common saleable product. Client A may allocate only its 120 and Client B only its 100, subject to their own reservations and holds.

Using Client A's conversion for both receipts would record 240 eaches, overstating custody by twenty. Using the correct total 220 but losing ownership would still leave an unsafe stock pool.

Now Client A orders 130 eaches. Its shortage is ten. Client B's available hundred does not remove that shortage unless there is an explicit, authorised transaction changing ownership or creating an agreed fulfilment arrangement. A supervisor selecting Client B's bin is not a substitute for that commercial and system record.

The operation should retain Client A's shortage, notify its planner and prevent allocation from Client B. If an approved ownership transfer is later allowed, record the parties, quantity, item equivalence, valuation treatment and linked source and destination transactions before releasing the allocation.

Decide how physical and logical controls work together

Dedicated zones make ownership visible and reduce some selection errors, but they consume space and do not prevent a wrong system mapping. Shared zones can use space more flexibly, but require reliable handling-unit identification, location rules and work confirmation.

Evaluate the combination against the product, contract and site's approved handling requirements. Do not infer that physical sharing is allowed merely because the WMS supports owner dimensions. Some goods or agreements require additional separation.

An overflow area is a frequent failure point. If it cannot enforce the same identity checks, the warehouse has created an uncontrolled exception rather than extra capacity. Include overflow and temporary staging in the review.

Carry ownership through every exception

A damaged unit remains the same owner's stock while its status changes. A count adjustment needs the owner and location; a balancing adjustment across clients would conceal two distinct errors. A return without a reliable original reference belongs in an unidentified-custody queue until an authorised reviewer resolves its owner.

A replacement barcode should resolve to the same handling unit when the physical unit is unchanged. Printing a fresh label must not make the old one valid for a different client's stock.

The client portal needs the same boundaries as warehouse execution. Restrict downloads, document previews, exports and API actions by owner and role. OWASP identifies object-level authorisation failures when an API trusts a supplied record identifier without checking access. OWASP — Broken Object Level Authorization

Use approved test identities and fixtures to demonstrate that Client A cannot read or alter Client B's receipt, even when the identifier is known. Check bulk exports and attachments as well as the primary screen.

Prove the boundary with difficult transactions

Prepare a test set containing identical SKU codes, different pack sizes, an unidentified return, a cross-zone replenishment and an owner-specific hold. Include a request for more than one client's available quantity. The expected result must be shortage or approved exception, not automatic borrowing.

Reconcile by owner, item, unit, location and status at a common cutoff. A combined total across clients is only a custody cross-check. It cannot prove that each client's records are right.

Measure owner-mapping exceptions, prevented wrong-owner actions and unresolved unidentified stock. Investigate every incorrect ownership assignment; a high overall transaction success rate does not offset one client's goods being supplied for another.

For a shared-warehouse review, start with the client master keys, unit conversions and the screens where staff may override ownership. Those boundaries often matter more than adding another customer filter to the report.

Keep each client's entitlement visible

A shared warehouse works when common physical resources do not erase separate inventory rights. The owner identity needs to remain intact through the ordinary transaction and the awkward correction.

Next actions

1. Map client codes to owner-qualified internal items and packaging.
2. Trace receipt, allocation, return and adjustment screens for lost owner context.
3. Test shortages and cross-client access with authorised sample data.
4. Agree the approval and transaction path for any permitted ownership transfer.