Shrink and Loss Pattern Detection

Shrink and loss pattern detection applies machine learning to inventory adjustments, returns, POS exceptions, CCTV metadata, and store operations signals so a loss-prevention (LP) analyst can see where unexplained inventory loss is concentrated and which stores, SKUs, or workflows deserve attention first.

The model does not decide guilt, close cases, or authorize disciplinary action. It ranks recurring patterns, unusual combinations of events, and locations where loss appears systematic rather than random. The LP analyst still opens the case, reviews evidence, interviews where needed, and decides whether the signal is theft, process failure, supplier shortage, system error, or noise.

When adjustment history, return history, or POS exception history is missing, the page produces empty output. Those three feeds are the minimum required to form a credible shrink pattern. CCTV metadata and store operations data improve prioritization when present, but they do not replace the core transactional history.

Inventory adjustments are the primary shrink ledger. Useful fields include store, SKU or item hierarchy, adjustment reason code, quantity, unit cost or retail value, timestamp, associate ID where available, and whether the adjustment was approved or auto-posted. Reason codes that cluster around “shrink,” “damaged,” “missing,” or “cycle count variance” matter most, but benign codes can still hide patterned abuse when volumes spike in odd windows.

Returns and voids add a second lens. High-frequency returns of high-value items, returns without matching original receipts, same-day return loops, and returns concentrated on a small set of registers or associates often co-occur with inventory write-offs. The model treats returns as supporting context for shrink, not as a standalone fraud verdict.

POS exceptions cover overrides, price changes, no-sale opens, tender swaps, failed authorizations that later complete offline, and other register events that LP teams already review manually. Alone, an exception is often operational. Combined with adjustments and returns in the same store-day or same associate window, it becomes a stronger pattern feature.

CCTV metadata, when available, is limited to structured event tags such as camera zone, time window, and linked register or aisle IDs. The model does not watch video. It only uses timestamps and location tags to help the analyst decide which footage to pull during investigation.

Store operations signals include open hours, staffing levels, receiving windows, cycle-count schedules, and known reset or remodel periods. These help separate expected variance (for example, after a full reset) from unexplained loss that continues after operations normalize.

Daily or weekly, the analyst receives a ranked list of candidate patterns. Each item typically includes the store or cluster, SKU family or department, estimated loss over a defined window, the dominant signal mix (adjustments vs returns vs POS exceptions), and a short explanation of what made the pattern unusual relative to peer stores or the store’s own baseline.

The analyst’s first job is triage. Patterns with high estimated loss, rising trend, and multiple corroborating feeds jump the queue. Single-signal spikes with a known operational cause (cycle count catch-up, vendor shortage write-off, storm damage) can be deferred or marked as explained without a full case.

Investigation stays human-led. The analyst pulls source transactions, checks receiving and transfer history, reviews CCTV for the flagged windows, and coordinates with store management when process gaps look more likely than theft. The model’s role ends at prioritization and pattern labeling. Case outcomes, associate actions, and policy changes remain with LP and store leadership.

Empty output is intentional when required history is incomplete. If a store or period lacks adjustment, return, or POS exception history, the system should return no ranked patterns for that scope rather than inventing a score from partial feeds. Partial coverage elsewhere on the estate does not justify filling gaps with proxies that LP cannot audit.

Cross-feed coincidence is the strongest practical cue. An example is a department with rising “missing” adjustments, elevated high-value returns without receipts, and clustered no-sale or void events on the same evenings. Any one of those can be process noise. Together, they justify a case.

Peer outliers matter next. A store whose shrink rate for a category sits well above demographically similar stores, after controlling for sales volume and cycle-count cadence, is a better candidate than a store that simply sells more of that category.

Temporal regularity also ranks high. Loss that repeats on the same weekday, after closing, or during low-staff receiving windows is more actionable than a one-off spike after a known inventory event.

SKU concentration is another useful cut. Shrink that piles onto a short list of high-velocity or high-ticket items is easier to investigate and more likely to repay the analyst’s time than diffuse low-value variance across hundreds of SKUs.

Process-shaped patterns should not be ignored. Repeated adjustments after failed cycle counts, chronic damages in a single aisle, or returns that track a broken receipting workflow often point to training, fixture, or system issues. Flagging them still helps LP reduce loss even when no theft is found.

Minimum inputs: inventory adjustment history, returns history, and POS exception history, each with store, item, timestamp, quantity or amount, and reason or exception type. Preferred enrichments: item cost or retail value, associate or register IDs, CCTV zone timestamps, staffing and receiving schedules, and known operational events.

Primary outputs: a prioritized pattern list, per-pattern estimated loss for the scoring window, contributing event summaries, and a human-readable rationale. Secondary outputs can include store and category heatmaps for LP planning, but those are optional views over the same ranked patterns.

Constraints: the model flags patterns; LP investigates. Scores are decision support, not evidence of wrongdoing. Do not auto-create disciplinary cases from model scores alone. Do not score scopes that lack the three required history feeds. Recalibrate after major POS upgrades, reason-code remaps, or inventory-system migrations so that code changes are not mistaken for new shrink.

Related reading: Inventory Record Reconciliation, Planogram Compliance Checker, Real-Time Stockout Risk Predictor.