Moving stock off a spreadsheet: the eight steps, in order

What actually takes the time when stock moves off a spreadsheet?

De-duplication and reconciliation, in that order, and neither of them is a technical problem. The import itself runs in an afternoon. Deciding which of three rows is the real product, and then explaining every difference between what a line cost and what was counted, is where the weeks go.

The scarce resource on a migration is not the person who writes the script. It is the person who remembers why the data looks like this: why that supplier code changed in 2023, why there are two entries for the same carton, why one cost is in riel and the next one in dollars. Their time has to be booked like anyone else's, and a plan that assumes they can answer questions between other work is a plan that slips.

Be wary of any quote for a stock migration given without someone asking to see the sheet first. The sheet is the entire variable. Two businesses of the same size, in the same trade, with the same number of SKUs, can be four weeks apart on this work depending on how disciplined the last six years were, and nobody can tell which one you are without opening the file.

The eight steps, in the order they have to run

Each step assumes the one before it finished. The order is not a preference. A de-duplication run before the physical count wastes the count, and an import before the reconciliation produces an opening valuation that nobody can defend when it is questioned six months later.

1. Freeze the spreadsheet. Name a cut-off date, take a copy, and treat that copy as the only version anything is measured against. Movements after the cut-off keep happening in the live file and are entered into the new system afterwards; they are never merged back into the migration data.
2. Count physically against that cut-off. Count the building in as tight a window as you can manage, with movements paused or logged separately while it runs. What you are migrating is the count. The spreadsheet is only there to tell you how far off it was.
3. De-duplicate the products. The same item exists as three rows because three people typed it in over three years. Decide which row survives, merge the quantity and the history into it, and keep the mapping. Someone will ask why last year's figure for a product does not match this year's.
4. Map the SKUs that changed code. A supplier reissues a code, a category gets renumbered, and one physical item carries three identities across six years. One column, old code against new code, maintained by a person who knows the history. It is unglamorous, and it decides whether your old data is worth anything after the move.
5. Split KHR and USD costs into flagged columns. A single mixed cost column is common and invisible until you total it. Every cost gets a currency flag and the date of the rate used. Where the number should have been the landed cost rather than the invoice line, fix it in the same pass: how landed cost is built on the buy side covers what belongs in it.
6. Reconcile before you import. Total cost in the cleaned sheet against the value of what was counted, and resolve every difference rather than only the large ones. A difference you cannot explain is not rounding. It is a product you have not found, a duplicate you have not merged, or stock that left without a document. Finding it now costs an afternoon; finding it after go-live costs the new system its credibility.
7. Import opening on-hand only, with no back-dating. The new system starts at the cut-off with a quantity and a value per item and per site. It does not receive six years of movements dated into the past. Back-dated history produces valuations that change retrospectively and a stock ledger that argues with books you have already closed. Keep the old file as an archive and query it there.
8. Run both for one month, and reconcile weekly. Everything gets entered twice, which is unpopular and worth it. A weekly reconciliation catches a process gap while it is one week old and the people involved can still remember the transaction. A parallel run reconciled only at the end is not a parallel run; it is a month of double entry followed by a disagreement nobody can unpick.

Why is step six the one that decides whether anyone trusts the system?

Because an unexplained difference does not disappear when you import. It becomes the opening balance. From that moment every stock figure the system produces carries it, and the first person to find it has no way to tell whether the system is wrong or the opening number was.

That is the exact mechanism by which a business ends up keeping a notebook next to a working system. Somebody checks a figure in the first month, finds it out by a quantity nobody can account for, and quietly decides the screen cannot be trusted. The system never recovers that person, and the parallel record starts again on a new laptop.

Resolving a difference does not always mean finding the missing stock. It means naming the cause. Stock that left without a document is a real answer and a legitimate write-off; a duplicate you have now merged is a real answer. What is not an answer is calling it rounding, because rounding does not produce differences of the size that turn up in a six-year spreadsheet.

What do you need ready before the first step?

One decision and four artefacts, and the decision is the one that goes wrong most often. Settle the unit you count in, once, and enforce it: a case of 24 x 330ml counted sometimes as one pack and sometimes as twenty-four cans is the single most common reason a count never reconciles.

• A decision on the counting unit, made once and written down, before anybody stands in an aisle with a clipboard.
• An item master somebody will vouch for, with the dead SKUs marked dead rather than left to be discovered during the count.
• A site list with the role of each site written down: which one absorbs a container, which one is a cross-dock, which one holds goods that are not all yours to sell yet.
• A cost per item, and a note of where it came from. A cost with no provenance cannot be reconciled against anything.
• A named person who can settle it when two records disagree. That call is needed weekly, and it is not ours to make.

What does this look like inside a wider project?

The same cleaning work sits on the critical path, and it usually starts later than it should. Where the stock module is one part of an ERP programme, the migration cannot begin until the item master is agreed, and the item master is exactly the thing several departments want to argue about. What actually drives the scope of an ERP project sets out where that lands in a timeline.

The stock system this feeds is described on the inventory system page, and the first thing it will ask you for after go-live is a counting discipline. Migrating cleanly and then never counting again returns you to the same place within a year, which is why cycle counting and stock variance belongs in the same plan rather than in a later one.

What to move to: a spreadsheet, a packaged WMS or a build

The recommendation is made with you in discovery rather than for you in a pitch, and we take no referral fee from any vendor named below. Against Scale Inventory sit the two alternatives every distributor already has: a spreadsheet somebody maintains, or a packaged WMS bought off the shelf. The table sets out what separates the three.

We write the stock model against the way you already work, check the Khmer screens your staff will actually use, with them, before signature, and hand over source, schema and documentation at go-live.

That answers the things a package argues with: bonded stock at the port that cannot be valued like domestic stock, a repack that turns one SKU into a different one, consignment sitting in a customer's shop that is still yours until it sells. How purchasing, inventory, sales and accounting run as one ledger is the architecture it is held to.

Where the flows are ordinary, receive, put away, pick, transfer and count, a packaged WMS is built for exactly that. Two of the table's rows are its strengths rather than feature ticks: multiple warehouses with stock in transit, and lots and serials with FEFO removal. If your rules are unexceptional and your volume clears the vendor's minimum, it may be the cheaper answer, and we say so even though the build is the larger engagement.

Ask any vendor, ours included, what its Cambodian localisation actually covers. A chart-of-accounts and tax localisation is not a warehouse one: it does not translate the stock screens, and it is not a filing connection. That last point is where inventory demos oversell, and it is worth being blunt about.

A stock system produces a valuation and a cost-of-goods-sold figure. It files nothing, and nothing files to GDT for you: the monthly return is filed by a person through GDT's E-Filing, on every option in the table, a packaged system and a build alike. Any vendor blurring those two is describing something that does not exist, and the question to ask is not whether they can do it but whether it is in the contract you are being handed.

The licensing row compresses a lot. A packaged WMS minimum, not its unit rate, is what excludes a mid-size distributor, and a per-user line bites hardest when several warehouse staff need nothing more than read access. A caveat on the currency row: a system that pulls a daily rate is not the same as a team that uses the rate that applied on the receipt date, and that is a process question, not a capability one.

On the five-year shape, one thing is worth stating: a packaged licence renews with headcount rather than with the value the system returns, and a rented licence can be repriced at renewal. The Cambodian ERP cost calculator gives an order-of-magnitude range before you speak to anyone.

How long does a stock migration take?

It depends almost entirely on the state of the sheet, which is why a quote given without seeing it is not a quote. The import is an afternoon. De-duplication and reconciliation are the variable, and on a six-year spreadsheet with an unmaintained item master they can each take longer than the build they are feeding.

Can we migrate our transaction history as well as the current stock?

You can, and on a stock system you generally should not. Back-dated movements produce valuations that change retrospectively and a stock ledger that disagrees with books you have already closed. Import opening on-hand at the cut-off, keep the old file as an archive, and query the history there when somebody asks.

Do we have to stop shipping to do the count?

Not for the whole exercise, but the count itself needs as tight a window as you can manage, with movements either paused or logged separately so they can be applied afterwards. A count taken while goods are moving in and out unrecorded is not a count, it is an estimate with extra steps.

What if we cannot explain a difference?

Name the cause rather than the amount. Stock that left without a document is a legitimate write-off and a real answer. A duplicate you have now merged is a real answer. Calling it rounding is not, because rounding does not produce differences of the size a six-year spreadsheet accumulates, and the unexplained amount becomes your opening balance either way.

Who should own the migration on our side?

The person who remembers why the data looks like this, with enough authority to settle a disagreement between two records. That is usually not the most senior person available and it is almost never someone from IT. Book their time explicitly, because the work stops without them.

What should we ask an inventory vendor that a demo will not answer?

The question that separates vendors is what happens to stock that has left one site and not yet arrived at the next, so ask to see the record. Then ask for an adjustment from a count that went the wrong way, with the reason and the approver still on it. Ask what is written where when the connection drops mid-scan, and what happens when it comes back. Ask who owns the source code and the schema at go-live, in writing. And ask what this does that your spreadsheet does not, answered without the word "integrated". A vendor who cannot answer these on a whiteboard will not answer them in production.