Inventory Analytics at Scale: Why a Lakehouse Beats Spreadsheets for Multi-Warehouse FMCG

For a single warehouse, a spreadsheet handles inventory perfectly well. The trouble starts at scale: a dozen warehouses, tens of thousands of SKUs, thousands of daily movements. People assume the problem will be performance — the file getting slow — but that is not the real failure. The real failure is correctness.

The multi-warehouse spreadsheet is built by exporting stock from each warehouse system and pasting it together. By the time the last export is in, the first is hours old; a movement that happened during the compilation is missed; a manual paste drops or duplicates rows. The file looks complete and is quietly wrong, and crucially nobody can say by how much, because there is no reconciliation back to the sites.

That is the point at which inventory reporting has outgrown spreadsheets — not because the file is slow, but because the group stock number can no longer be trusted. A lakehouse fixes the correctness problem, and the analytics come as a consequence.

Multi-warehouse FMCG operations rarely run one system. There is an ERP, perhaps a dedicated WMS at larger sites, a different setup at a third-party-logistics location, and spreadsheets filling gaps. The core job a lakehouse does is consolidate all of them into one governed model — each source landing in Microsoft Fabric and OneLake and conformed to a shared inventory structure, so a SKU and a location mean the same thing everywhere.

This conformance is the work that a spreadsheet can never do reliably. Different systems code products and locations differently; the lakehouse maps them to one definition in the data layer, so the consolidated stock position is a genuine like-for-like roll-up rather than a paste of incompatible exports. One SKU, one location, one quantity — across every site.

Because the sources feed the model continuously rather than by manual export, the consolidation stays current. A movement at any warehouse flows into the governed model, so the group view reflects today, not the last time someone built the file.

With the sources consolidated, the group has a single live stock position: how much of each SKU is where, right now, reconciled across all warehouses. This is the number the spreadsheet could never reliably produce, and it is the foundation everything else sits on. A buyer, a planner or a finance controller reads the same stock figure, and it is current.

Because the model is governed, that figure is also traceable: the group number ties back to the per-site quantities that make it up, so when someone questions it, the answer is a decomposition rather than a defence. "The group holds this much; here is the split by warehouse" is a statement the business can act on and audit.

This single trusted position is what turns inventory from a reporting chore into a decision input. You cannot optimise stock you cannot measure consistently, and the live, reconciled position is what makes every downstream analysis — ageing, turnover, stockouts — meaningful rather than approximate.

On a trusted, consolidated foundation, the inventory analytics an FMCG operation actually needs become possible. Ageing and slow-moving analysis across all sites: which stock is sitting too long and where, so it can be moved or marked down before it becomes a write-off. Turnover and days-of-cover by SKU and location: where capital is tied up and where cover is thin. And stockout and overstock signals across the network, so imbalances between warehouses are visible and correctable.

None of these survive on a multi-file spreadsheet, because each needs a consistent, current, cross-site view that the manual process cannot sustain. Ageing in particular needs movement history the spreadsheet throws away on each rebuild; turnover needs consistent SKU definitions across sites; network stockout analysis needs all warehouses in one comparable model. The lakehouse provides all three by design.

The analytics also compound: the same governed inventory model feeds demand and replenishment, so stock decisions connect to forecasting rather than sitting in isolation. One foundation, many inventory questions answered consistently — which is the opposite of a folder of per-warehouse spreadsheets nobody can reconcile.

Multi-warehouse FMCG inventory outgrows spreadsheets not when the file gets slow but when the group stock number can no longer be trusted. A data lakehouse on Microsoft Fabric and OneLake consolidates every warehouse system into one governed model, conforms SKUs and locations to single definitions, and keeps the position current — giving the business one live, reconciled, traceable stock figure. On that foundation, ageing, turnover, cover and network stockout analytics become possible, and inventory connects to demand and replenishment rather than sitting in isolated files.

The test is simple: can you state your group stock position right now, reconcile it to each site, and age it by location — without building a file for a day and hoping it is right? If not, inventory reporting has outgrown the spreadsheet, and the fix is a consolidated foundation, not a bigger spreadsheet. The value is one number the whole business trusts, which is what every inventory decision quietly depends on.