> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # ERP-vs-Ecom Inventory Variance %, Microsoft Dynamics 365 > ERP-vs-Ecom Inventory Variance % gauges how far D365 on-hand drifts from your commerce feed. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > The summary gauge for how far your commerce platform's inventory has drifted from D365, the system of record. Above 5% means a sync problem. ## At a glance > The aggregate percentage of SKUs (or units) whose on-hand quantity differs between Dynamics 365 (the system of record) and the commerce platform's inventory feed. It is a single health gauge: low is good (the two systems agree), high means the sync between F\&O / BC and your storefront is drifting. The per-SKU detail behind this gauge lives on the [SKUs with D365 vs Ecom Inventory Drift >5%](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift) card. | | | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The share of compared SKUs (or units, depending on configuration) where D365 on-hand and commerce-platform available quantity disagree beyond the drift tolerance. Conceptually `count(drifted SKUs) / count(compared SKUs)`, expressed as a percentage and rendered as a gauge. D365 on-hand comes from the inventory layer (AvailablePhysical in F\&O, Item Availability in BC); the commerce side comes from each connected storefront's inventory feed. | | **What "variance" means** | A SKU is in variance when its D365 sellable on-hand and the commerce platform's available-to-sell quantity differ by more than the configured tolerance. The gauge aggregates those flagged SKUs into one percentage. | | **Multi-platform** | Where a merchant runs more than one storefront (e.g. Shopify Plus plus a B2B BigCommerce or Adobe Commerce instance), each mapped SKU is compared against the storefront it is published to. The gauge is the blended drift across all mapped channels. | | **Multi-Company / legal entity** | Respects the selected legal-entity filter. SKUs are compared within their owning entity so a multi-entity tenant does not cross-count stock between companies. | | **Time window** | `RT/24H` (real-time gauge, evaluated against a rolling 24-hour comparison) | | **Alert trigger** | `>5%`. When aggregate variance exceeds 5%, the gauge enters the warning band and the Nerve Centre raises an alert. Sustained breach points at a sync failure rather than normal timing noise. | | **Roles** | owner, finance, operations | ## Calculation Calculated automatically from your Microsoft Dynamics 365 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 mid-market apparel brand syncs Finance & Operations to a Shopify Plus storefront via a dual-write / Power Automate integration. The gauge is read 21 Mar 26. The catalogue has 4,200 mapped SKUs. | Measure | Value | | ------------------------------------------------- | -------- | | Mapped SKUs compared | 4,200 | | SKUs within tolerance | 3,906 | | SKUs in variance (beyond tolerance) | 294 | | **ERP-vs-Ecom Inventory Variance % (this gauge)** | **7.0%** | | Alert threshold | 5% | Four things to notice: 1. **At 7.0% the gauge is in the warning band.** It has crossed the 5% threshold, so the Nerve Centre has raised an alert. Below 5% this is usually just timing noise (a sale on the storefront not yet pushed to F\&O, a receipt in F\&O not yet published to the store). Above 5% it is structural and worth investigating today. 2. **The gauge does not tell you which SKUs.** That is by design. This card is the summary health reading; the 294 individual drifted SKUs, with the D365 quantity, the commerce quantity, and the gap, are listed on [SKUs with D365 vs Ecom Inventory Drift >5%](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift). Start at the gauge, drill to the list. 3. **The likely root cause is the integration, not the data.** A spike from a steady 1 to 2% baseline up to 7% usually means the sync stopped or slowed. Check [Power Automate Flow Failures (ecom integration)](/nerve-centre/kpi-cards/microsoft-dynamics/power-automate-flow-failures-ecom-integration) first; a failed inventory-push flow is the most common reason the two systems diverge. 4. **High variance plus open demand is the dangerous combination.** If drifted SKUs are also ones with open sales-order demand, you risk overselling on the storefront or starving real orders. Cross-reference [OOS with Open Sales-Order Demand](/nerve-centre/kpi-cards/microsoft-dynamics/oos-with-open-sales-order-demand) and [Low Stock Alerts](/nerve-centre/kpi-cards/microsoft-dynamics/low-stock-alerts) when the gauge is high. ## Sibling cards merchants should reference together This gauge is the summary. Pair it with these to find the cause and the consequence of the drift. | Card | Why pair it with ERP-vs-Ecom Inventory Variance % | | ------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | [SKUs with D365 vs Ecom Inventory Drift >5%](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift) | The per-SKU detail behind this gauge. The gauge says "how bad"; this card says "which items, by how much". Always your first drill. | | [Inventory Sync Drift](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift) | The broader sync-health view of how the ERP and storefront inventory are tracking over time, beyond a single threshold gauge. | | [Power Automate Flow Failures (ecom integration)](/nerve-centre/kpi-cards/microsoft-dynamics/power-automate-flow-failures-ecom-integration) | The most common root cause. A failed inventory-push flow is usually why the gauge spikes. Check it first when variance jumps. | | [Low Stock Alerts](/nerve-centre/kpi-cards/microsoft-dynamics/low-stock-alerts) | Drift on low-stock SKUs is the riskiest kind: it is exactly where overselling or stockout happens. | | [OOS with Open Sales-Order Demand](/nerve-centre/kpi-cards/microsoft-dynamics/oos-with-open-sales-order-demand) | The consequence. When drifted SKUs also carry open demand, the storefront and the ERP disagree on whether you can fulfil. | ## Reconciling against Microsoft Dynamics 365 **Where to look in Business Central / Finance & Operations:** The closest native equivalents in the Dynamics UI are: > **F\&O > Inventory management > Inquiries and reports > On-hand inventory** (the D365 side of the comparison, per item / warehouse) > **F\&O > Data management > Data project execution history** (whether the inventory export to the storefront ran) > **Business Central > Inventory > Item Availability by Location** (the BC equivalent on-hand) > **Power Platform admin > Power Automate > flow run history** (the actual push of D365 quantities to the storefront) To verify a single drifted SKU, open On-hand inventory for the item in F\&O (or Item Availability in BC), note the sellable quantity, then open the same SKU in the storefront admin and compare the available-to-sell figure. The gap you see by hand should match the gap the per-SKU drift card reports. D365 is the reference: the storefront should be reconciled to it, not the other way round. Common mistakes when comparing the two systems by hand: * **Comparing physical to sellable.** D365 on-hand can include reserved, blocked, or non-nettable quantity. The storefront usually publishes available-to-sell. Compare like for like (sellable to sellable) or the gap is an illusion. * **Wrong warehouse scope.** If the storefront is fed from one warehouse but you check total on-hand across all warehouses in D365, the numbers will never tie. * **Timing.** A sale that just happened on the storefront has not yet decremented F\&O until the order syncs. A momentary gap is normal; a persistent one is drift. **Why our number may legitimately differ from a manual check:** | Reason | Direction | Why | | ----------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sellable vs physical definition** | Either | The gauge compares sellable-to-sellable using the configured field map. A manual check that uses raw physical on-hand will show a different gap than the card. Confirm the field map matches your fulfilment logic. | | **Warehouse feed scope** | Either | If only certain warehouses feed the storefront, the comparison is scoped to those. A whole-company on-hand check will not match. | | **Tolerance band** | Card lower count | The gauge only counts SKUs beyond the configured tolerance. A by-hand check that flags any non-zero gap will count more SKUs than the gauge. | | **Sync timing window** | Either | The gauge evaluates against a rolling 24-hour comparison. A spot manual check at a different instant catches different in-flight transactions. | | **Multi-platform blending** | Either | The gauge blends drift across all mapped storefronts. Checking one storefront by hand will not reproduce the blended figure. | **Cross-connector note:** This is the most cross-connector card in the inventory set by nature: it only exists because two systems (D365 and the commerce platform) are being compared. The D365 side is always the system of record. When the gauge is high, the fix is almost always on the integration or the storefront side, and [Power Automate Flow Failures (ecom integration)](/nerve-centre/kpi-cards/microsoft-dynamics/power-automate-flow-failures-ecom-integration) is where the evidence usually is. ## Known limitations / merchant FAQs **What is a "good" number on this gauge?** Below the configured tolerance, typically under 5%, is healthy and reflects normal timing noise between the two systems. Above 5% the gauge enters the warning band and signals a structural sync problem rather than ordinary lag. **Why is the threshold 5% and not zero?** Because the two systems are never instantaneously identical. A sale on the storefront, a receipt in F\&O, and the sync that reconciles them all happen at slightly different moments. A small, constantly-churning gap is expected. The 5% band separates that healthy noise from a real failure. **This gauge is high but every SKU I check looks fine. Why?** Almost always a definition mismatch. D365 on-hand may include reserved or blocked quantity while the storefront publishes available-to-sell, or you are comparing across the wrong warehouse scope. Compare sellable-to-sellable for the warehouse that actually feeds the store. The per-SKU drift card shows exactly which figures it is comparing. **Which direction is the variance? Is the storefront over or under?** The gauge itself is direction-agnostic, it measures magnitude. To see whether the storefront is showing more or less than D365 per SKU, open [SKUs with D365 vs Ecom Inventory Drift >5%](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift), which shows both quantities and the signed gap. **The gauge spiked overnight. What do I check first?** The integration. A failed or throttled inventory-push usually causes a sudden jump. Open [Power Automate Flow Failures (ecom integration)](/nerve-centre/kpi-cards/microsoft-dynamics/power-automate-flow-failures-ecom-integration); a cluster of failed inventory flows in the same window is the smoking gun. **Does this work with dual-write as well as Power Automate?** Yes. The gauge does not care how the inventory gets synced; it compares the end state in D365 against the end state in the storefront. Whether the pipe is dual-write, Power Automate cloud flows, or a third-party connector, the drift shows up here the same way. **Why SKUs and not just units?** Counting SKUs answers "how much of my catalogue is out of sync", which is the operational question. A units-based view can be configured where the merchant cares more about total drifted quantity than catalogue breadth. The per-SKU card shows the unit gaps regardless. **Can a brand-new product inflate the gauge?** Yes, briefly. A SKU created in D365 but not yet published to the storefront (or vice versa) reads as drifted until both sides catch up. A steady stream of new launches can keep a small baseline variance that is not a fault. *** ### Tracked live in Vortex IQ Nerve Centre *ERP-vs-Ecom Inventory Variance %* is one of hundreds of KPI pulses Vortex IQ tracks across Microsoft Dynamics 365 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.