Skip to main content
Metrics type: Key Metrics • Category: Ecommerce Platform
A cross-platform 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-platform 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.

​
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%. Four things to notice:
  1. Two systems, one finding. Oracle knows it has 120 earbuds. Shopify is advertising 410. Neither system flags the gap on its own; the cross-platform join is what exposes it. The storefront will happily sell 410 units of stock that does not exist.
  2. 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.
  3. 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.
  4. 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.

​
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 Time
The 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.
Why our number may legitimately differ from Oracle’s reports:

​
Known limitations / merchant FAQs

Why is this a cross-platform card? Because the finding only exists when you compare two systems. Oracle Inventory Cloud is the system of record for what you physically have; the ecommerce platform is what customers can buy. The card joins the two on the SKU and flags where they have drifted apart, which is something neither system can tell you on its own. What causes drift between Oracle and the storefront? Almost always a sync issue: a scheduled OIC flow that failed or ran partially, latency between an Oracle transaction and the next publish, a mapping that points the storefront at the wrong inventory org, or a SKU that went negative in Oracle. The sibling cards point to the specific cause. Why 5% and not an absolute quantity? Because the impact scales with the SKU. A 5% drift on a high-velocity SKU with thousands of units is a large absolute gap; a 5% drift on a slow mover is small. A percentage threshold treats every SKU proportionally. The card lists both the percentage and the absolute gap so you can prioritise. Which direction of drift is worse? It depends on your cost of failure. Storefront higher than Oracle causes oversell, with refunds, cancellations, and reputational cost. Storefront lower than Oracle causes phantom stockouts and silent lost sales. The card shows the sign so you can triage by the risk that matters most to your business. Does the storefront quantity reconcile to Oracle? No, and it should not. The storefront quantity is the commerce platform’s published availability, which appears in no Oracle report. That column is the cross-platform half of the card; the drift is the gap between it and Oracle’s on-hand. Can Vortex IQ correct the storefront quantity? No. Re-publishing inventory to the storefront and correcting Oracle on-hand are controlled actions inside your integration and inventory systems. Vortex IQ detects the drift, names the SKUs and the direction, and notifies owner, finance, and operations. Your team re-runs the sync or corrects the source in Oracle.

​
Tracked live in Vortex IQ Nerve Centre

SKUs with Fusion-vs-Ecom Inventory Drift >5% is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.