A stock report is only useful if it describes the world as it actually is right now. For a single-site retailer, that is a manageable problem. For a trade or specialist retailer running dozens or hundreds of sites, it is often not true at all. The number on the screen at 9am reflects what was true when the overnight batch ran, not what happened on the shop floor an hour ago.
Most retail leaders know this in the abstract. Far fewer have quantified what it actually costs them: the stock that shows as available but has already sold, the transfer that gets approved based on numbers that were wrong before the approval was even clicked, the finance team reconciling three different versions of the truth at month end. None of these show up as a single line item. They show up as margin leakage, wasted staff hours, and decisions made with more confidence than the data deserves.
This post looks at why stock data lags behind reality as retailers scale past a handful of sites, what that lag actually costs, and what a genuinely connected alternative looks like in practice.
Most multi-site retailers did not choose fragmented stock visibility. It accumulated. A POS system was bought to solve the till. A separate system was bought or built to handle warehouse and stock. Finance ran its own reporting on top of both. Each system was probably right for the problem it was bought to solve at the time. The issue is what happens when those systems have to talk to each other at scale.
The typical pattern is a nightly batch job: POS data is exported, matched against warehouse movements, and pushed into whatever system finance and head office actually look at. That works fine at five sites. At fifty or a hundred, the batch window gets longer, the reconciliation gets messier, and the gap between "what the system shows" and "what is actually on the shelf" gets wider. Add multi-site transfers, trade accounts with their own pricing and credit terms, and variable units of measurement (a builders' merchant selling both bulk pallets and single components is a good example), and the batch process is trying to reconcile a much more complex picture overnight than it was ever designed for.
The cost of this lag rarely appears as a single number, which is exactly why it survives so long unaddressed. It shows up in several places at once.
Stockouts and overstock both increase, often at the same time in different locations, because head office is buying and allocating against numbers that are already several hours or a day out of date. Staff time gets absorbed in manual reconciliation. Someone, usually in finance, is pulling a stock report from one system, a sales report from another, and reconciling the difference by hand before anyone can trust the numbers enough to act on them. Trade and B2B customers, who expect accurate availability and fast quoting, notice when a system cannot tell them in real time what is actually in stock. And at the till, staff cannot serve a customer standing in front of them if building a quote or checking availability across sites takes minutes rather than seconds.
None of this is hypothetical. Selco Builders Warehouse, a 74-store trade merchant, was building customer quotes at the till in five to ten minutes on its legacy system before migrating to a connected Business Central and LS Central platform, a process that now takes around 30 seconds. Overnight processing failures that used to leave stores exposed at opening time were eliminated in the same move. Leyland, a 36-store decorating and DIY retailer running an unsupported legacy ERP and a bespoke POS system, was living with daily system crashes across warehouse and store operations before a similar transformation. In both cases, the underlying problem was the same: systems that could not agree on the truth in real time.
It is tempting to assume that stock visibility is a problem you solve once and then manage. In practice, it compounds with scale. Every additional site adds another set of stock movements that need to reconcile with the centre. Every additional transfer between sites adds another point where the "official" number and the physical number can drift apart. Every additional sales channel, online alongside in-store being the obvious one, adds another system that has to agree with the others about what is actually available to sell.
Retailers often notice this the hard way: the reporting and reconciliation processes that worked fine at ten or twenty sites start breaking down noticeably somewhere between fifty and a hundred, not because anything changed overnight, but because the batch-based architecture was never built to carry that much complexity. By the time the pain is visible at head office level, it has usually been costing the business in smaller, less visible ways for a long time.
"Real-time" gets used loosely in retail technology marketing, so it is worth being specific about what it actually requires. It is not a reporting dashboard that refreshes more often. It requires POS, warehouse, and finance to be built on the same underlying platform, so that a sale, a stock movement, or a transfer updates one shared source of truth rather than several systems that then need to be reconciled after the fact.
This is the core of what Business Central and LS Central are designed to do together. Business Central provides the finance and operations backbone: purchasing, inventory, multi-site compliance, and reporting. LS Central extends that into the retail and POS layer, so that a transaction at the till and a stock movement in the warehouse are recorded in the same system, not two systems that get compared later. The result is that stock, sales, and finance are looking at the same numbers at the same time, whether you are running one site or a hundred.
That said, moving to a connected platform is a genuine architecture decision, not a simple software swap. Multi-country operations, in particular, are not just a multi-site problem: territory-specific fiscal and compliance requirements can mean separate environments are needed, which is a design question that has to be worked through properly rather than assumed away.
The pattern in both the Selco and Leyland transformations was not simply installing new software. It was a phased, risk-first migration that protected day-to-day trading throughout. Selco's move involved a hybrid bridge between its legacy NAV system and Business Central, allowing head office functions to modernise first while stores transitioned in phases, with rollouts scheduled out of hours specifically to avoid disrupting trade. Leyland's transformation replaced a fragmented mix of an ageing ERP and bespoke POS with a single, cloud-based Business Central and LS Central platform, introducing a configuration-first approach that formalised processes and controls the business had never had in place before.
In both cases, the retailer ended up with one connected system rather than, as Leyland's CEO put it, "lots of bolt ons and workarounds." That is the practical definition of solving the stock visibility problem: not more reports, but fewer systems that need reconciling in the first place.
A few honest questions tend to surface whether delayed stock data is quietly costing your business money. Can head office see stock as it actually stands right now, or only as it stood at the last batch update? When a transfer is approved between sites, is it based on live figures or numbers that could already be several hours old? How much staff time each week goes into manually reconciling stock, sales, and finance reports that should already agree with each other? And if you are managing bulk stock alongside single-unit components, or trade pricing alongside retail pricing, does your current system actually understand that complexity, or is it being handled through manual workarounds and spreadsheets sitting outside the core system?
If the honest answer to more than one of these is uncomfortable, it is worth treating stock visibility as an operational risk to be designed out, rather than a reporting inconvenience to be lived with. BC4's data and system migration services exist specifically to move retailers off legacy, disconnected systems without disrupting trade in the process.
BC4 has helped multi-site trade and specialist retailers, including Selco Builders Warehouse and Leyland, replace fragmented, batch-based systems with a single connected platform built on Microsoft Business Central and LS Central. If stock visibility across your sites is costing you more than it should, get in touch and we can talk through what that looks like for your business.
Business Central, extended by LS Central for retail and POS, records sales, stock movements, and finance in one connected system rather than separate systems that need reconciling afterwards. This means head office can see an accurate stock position across every site in real time, rather than relying on overnight batch updates.
Poor stock accuracy shows up as stockouts and overstock happening simultaneously across different sites, staff time lost to manual reconciliation between systems, slower service for trade and B2B customers who expect accurate availability, and finance teams reporting numbers they cannot fully trust. It rarely appears as one line item, which is often why it goes unaddressed for years.
A batch update processes stock and sales data at set intervals, typically overnight, so the numbers on screen reflect the last batch run rather than the current position. Real-time stock visibility means every sale or movement updates a single shared system immediately, so head office, stores, and finance are always looking at the same, current numbers.
Many standard ERP systems are not built for the specific complexity of trade retail, including bulk and granular inventory tracked down to single components, made-to-order products, and B2B pricing or credit terms alongside standard retail pricing. This is a specific design and configuration challenge, not something every ERP or retail platform handles well out of the box.
It does not have to disrupt trading, but that depends entirely on how the migration is planned and delivered. A phased, risk-first approach, including hybrid bridging between old and new systems where needed and rollouts scheduled around trading hours, can protect day-to-day operations throughout, as demonstrated in BC4's work with both Selco and Leyland.
There is no fixed number, but retailers commonly find that reconciliation processes which worked at ten or twenty sites start to strain noticeably between fifty and a hundred sites, as the volume of transfers, transactions, and batch processing outgrows what the underlying architecture was designed to handle.