WMS vs Excel — when is it time to switch

Excel is universal and everyone knows it. Sums, sorting, filtering, pivot tables, charts - you can compute rotation, margin, stock value, anything. For ad-hoc reporting it's hard to beat. And honestly, a WMS will never replace Excel for analyses - a good implementation always lets you export to CSV or XLSX so accounting or the sales lead can do their own calculations.

What Excel doesn't give you: many people editing concurrently without conflicts, strong validation of entered data, an audit log of changes (who, when, what), roles and permissions, real-time integration with a barcode scanner. SharePoint and Excel Online try to solve part of that, but on a real warehouse it quickly becomes clear that this is a band-aid on a gunshot wound.

The most common ones we hear during pre-implementation analysis:

• "The sheet says 47 units, there are 42 on the rack and nobody knows where the difference came from"
• "Two people opened the file at the same time and one overwrote the other's changes"
• "A bug in one formula and for a week everyone was making decisions on bad numbers"
• "We need to find out who last edited cell B47 - and there's no way to check"
• "The file has 35 sheets, everyone has their own offline version, merging takes half a day"

Each of these symptoms alone can still be worked around. Three at the same time mean the company has already lost money - it just hasn't counted it yet.

A cosmetics client with around 1,800 SKUs, three warehouse workers, Excel for six years. The annual stocktake showed a 4.2% value shrinkage. A year earlier - 3.8%. Two years earlier - 2.1%. The trend is characteristic: the more operations there are, the bigger the buffer of errors that accumulates in a sheet nobody validates in real time.

Second typical symptom - claims for shipping mistakes. In a pure-Excel warehouse we've seen 2-3% wrong order rates. After implementing a WMS with scan-on-pack, that drops to 0.1-0.3%. With 200 orders per day and an average value of 250 PLN, a 2-percentage-point error reduction means roughly 1,000 PLN per day of recovered margin.

The third thing nobody counts but nobody can miss - time spent "looking for something". A worker walks to the rack, doesn't find the item, walks back, checks the sheet, walks to a different rack. In a 600 m² warehouse with locations kept in Excel, that's often 30-40 minutes per person per day. Three people × 40 minutes × 22 days = 44 hours lost per month. A salary plus a piggy bank.

From our experience the line is roughly here:

• 500-700 SKUs - Excel still copes if two people work in shifts. With three working at the same time, problems start.
• 50+ warehouse operations per day - inbound plus outbound. Manual entry eats hours and errors compound.
• 3+ warehouse workers - data synchronisation between people stops being realistic. Everyone has their own version of the file.
• Required traceability (batch numbers, expiry dates, serial numbers) - Excel can theoretically handle it, but during a complaint it turns out you can't establish where a specific lot was shipped.

If even two of these conditions are met, the cost of running Excel already exceeds the cost of implementing WMS. The company simply doesn't know it yet.

The second phase of "warehouse in Excel" is usually somebody who learned VBA and wrote a few macros. Buttons "Receive delivery", "Issue WZ", linking with CSV files from suppliers. It even works - as long as that person is in the company. We saw this scenario for the first time in 2018: a client was implementing WMS with us because their Excel "system" had been written by a warehouse manager who left, and nobody after him could read the code.

Second reason: macros have no tests, no version control, no documentation. Every change in requirements (a new supplier, a new file format, a new accounting report) means digging into code written by someone who wrote it for themselves. After two or three years such a "system" stops being modifiable - people are afraid to touch it because every change breaks something.

And the third, fundamental reason: Excel was not designed as a database. Trying to keep 50,000 historical operations in it ends with a file that weighs 80 MB, opens for a minute and crashes every few hours. Then someone makes an "archive", moves old data to a separate file, the links break and it gets worse than before.

Four things you simply won't do in Excel:

• Scanning instead of typing. The operator scans a pallet barcode, the system reads GTIN, batch and expiry date in one move. No typos in batch numbers, no "I typed 47 instead of 4.7".
• Real-time. The moment a worker issues a goods note, the e-commerce stock decreases. No "sync once a day", no overselling.
• Audit log. Every operation has an author, date and time. A claim three months later? You check who packed the order, who picked it, who received the inbound - and you reconstruct the full path.
• Roles and permissions. A picker won't change a purchase price. A packer won't see the margin. A manager sees reports but doesn't backdate stock changes. These are things you can bypass in three clicks in a spreadsheet.

The worst time to worry about it is the last week before go-live. The migration goes like this:

• Product master - we import the SKU list with code, name, unit, barcode from the spreadsheet. That's usually 70% of the work. It drags out because in Excel a single product often has three different names.
• Stock on go-live day - we count the warehouse physically the day before launch. That's the opening balance. The old history from the spreadsheet stays in an archive file.
• Locations - the rack map. Usually during the implementation we physically label racks with code labels, because in Excel locations were typically descriptive ("rack next to gate 3").
• Counterparty master - suppliers and customers. Often with duplicates ("ABC Ltd", "ABC ltd", "ABC Ltd.") - time for cleanup.

For a 1,500-2,000 SKU warehouse, the whole operation takes 3-4 working days on our side, plus the client's involvement for the stocktake. You can also start the system without full history - the old Excel file then stays as a reference for claims from before go-live.

"Operators won't learn it" - we hear this in 90% of pre-implementation talks. After go-live it turns out the biggest resistance came from office workers, not warehouse workers. A worker on the rack learns to scan in 2 days. An office worker who'd been writing Excel formulas for five years and felt like their author loses the sense of control - and that tends to be harder than learning the software itself.

"It's too expensive" - implementing WMS in a company with 3-5 warehouse workstations is typically several to a few dozen thousand PLN one-off plus a few hundred to one thousand PLN per user per month. Counted in hours saved in the first months (those 44 hours of searching, plus 1,000 PLN per day of fewer mistakes) it pays back in the first quarter. You just have to have the courage to do the math.

"Our process is too unusual" - rarely is. A warehouse with full lot tracking, a customs warehouse, manufacturing, e-commerce - those are all standard scenarios a WMS handles out of configuration. What's actually unusual are processes the client invented for themselves and which don't map to any sensible pattern - and those are exactly the processes worth reviewing during the implementation.

The most common solution at our clients: warehouse operations in Weaver WMS, management reporting still in Excel. The system exports a daily or on-demand list of movements as CSV/XLSX, the manager builds their own charts in a sheet. That stays. What changes is the data source - instead of a manually maintained sheet, an export from a system that guarantees the data is current and consistent.

The next step is the API. Weaver WMS exposes a REST API that can feed Power BI, Tableau or an external reporting system. For companies that already have working dashboards in Excel, it's a painless transition - the data structures stay, only the source stops being manual editing and becomes the warehouse system.

Four metrics worth measuring before and after the implementation - because that's what shows whether the change made sense:

• Order picking time. Before: 8-12 minutes for 5-7 lines. After: 4-6 minutes with multipicking.
• Wrong shipment rate. Before: 2-3%. After: 0.1-0.3%.
• Shrinkage at stocktake. Before: 2-5% by value. After: 0.3-0.8%.
• Office time spent on warehouse handling. Before: 4-6 hours per person per day. After: 1-2 hours.

An average client recovers 50-80 hours per week across the company in the first quarter. A full-time slot. This isn't speculation, these are values we see on real implementations going back over a decade.

Before the first meeting, it's worth having ready:

• the number of active SKUs (not all in the database, only those that move during a year)
• the average daily count of inbound and outbound transactions
• the number of warehouse workers per shift
• a list of systems the WMS has to integrate with (ERP, e-commerce, courier)
• information about specific requirements: batches, expiry dates, serial numbers, customs warehouse

On our side - Weaver Software has been implementing WMS for 17 years, we know the real size of the pitfalls, we know where to cut scope and where there's no point trying to. The first conversation usually takes 60-90 minutes, after which we leave with an understanding of whether WMS makes sense at all and, if it does, what scope to start with. Excel then stays in the role of an archive and an analysis tool, and operations are taken over by the system. Without fireworks or promises that the implementation will transform the company. Counted in hours of work, it just pays back faster than most other investments.