When your POS, stock and online don't talk.

A promo fires at the till but not online. A customer buys the last of something in aisle four, and ninety minutes later your website happily sells it again. Head office pulls a stock report that was already a day out of date the moment it opened. If any of that sounds like your Monday, you don't have an omnichannel problem - you have three systems each convinced it holds the truth. Here's the honest version of what it takes to make them agree.

Three systems, three versions of the truth

The classic growing-chain setup arrives one honest decision at a time. The till runs its own point-of-sale. Stock lives in a spreadsheet, or in the POS's own thin inventory, or increasingly in both. The website runs on a separate platform with its own idea of what's available. None of these were wrong when you had four stores. They become a daily tax somewhere between store ten and store twenty.

The symptom is always the same shape: the numbers drift. A count that was right at open is wrong by lunch because two of the three systems moved and one didn't. Promotions clash - a discount that's live at the register hasn't reached the web, or vice versa, and now a customer is standing at the counter with a screenshot. And every report head office relies on is a reconciliation of yesterday, not a view of now. You are, in effect, running the business on three maps and hoping they roughly overlap.

Syncing isn't unifying

The instinct - and it's the instinct most "omnichannel" projects run on - is to bolt the systems together with connectors. Push stock from the POS to the website every few minutes. Pull web orders back into the till system. Add a middleware layer to referee. It demos beautifully.

It also just moves the drift around. Every sync is a snapshot in transit, and between snapshots the systems disagree. The more stores and channels you add, the more snapshots are in flight at once, and the wider the window in which two systems can both be confidently wrong. You haven't removed the reconciliation work; you've automated it and hidden it, which is worse, because now the drift shows up as an oversold web order or a promo mismatch instead of a line in a spreadsheet someone was at least checking. Integrated is not the same as unified. Four systems talking to each other is still four versions of the truth having a fast conversation.

The real fix is a different idea entirely, and it's a bigger one than a plugin. Not more integrations - fewer sources of truth. One.

One live inventory, read and written everywhere

Unified commerce means every till, every warehouse and every web order reads from and writes to the same live inventory, in real time. Not a master copy that syncs outward - the actual data that a sale in aisle four decrements the instant it happens, so the website already knows before the next customer loads the page. Procurement, checkout and analytics all sit on the same model. There is nothing to reconcile because there was only ever one number.

This is a bigger claim than a thought piece should make without proof, so here is ours. We run a retail ERP and POS platform for a multi-store Indian grocery and FMCG chain - a single platform, custom-built, that now runs 53 stores across three states. It didn't launch at that size. The chain scaled with us from roughly 30 stores to 53, adding locations onto the same live data model rather than bolting on another disconnected system each time. In its first year on the platform it processed around 380,000 bills - a little over a thousand a day, every day - and every one of them wrote to the same inventory the website and head office were reading.

That single model carries 223,908 SKUs and 1,565 suppliers inside one controlled procure-to-pay cycle, all of it live since 2025. Head office doesn't wait for a nightly roll-up; it sees the floor now. That's the whole point of one source of truth: the report and the reality are the same object.

The details that break at scale

Unified inventory is the spine, but grocery and FMCG break your system on the details a generic retail deck never mentions. These are the parts that quietly decide whether the idea survives past a pilot store.

• Batch & expiry - 223,908 SKUs that expire is not a rounding error, it's the hard problem. Real grocery ops can't fake this: stock has to be tracked by batch, moved oldest-first, and pulled before it's sold past date. A count that ignores batches is fiction dressed as a number.
• Procure-to-pay - purchase orders, suppliers and goods-in have to feed the same inventory and costing that the till sells against. 1,565 suppliers in one controlled cycle only works because receiving a delivery and selling an item touch the same data, not two systems that reconcile later.
• Promotions & loyalty - a promo has to apply identically at every till and online, or you get the screenshot-at-the-counter moment. Same rule, same source, one place it's defined.
• Patchy connectivity - a till in a store with a flaky line can't stop trading. It has to keep ringing sales and reconcile cleanly to the live inventory the moment the link returns, without double-counting or losing a bill.

You don't rip and replace

Here's the part that matters most to anyone running stores today, because trading never stops: you do not - and should not - replace everything at once. A chain doesn't get a maintenance weekend across 53 stores. The move onto one live inventory happens store by store, integrating what already works, keeping the tills that are fine, and training staff as each location comes across. Growing from 30 stores to 53 on the same platform is exactly what a rollout that respects trading looks like: the business kept selling the whole way through. Big-bang cutovers are how omnichannel projects earn their bad reputation. Incremental is slower to talk about and far safer to live through.

Owning the stack, and the no-per-till-tax point

One more thing the SaaS route hides. When your POS and inventory are rented per till or per store, growth is a recurring penalty - every new location adds to the monthly bill forever, and your data lives in someone else's system. The platform we run for the grocery chain is custom and self-hosted: they own it outright - code, data and hosting. There is no per-till tax waiting at store 54, and the operational history of the whole business stays theirs. For a chain whose entire advantage is opening more stores, paying rent that scales with your own success is the quiet wrong incentive to design in.

Where to start

You don't need to commit to a rebuild to find out where you stand. The useful first step is a clear-eyed look at where your tills, stock and online actually disagree today - the specific seams where drift is getting in - before anyone talks architecture. That's what our Retail Stack Assessment is: a free, honest map of your current stack and the reconciliation work it's quietly costing you. If you want the fuller picture first, the POS for retail practice lays out how we build these platforms, and the grocery retail ERP case study walks through the 53-store build in detail. Start with the map. The decision comes second.