**Memo: Inventory accuracy follow-up — your four questions answered**
**To:** Tomasz Nowak | **From:** Fatima Zahra | **Date:** 2026-01-16

**1. The 24% rise is a scale effect, not a worsening trend.** Half-month data shows events-per-active-location flat all year (4.6-5.9 range, no drift: ~5.2-5.4 in January, ~5.2-5.3 in December). Raw counts rose because 23 new warehouses came online over the year, tracking almost exactly with the growth in active locations (85→111). *(Report: Trend of stock-count discrepancies within 2025.)* **No step-change moment to point to — it's rollout, not a deteriorating process.**

**2. The theft-tag split looks like an artifact, not a genuine signal.** "Missing - suspected theft" sits in an unusually tight 15-23% band across all 35 staff identities and all warehouses — and each named staff member's adjustment total exactly matches one specific warehouse's total (e.g., Christopher Evans = 1,506 = Atlanta's full count). That's a 1:1 staff-to-warehouse mapping, not real individual rosters. Entry times cluster at ~11-12 UTC regardless of country. *(Reports: staff and warehouse theft-tag breakdowns.)* **I don't trust this reason-code data enough to size a shrinkage provision off it** — recommend confirming with engineering how `adjusted_by_user_id` and `reason` actually get populated before using this for the auditors.

**3. The Dec-31 "B2B correction" is very likely a system event, not an annual stocktake.** 406 of 407 adjustment-kind events share the *exact same microsecond* timestamp (2025-12-31 22:59:59.999999), across 59 independent tenants. Fifty-nine companies finishing physical counts at the identical instant isn't physically plausible. *(Report: Is the Dec 31 correction one batch event?)* Separately, B2B tenants' pick locations behave normally (14-57 routine adjustments/year, proportional to their small catalogs) — it's specifically their bulk locations, which get zero day-to-day counting (same as bulk locations everywhere), that silently drift and then show up in this event. **Please don't tell auditors we run annual B2B stocktakes based on this data** — I'd confirm with engineering what actually generated this batch first.

**4. Apparel concentration is about catalog size, not site-specific failure.** Every apparel warehouse has exactly one pick location, so "rate per location" collapses to "rate per catalog size" — and adjustments-per-distinct-variant is a near-constant ~1.07-1.09 across every apparel site, big or small (Atlanta 1.09, Tampere 1.08). Product-level drill-down at the three biggest sites found no hot SKU, size, or color (max 5 events across 2,927 variants). **This is not a training/process fix for a handful of sites** — it's systemic to how many SKUs a site carries. Confirmed further: this ~1.05-1.14 ratio holds across *all 11* merchant verticals (Report: *apparel-specific or company-wide?*) — apparel's raw totals are large simply because it carries ~6,000 distinct SKUs versus ~90-275 elsewhere. The whole routine stream is best described as **a flat ~1-unit-miss-per-SKU-per-year background rate, platform-wide**, not a product or process defect concentrated anywhere in particular.

**Bonus, resolved cleanly:** the 10 zero-activity "...Warehouse" sites (as opposed to "...Fulfilment Centre") hold zero stock on hand — empty shells, not a hidden blind spot.

**Confidence:** High on #1, #3's timestamp evidence, #4, and the warehouse-shell check — each is cross-confirmed across independent queries with numbers that reconcile exactly. Lower on #2 and the "why" behind #3 — I can show the *pattern* looks artificial, but can't yet tell you the *root cause* in the source system.

**Next steps:** (a) ask engineering directly how `stock_adjustments.reason` and `.adjusted_by_user_id` get set, and what generated the Dec-31 batch; (b) if #2/#3 turn out to be genuine data-quality issues, reframe the audit answer around "routine stock accuracy is strong and stable" and flag the two artifacts as open items rather than facts.