A cross-channel table joining two systems: SKUs whose on-hand quantity in Oracle Inventory Cloud differs from the quantity published on the storefront by more than 5%. Drift drives oversell and phantom stockouts.
At a glance
This is a cross-channel card. It compares the on-hand quantity Oracle Inventory Cloud holds for each SKU against the quantity that SKU is advertising on the ecommerce platform, and lists every item where the two have drifted apart by more than 5%. Inventory parity between the system of record and the storefront is what stops two failure modes: overselling (the storefront shows more than Oracle has, so customers buy stock you cannot ship) and phantom stockouts (the storefront shows less than Oracle has, so you lose sales on stock that exists). Drift is the early signal that the sync between Oracle and the storefront is lagging, partial, or broken. Each row is a SKU with its Oracle on-hand, its published storefront quantity, and the drift percentage, so operations can fix the worst offenders first.
| What it counts | Each row is one SKU whose Oracle Inventory Cloud on-hand quantity differs from the quantity published on the ecommerce platform by more than 5%, in either direction. Columns show the Oracle on-hand, the storefront quantity, the absolute gap, and the drift percentage. |
| Cross-channel join | Oracle on-hand (the system of record) is matched to the storefront’s published availability (what customers see) on the SKU. The card exists because neither number alone reveals the gap. |
| Direction matters | Storefront higher than Oracle risks oversell; storefront lower than Oracle risks phantom stockouts and lost sales. The card shows both directions and the sign of the gap. |
| Why 5% | A small drift is normal sync latency. A drift beyond 5% is large enough to cause a real oversell or a real lost sale, so it is the point worth a human’s attention. |
| Business Unit scope | Respects the dashboard’s selected Business Unit and inventory-organisation filter. By default spans every inventory org and storefront the connected role can see. |
| Time window | RT/24H (real-time parity check, evaluated against the last 24 hours of sync) |
| Alert trigger | >10 SKUs drifting - more than ten SKUs past the 5% drift threshold raises the table |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A Fortune 500 omnichannel retailer runs Oracle Inventory Cloud as the system of record, syncing on-hand to a Shopify Plus storefront through Oracle Integration Cloud (OIC) on a scheduled flow. On 14 Mar 26 a sync batch partially failed, and the parity check surfaces four SKUs drifting beyond 5%.| SKU | Oracle on-hand | Storefront qty | Gap | Drift | Risk |
|---|---|---|---|---|---|
| SKU-44120 (Wireless Earbuds) | 120 | 410 | +290 | +242% | Oversell |
| SKU-90711 (Travel Mug) | 880 | 540 | -340 | -39% | Phantom stockout |
| SKU-22305 (Yoga Mat) | 64 | 0 | -64 | -100% | Phantom stockout |
| SKU-71150 (Water Bottle) | 1,200 | 1,140 | -60 | -5.0% | Borderline, watch |
- Two systems, one finding. Oracle knows it has 120 earbuds. Shopify is advertising 410. Neither system flags the gap on its own; the cross-channel join is what exposes it. The storefront will happily sell 410 units of stock that does not exist.
- The earbuds row is an active oversell. Storefront 242% above Oracle on-hand means every order beyond 120 units cannot be fulfilled. This is the most expensive kind of drift: refunds, cancellations, and customer trust. The likely root cause is a stale sync; pair this with OIC Integration Flow Failures (24h) to confirm the flow broke.
- The yoga mat is a 100% phantom stockout. Oracle has 64 units; the storefront shows zero, so the SKU is silently losing every sale. Phantom stockouts are easy to miss because nothing breaks visibly; you just sell less than you could. Pair with OOS with Open Sales Order Demand.
- Always check for negative on-hand upstream. A SKU that went negative in Oracle will almost always show as drift here too. Read this card together with Inventory AvailableQuantity Went Negative; a negative on-hand is both an integrity break and a parity break.
Sibling cards merchants should reference together
This card lives at the join of Oracle inventory and the storefront. Pair it with the inventory-integrity and demand cards on both sides.| Card | Why pair it with SKUs with Fusion-vs-Ecom Inventory Drift |
|---|---|
| ERP vs Ecom Inventory Variance | The aggregate variance picture; this card is the per-SKU breakdown past the 5% line. |
| Inventory AvailableQuantity Went Negative | A negative on-hand almost always shows as drift; read the two together. |
| OIC Integration Flow Failures (24h) | The most common root cause of drift: a broken or lagging sync flow. |
| OOS with Open Sales Order Demand | Phantom stockouts on this card become lost sales here. |
| Low Stock Alerts | Drift can mask a genuine low-stock position or invent a false one. |
| Total Inventory Value | The valued position that drift distorts when read against the storefront. |
| Oracle Fusion Health Score | The composite that widespread drift drags down. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud: The Oracle side of this card maps to standard Inventory Cloud on-hand views; the storefront side comes from your commerce connector, so a full match requires both.Navigator → Supply Chain → Inventory Management → Manage Item Quantities (Oracle on-hand and available per SKU and inventory org) Inventory Management → Review Completed Transactions (the transactions behind the current on-hand) Reports and Analytics → OTBI → Inventory Management → Inventory On-hand Balance Real TimeThe Oracle on-hand column in this card should match Manage Item Quantities when scoped to the same inventory org and as-of moment. The storefront quantity will not appear in any Oracle report, because it is the commerce platform’s published availability; that column comes from the connector. The drift is the difference between the two. Common mistakes when comparing against Oracle’s own reports:
- Comparing on-hand to available. Oracle distinguishes on-hand from available after reservations. The card compares the figure the storefront should be syncing from; check you are reading the same one in Oracle.
- Wrong inventory organisation. Storefront availability often maps to one or a few fulfilment orgs, not the whole network. Aggregating every org in Oracle will not match the storefront’s source org.
- As-of timing. On-hand moves continuously. A drift can close or open between the card’s sample and your Oracle query, especially right after a sync runs.
| Reason | Direction | Why |
|---|---|---|
| Cross-channel by design | Card has extra data | The storefront quantity has no Oracle equivalent; it is the commerce platform’s published number. The card’s value is the comparison, not a single-system reconciliation. |
| On-hand vs available | Either | If the storefront syncs from available (net of reservations) and you compare against gross on-hand, a gap appears that is definitional, not real drift. |
| Inventory-org mapping | Either | The storefront draws from specific fulfilment orgs; comparing against the full network in Oracle overstates the Oracle side. |
| Sync timing | Either | A drift sampled just before a sync run can resolve immediately after, so the card and a later Oracle query disagree. |