# Turning POS and inventory streams into a single source of truth
A can of soup scans at the register for $2.49. The customer walks out. In your system, that sale just triggered a chain reaction: revenue recognized, one unit deducted from on-hand inventory, a replenishment signal edging closer to firing. Simple.
Now follow that same can. It was part of a 12-pack the store received as a case, but the register counts singles. A second identical can fell behind the shelf three weeks ago and was never scanned out. A third was scanned twice by a jammed barcode reader. By the time your inventory system says you have "8 on hand," the shelf actually holds 5, the stockroom holds 2, and 1 exists only as a ghost in the database.
That gap is where retail data goes to die. Every forecast, every reorder, every markdown decision downstream inherits it.
Retail runs on two transactional data feeds that are supposed to describe the same physical reality.
POS (point of sale): the register data. Every scan, void, return, and discount. It is fast, high-volume, and mostly accurate at the moment of transaction.
Inventory (perpetual inventory): the running count of what you own, by SKU (stock keeping unit, the unique code for one distinct product variant), by location. It is updated by receipts, sales, transfers, returns, and adjustments.
In theory: every POS sale decrements perpetual inventory by exactly one unit. In practice, the two streams drift apart constantly. A "single source of truth" (SSOT) means one reconciled dataset that the whole business trusts, instead of merchandising, supply chain, and finance each quoting different numbers in the same meeting.
Three failure modes explain most of the drift.
Phantom inventory is stock the system says you have but the shelf does not. Causes: theft not recorded, breakage tossed without an adjustment, items misplaced in the wrong bin, or receiving errors.
The damage is quiet. Your system thinks you have 8 cans, so it does not reorder. Customers find an empty shelf. You lose the sale and never see why, because the data insists the product was available.
Studies of retail operations routinely estimate that a meaningful share of SKUs in a typical store carry inaccurate on-hand counts at any given moment. Treat specific percentages you see quoted as estimates, but the direction is not in dispute: inventory records are wrong more often than most non-operators assume.
Shrinkage is the difference between recorded inventory and actual inventory, usually measured against a physical count. Sources include shoplifting, employee theft, vendor fraud, administrative error, and damage.
Shrink is not just a loss line for finance. It is a data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → problem. If 3 units vanished without a transaction, your perpetual inventory overstates on-hand by 3, and it stays wrong until the next physical count corrects it.
This is the least glamorous and most destructive. A UOM mismatch happens when the same product is counted in different units across systems.
The classic case:
Receive 10 cases, and depending on the mapping error, the system might record 10 units instead of 120, or 120 cases instead of 120 units. Now your on-hand is off by an order of magnitude, and every replenishment calculation built on it is nonsense.
UOM errors are especially brutal because they are systematic, not random. Random noise averages out. A wrong case-to-each conversion breaks the same SKU the same way, every single delivery.
Getting to one truth is a data engineering and operations problem, not a software purchase.
Everything hinges on a shared key. Each physical product needs one canonical SKU, and every system (POS, warehouse, ERP, supplier feed) must mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → to it. Alongside the SKU, store an explicit conversion factor: how many eaches per case, per pallet, per inner pack.
Here is the reconciliation logic in its simplest form, normalizing everything to eaches before comparing:
# Normalize every movement to a common unit (eaches) before reconciling
def to_eaches(qty, uom, conversions):
# conversions: {'each': 1, 'inner': 6, 'case': 12}
return qty * conversions[uom]
# Expected on-hand from the transaction streams
opening = to_eaches(10, 'case', {'each':1,'inner':6,'case':12}) # 120
sold = 47 # POS units, already in eaches
received = to_eaches(5, 'case', {'each':1,'inner':6,'case':12}) # 60
adjustments = -3 # damage write-offs
expected_on_hand = opening - sold + received + adjustments # 130
physical_count = 124
variance = physical_count - expected_on_hand # -6 (shrink or error)
print(f"Expected {expected_on_hand}, counted {physical_count}, variance {variance}")That variance line is the whole game. A non-zero variance is a flag, not an answer. Your job is to route it: is it shrink, a phantom, a UOM bug, or a scan error?
POS and inventory events must carry accurate, consistent timestamps. If a return posts before the original sale in your data, the running count goes temporarily negative and downstream jobs choke. Order events by event time, not by when the batch happened to load.
Rather than shutting the store once a year for a full physical count, cycle counting counts a rotating subset of SKUs continuously (high-value or fast-moving items more often). Each count corrects the perpetual record and, more importantly, generates variance data you can analyze for root cause.
For a solid, vendor-neutral primer on inventory accuracy fundamentals, the U.S. Small Business Administration's guidance on managing inventory is a free starting point for the operational basics.
🎬 [VIDEO: "How Retailers Track Inventory (POS Systems Explained)" — youtube.com — a plain-language walkthrough of how register data flows into inventory records]
Knowledge check
1. What is the core problem a 'single source of truth' (SSOT) is meant to solve in retail data?
2. Why is a discrepancy between the POS stream and the perpetual inventory stream especially damaging?
3. A store's system shows 8 units on hand, but a physical count finds 5 on the shelf and 2 in the stockroom. What does the remaining 1 unit represent conceptually?
4. Select ALL correct answers. Which situations can cause the POS and perpetual inventory streams to drift apart?
Select all the correct answers.
5. Select ALL correct answers. Which statements accurately describe the POS and perpetual inventory streams?
Select all the correct answers.
Once POS and inventory agree, the compounding value shows up everywhere downstream.
Replenishment stops guessing. Accurate on-hand plus accurate UOM means the reorder point fires at the right quantity. No more ordering 120 when you needed 12, or starving a shelf because a phantom said you were stocked.
Forecasting improves. Demand models learn from sales, but if sales data is polluted by double-scans and stockouts (which look like zero demand rather than lost demand), the forecast learns the wrong lesson. Clean, reconciled data lets you distinguish "nobody wanted it" from "we had none to sell."
Omnichannel becomes possible. Buy-online-pickup-in-store and ship-from-store both promise a customer a specific unit at a specific location. If your on-hand is off by even a few units, you either oversell (and cancel orders, angering customers) or hide sellable stock (and lose margin). A trusted SSOT is the precondition for selling the same inventory across channels.
Loss prevention gets targeted. When variance is captured per SKU per location per count cycle, patterns emerge. A single SKU consistently short at one store is a different problem (theft, or a receiving error) than the same SKU short everywhere (a UOM mapping bug in the system).
The hardest part is not the data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition →. It is agreeing that one number wins. When finance's shrink figure and merchandising's on-hand figure disagree, someone has to own the reconciled truth and the rules that produce it. Without that ownership, teams quietly rebuild their own spreadsheets, and you are back to three versions of one can of soup.