Running a warehouse full of other people's stock

What changes when the stock in your building is not yours?

Ownership stops being an assumption and becomes a field. In your own warehouse every carton is yours, so no movement has to record whose it is. In a third-party warehouse every movement does, and the rest follows from that.

The shapes that matter here are familiar. A forwarder at Sihanoukville · Port holds cleared stock for one importer and stock still under customs control for another, in the same building and sometimes on the same rack run. Phnom Penh · Node 3 takes the same goods a week later for national distribution, and consignments cross at Bavet and Poipet on the way to and from Vietnam and Thailand. In all of those moves the goods change location and change custody without changing owner. A system that reads a location change as an ownership change is wrong in its first week.

The commercial change is the sharpest one. Your revenue is no longer margin on goods sold, it is fee on work performed and space occupied, so the movement log stops being a bookkeeping by-product and becomes the thing you invoice from. A picked line nobody recorded is a picked line nobody charged for.

How do you keep one client's stock separate from another's in one warehouse?

Owner is a field on every movement and every balance, enforced by the system. It is not a convention about which aisle a client's pallets live in. Locations move, and ownership does not.

The convention works until the week it does not. Client A has rows 1 to 12, Client B has rows 13 to 24, everybody knows it, and then a peak inbound arrives bigger than the space you set aside and four pallets go into row 11 because row 11 was empty. Nothing is lost. But the only record of who owns those four pallets is now the memory of the person who put them there. If both clients hold the same item, a 24 x 330ml case of the same drink, the error never shows up in a count: the building total is right and the split between two owners is wrong, which is the worst kind of wrong, because it reconciles.

Stamping owner on the movement fixes it at the source. A receipt records owner, lot, quantity and location together, so a pallet in row 11 is still Client B's pallet whether or not the slotting plan was respected. Location becomes an operational fact rather than a legal one, and that permits what a convention forbids: mixed pallets, dynamic slotting, one bulk location holding the same SKU for two owners with the quantities kept apart in the record.

The read side deserves as much attention as the write side. A client login should be scoped to one owner at the point the query runs, so a screen, a report, a search box and a downloaded file all return the same restricted set. Test it before you sign: ask to be logged in as one client, then try to reach another client's data through a URL, a filter and an export. A client who can see another client's stock is not a support ticket, it is a lost contract, and word of it travels to the clients you still have.

Scanning keeps the owner stamp honest on the floor, because a scanned putaway records the owner without asking anyone to remember it. We should be straight about where that stands: there is no inventory handheld Scale can put in your hands today, and offline scanning, where a device keeps working through a dead spot in a racking aisle and syncs when it returns, is the architecture the build is written against rather than a shipped demo. How barcodes actually get onto Cambodian stock covers what the labels have to carry before any of it helps.

Do you bill by movement, by space, or by both?

You bill by both, because handling pays for the work and storage pays for the space. They behave differently: handling is spiky and follows the client's trade, while storage accrues quietly whether anything moves or not, and a rate card that prices only one of them leaves the other unpaid.

The rule that saves you is that the billing record and the stock record have to be the same record. Two systems reconciled at month end will not do, and neither will a tally the supervisor keeps in a book beside the stock system. There is one posting, created by the warehouse because it has to exist before the goods can move, and the invoice line is derived from it afterwards. The moment those become two records they disagree, and they disagree in front of a client who has just been asked for money.

The disagreement is rarely fraud. It is the ordinary drift of two logs kept by different people for different reasons. The picker confirms the lines that were on the sheet, and the billing tally is higher because two more were added by phone and never went back onto the sheet. Neither number is a lie, nobody can prove which is right a month later, and the argument is settled by whoever is more stubborn.

Storage repays the most attention, because it is billed on a state rather than an event. You need an on-hand balance by owner that is readable as at a moment, not only as of now. When a client queries a storage line weeks later, the answer should be a stored balance at that timestamp with the movements either side of it, not a recollection.

What reporting does your client expect to see without phoning you?

Your client expects their on-hand, their movements, their ageing and their open orders, readable at any hour, showing nobody else's anything. Most of the calls you take in a week are a client asking a question your system already knows the answer to.

Ageing is the report clients ask for most and the one operators most often lack. It says how long each lot has been in the building, which your client needs for working capital and you need in order to defend a storage invoice. It also drives dispatch order on anything with an expiry date, where the first-expired-first-out picking rule sends the earliest expiry out first regardless of when it arrived. Keep that apart from the cost-flow rule your client's accountant uses: first-in-first-out decides which cost leaves the books, FEFO decides which pallet leaves the door, and the two are independent of one another. What lot and expiry tracking has to record sets out the shape of it.

Resist the temptation to build two service levels, even though a Cambodian 3PL client base often looks like two different businesses. The regional arm of a multinational arrives with a mandate, a systems team and an integration request. A small importer bringing in the occasional container arrives with a phone number. Give both the same portal, scoped by owner, and let the smaller client use only the parts they want. The alternative is a manual process you personally maintain for half your revenue, which caps how many clients you can carry.

Counting is the other thing clients want sight of, and in a shared building it is not optional, because you are the one who will be asked to explain a difference in someone else's goods. Rolling counts by location, scheduled so every client's stock is touched over a cycle, give you a variance you can trace to a week instead of a year. Cycle counting instead of the annual shutdown sets out how that runs.

What happens at the handover, when a client leaves?

They take their data with them, and that should be an export rather than a negotiation. Every client eventually leaves, moves to a competitor or brings the warehouse in-house, and the contract worth having is the one that survives that ending in good order.

A departing client is owed four things in a machine-readable file: the on-hand at handover by item, lot, expiry and location; the movement history for the period you held the goods; the billing records tied to those movements; and any master data of theirs you have been maintaining, item codes, dimensions, barcodes, delivery addresses. Owed is the right word. It is their stock and their trading history, and your system holds it as a custodian.

Friction here is often accidental. Data that leaves only as a PDF, an export that has to be requested and quoted for, a movement history that stops well short of the period you actually held the goods: each of those turns an ordinary ending into a bad one, and bad endings get discussed. Cambodian logistics is a small world, and the forwarder you hand over to badly this year is quoting against you next year.

The physical side has its own rule. Do a joint count on the day, signed by both sides, against a system balance printed before anyone starts, and post the difference as an adjustment with a reason on it before the goods leave. A handover with no joint count is a dispute waiting for a quiet month.

What should you ask a vendor before signing?

Ask these six questions, and take the answer a vendor can demonstrate on a screen over the one written in a document. Ask them of us as readily as of anyone else. A vendor who would rather answer in a slide deck than in the software has told you something already.

1. Show me a movement record and point at the owner field. If ownership is a location naming convention, or a customer on the order rather than on the stock, that is your answer.
2. Log me in as one client, then let me try to reach another client's data through a filter, a saved report, a search and a downloaded file.
3. Produce this month's invoice for one client and trace every line back to the movement it came from. Ask what happens when the two disagree.
4. Show me one client's on-hand as at the last day of last month, not as of today. A system that cannot answer that cannot defend a storage charge.
5. Export one client's entire history now, in this meeting, in a format I can open. Get the cost and the turnaround written into the contract.
6. Tell me what is built and what is specified. Anything shown on a slide rather than on a screen goes on a list, with a date against it, before signature.

Four sites and the stock on the road

On-hand stops being one number and becomes four: Phnom Penh · Node 3 as the central DC, Sihanoukville · Port for import and bond, Battambang · Depot upcountry, Kampot · Cross-dock for goods only passing through. A company total is still the right number for valuation. It is the wrong one for deciding whether tomorrow's run can be loaded.

The figure most systems lose is the one on the truck. A transfer from the central DC to Battambang is no longer stock at Node 3 the moment it is loaded, and it is not stock at the depot until someone there receives it against the transfer.

For the hours it spends on National Road 5 it belongs to neither end, and it has to exist in its own right: an in-transit quantity with a source, a destination, a dispatch row and a receipt row. Skip that state and you are left choosing between two wrong answers.

Decrement on dispatch and Battambang cannot see what is coming. Increment on dispatch and the depot can sell packs that are still on the road. Neither survives the moment a discrepancy appears and someone has to work out where the stock went. A warehouse management system that cannot show what is in transit is a single-site stock list with four filters on it.

The second distinction is between what you hold and what you can promise. A case allocated to tomorrow's delivery run is still physically in the building. It is countable, it belongs in the valuation, and it is not sellable. Show one number and a salesperson takes an order against stock the loader is about to put on a truck, and the argument that follows happens in front of a customer. Committed and available are two columns rather than one, and every allocation is the row that moved a pack from the second column to the first.

Reorder points belong to the item and the site together, not to the item alone. The same SKU needs a different trigger in each place because the sites do different jobs, and stock is counted in packs (a 24 × 330ml case is one thing you count, not twenty-four), so the trigger is set in packs too, which is also the unit the person holding the clipboard is looking at.

The rule itself is plain: it reads movements that have already been posted and raises a flag when the level is crossed. Where the levels themselves come from is how supplier lead times set them on the buy side.

• Phnom Penh · Node 3 holds the depth. It absorbs a container and every other site draws from it, so its trigger has to cover its own picking plus the days a replenishment spends reaching the other three.
• Sihanoukville · Port holds goods that have landed but are not all yours to sell yet. Bonded and cleared are two states of the same pack, and one combined on-hand figure across both will overstate what you can promise a customer.
• Battambang · Depot is far enough that a mistake costs a day. A replenishment that leaves short arrives too late to fix before the weekend, which is why the in-transit figure matters more upcountry than it does across town.
• Kampot · Cross-dock is a place stock passes through rather than sits in. Days of cover is the honest metric there, and a level that would read healthy at the central DC reads as a blockage at a cross-dock.

Frequently asked questions

Can I run a 3PL on an ordinary inventory system?

Only if it treats owner as an attribute of the stock rather than a customer on the order. Most systems will let you fake it with one warehouse per client, which holds while you have a handful of clients and breaks as you add more: you lose mixed locations, cross-client counting and any report that spans the building. Ask whether on-hand can be queried by owner across all locations, and whether one location can hold the same SKU for two owners with the quantities kept apart.

How do I handle bonded and cleared stock in the same building?

Treat customs status as another attribute on the stock alongside owner and lot, so a balance can be read by status and a change of status is a posting like any other movement. What your licence at Sihanoukville · Port actually requires of you is a question for your customs broker and your own legal advice, not for a software vendor, and any vendor who answers it confidently is guessing.

Should storage be billed on pallet positions or on volume?

Bill on whichever your contract says, and make sure the system supports the one you sold. Positions are simpler to evidence and easier for a client to check. Volume is fairer on odd-shaped goods, but it needs dimensions on the item master, kept current, or it silently under-bills. The failure to avoid is a contract written on volume against a system that only counts positions, because then the invoice is somebody's estimate.

What does a client portal need on day one?

It needs on-hand by item and lot, movements over a date range, ageing, open inbound and outbound orders, and an export on each of them. Nothing else is urgent. Scoped to one owner, that set answers the questions clients ring about, and it is small enough to finish before you have solved everything else in the building.

Do I need scanning before any of this works?

You need it eventually and you can start without it. A record with owner on every movement is correct whether the movement was keyed or scanned, and scanning reduces how often it is wrong or late. Be wary of anyone selling you the handheld first. Get the record shape right, then add the devices. Ours is not shipping, and we would rather say so than sell you a photograph.

Where to go next

What Scale Inventory tracks and how every movement posts is the hub for this cluster. If you hold stock for other people and want to work through your own building, its clients and its rate card, tell us what you are running today.