A growing multi-channel apparel retailer with three warehouses and four regional Shopify stores was expanding its product range and sales channels. Inventory data flowed from the warehouses into Linnworks as the central system of record, then onward to the Shopify stores and into Sage Inventory Planner for replenishment recommendations. Polar Analytics served as the primary reporting layer. On paper, the architecture was logical. In practice, the available inventory figures across these systems routinely disagreed, and the team could not produce reliable replenishment suggestions or consistent performance metrics. That led to a substantial amount of unnecessary Excel work trying to create a replenishment process that would work. They had an urgent need to move away from Excel and to use the replenishment system they already had.
The discrepancies were not occasional. Warehouse stock that should have been available for sale on Shopify was sometimes missing. Replenishment recommendations in Sage Inventory Planner appeared unreliable or incomplete. At the same time, the commercial and planning teams could not agree on a shared definition of return rate… an especially material metric in apparel, where customer returns are common and the timing of those returns affects both inventory planning and marketing investment decisions.
Diagnosing the Data Foundation
The first priority was to treat inventory as the core data set on which almost every other decision depended. A systematic comparison of SKU-level inventory across the warehouse systems, Linnworks, the Shopify stores, and Sage Inventory Planner revealed two recurring categories of problems.
SKU mapping errors existed between systems. The occasional SKU was mapped to an incorrect SKU in other systems, so available inventory quantities did not align even when the underlying stock was correct. In addition, synchronization jobs were failing silently. Certain integrations stop attempting to update a SKU after repeated failures. Without regular monitoring, individual items (or groups of items) simply drop out of the list of items to sync. The practical result was that warehouse stock existed but was not being pushed to the relevant Shopify store, so the product was effectively unavailable to customers even though physical inventory existed.
These issues were not visible in high-level dashboards. They surfaced only when the same SKU was examined side-by-side across systems and when the sync history and error logs were reviewed. Once the mapping rules were cleaned and the failed syncs were identified and reprocessed, the available-to-sell figures began to converge. Ongoing monitoring of the sync status was introduced so that future failures would be caught before they created material discrepancies.
Establishing a Shared Definition of Return Rate
With the inventory data more consistent, attention turned to return rate. Because customers can return apparel for a variety of reasons and over varying timeframes, the “final” return rate for a product depends on how long the business is willing to wait before treating the data as complete.
Analysis of historical return timing showed that most returns occurred within a defined window after the original sale. The team agreed that any return-rate calculation used for reporting or decision-making would exclude the most recent 45 days. This created a stable, comparable metric rather than a constantly moving number that changed as late returns continued to arrive. The same underlying definition was then applied consistently, regardless of the downstream use case.
Supporting Different Decisions with the Same Definition
Even with a single definition of return rate, the commercial and planning teams needed different views of that metric. Inventory planners needed to understand which products were likely to generate elevated returns so they could adjust reorder quantities. Marketing and merchandising teams needed to understand which products delivered acceptable return rates relative to their contribution margin and advertising efficiency, so they could allocate spend more effectively.
Two customized views were built in Polar Analytics. Both used the agreed 45-day exclusion rule and the same underlying calculation. One view was structured around the inventory-planning questions (return behavior by product attribute, size, or warehouse). The second view was structured around the commercial questions (return rate in the context of advertising performance and contribution). Because the definition remained consistent, the teams could discuss the same numbers while still seeing the information arranged for the decisions they each needed to make.
Establishing the Fundamental Core
Once the SKU mappings and synchronization processes were corrected, the available inventory figures across Linnworks, the Shopify stores, and Sage Inventory Planner became materially more consistent. Warehouse stock that had been invisible to customers began appearing for sale.
The next step was to restore usability of the Inventory Planning tool to enable easier supplier ordering. The confidence in these numbers didn’t exist.
Establishing Confidence in the Replenishment Recommendations
The inventory planning tool made recommendations for replenishment but historically had provided some “crazy values” according to the client. The core inventory data was correct, so I proceeded to validate the sales history being fed into the system and investigate the configuration options. Like many companies that buy this type of tool, the settings were the same for all SKUs and an explanation of how to properly choose configuration settings was never provided.
I provided an explanation of every input into the system, complete with a recommendation of how to pick a forecasting method for each SKUs. All SKUs do not behave the same, so an understanding of the demand patterns for each product is necessary to make a good choice.
Once the SKU settings were chosen and entered into the system, replenishment recommendations could be reviewed with greater confidence because the underlying inventory and sales inputs were no longer systematically incomplete and the forecast options and “special consideration” flags were properly set.
How it All Ended
The shared return-rate definition removed a recurring source of disagreement in planning and performance discussions. The two tailored views in Polar Analytics allowed each team to work with the metric in the format most useful to them without creating competing versions of the truth.
The work did not eliminate every future data exception since multi-system environments continue to require monitoring, but it restored the reliability of the core data set that the rest of the planning and reporting processes depend on. For a business operating warehouses in multiple countries and selling through several regional storefronts, that reliability is what makes downstream tools and decisions usable.
Businesses that run multi-warehouse, multi-store operations on a similar stack (order management systems feeding e-commerce platforms and planning tools) often encounter the same pattern: the integrations appear to be working until someone needs to trust a specific SKU or a specific metric. The diagnostic work of reconciling mappings, checking sync health, and agreeing on the timing and definition of key metrics is frequently the step that makes the rest of the technology stack deliver consistent results.
In the end, the company had a tech stack which produced consistent inventory information and a reliable inventory replenishment system to follow.
