> ## 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. # SKUs with Intacct-vs-Ecom Inventory Drift >5%, Sage > SKUs whose Sage Intacct on-hand quantity differs from the ecommerce stock count by more than 5%. Drift causes oversell and stockout. Intacct Inventory module required. How to read it, why it matters, and how to act on it. **Card class:** [Cross-Channel](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > SKUs whose Sage Intacct on-hand quantity differs from the ecommerce stock count by more than 5%. Drift causes oversell and stockout. Intacct Inventory module required. ## At a glance > A table of the individual SKUs whose Sage Intacct on-hand quantity disagrees with the ecommerce stock count by more than 5%, sorted so the most dangerous drift sits at the top. Where [ERP-vs-Ecom Inventory Variance %](/nerve-centre/kpi-cards/sage/erp-vs-ecom-inventory-variance) gives you the single catalogue-level gauge, this card is the line-item drill behind it: the named SKUs you can actually fix. Negative drift (storefront higher than Sage) is oversell waiting to happen; positive drift (Sage higher than storefront) is sellable stock the channel cannot offer. Both cost money, and both are invisible to either system alone. The card requires the Sage Intacct Inventory module and hides for Sage Accounting merchants who carry no perpetual inventory. | | | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | A row per SKU where the absolute difference between Sage Intacct on-hand quantity (`InventoryItem.QuantityOnHand`, summed across fulfilment locations) and the ecommerce platform's available-to-sell count exceeds 5% of the Intacct figure. Columns show both quantities, the percentage drift, the direction, and the recent order velocity so you can triage by risk, not just by size of drift. | | **Threshold** | 5% is the default per-SKU trigger. Configurable per workspace and tunable per Class; high-velocity SKUs often drop to 2% because a small percentage is a large unit count at speed, while slow movers can relax to 10%. | | **Direction** | Negative (storefront higher than Sage) is the oversell risk and is weighted to the top. Positive (Sage higher than storefront) is missed-revenue. The direction column drives the action. | | **Velocity weighting** | Rows carry recent sales velocity so a 6% drift on a SKU selling 200 a day outranks a 40% drift on a SKU selling one a month. The card sorts by risk (drift times velocity), not by raw drift percentage. | | **Currency** | Not applicable. This is a quantity-parity table. Pair with [Sage Total Inventory Value](/nerve-centre/kpi-cards/sage/sage-total-inventory-value) to attach a dollar figure to the drifting SKUs. | | **Entity scope** | Card respects the dashboard entity filter. In Multi-Entity Console a SKU is evaluated per entity, because a SKU can be in parity in one warehouse and drifting in another. | | **Time window** | `RT/24H` | | **Alert trigger** | `>10 SKUs drifting`, sentiment `inventory_drift`. Configurable per workspace. The count threshold matters less than which SKUs are on the list; one high-velocity oversell SKU is worse than twenty dormant ones. | | **Roles** | owner, finance, operations | ## Calculation Calculated automatically by comparing Sage Intacct on-hand quantity against the connected ecommerce platform's stock count, per matched SKU. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A US merchant on Sage Intacct (single entity, USD) with an Inventory Control module of roughly 3,800 SKUs, selling through Shopify Plus DTC. Snapshot 14 Apr 26. The catalogue gauge reads 6.1% and this card lists 18 SKUs drifting more than 5%, above the 10-SKU alert line. The operations lead sorts by risk (drift times velocity). | SKU | Sage on-hand | Storefront count | Drift | Direction | Velocity (units/day) | | --------------------------------- | ------------ | ---------------- | ------ | ----------------- | -------------------- | | PLNT-204 (bestseller planter) | 320 | 380 | -18.8% | Storefront higher | 95 | | HOSE-88 (seasonal) | 140 | 168 | -20.0% | Storefront higher | 40 | | TOOL-512 | 60 | 52 | +13.3% | Sage higher | 22 | | SEED-77 | 410 | 360 | +12.2% | Sage higher | 8 | | MISC long-tail (14 SKUs) | various | various | 6-9% | mixed | \<2 each | | **SKUs drifting >5% (this card)** | **18** | | | | | Five things to notice: 1. **PLNT-204 is the row that matters, and it is at the top because of velocity, not because it has the largest percentage drift.** At 95 units a day with the storefront showing 60 more units than Sage actually holds, the channel will accept roughly 60 orders it cannot fulfil within the day, then keep overselling until someone corrects the count. A 20% drift on HOSE-88 looks worse on paper but at 40 units a day it does less damage. This is why the card sorts by drift times velocity rather than by raw percentage: the operations lead should fix PLNT-204 first, and the card puts it first automatically. 2. **The negative-drift SKUs (PLNT-204, HOSE-88) are the oversell emergencies; the positive-drift SKUs (TOOL-512, SEED-77) are the quieter missed-revenue problem.** Negative drift means the storefront promises stock Sage does not have: cancelled orders, refunds, support tickets, and lost trust, all today and all visible to customers. Positive drift means Sage holds stock the storefront is not offering: no customer harm, but real revenue left on the table. A good triage handles the negative-drift, high-velocity rows within the hour and batches the positive-drift rows into the daily inventory review. 3. **TOOL-512 at +13% positive drift is often a returns or receipt-timing artefact worth understanding before acting.** Sage holding more than the storefront on a moderate-velocity SKU frequently means stock was received or returned into Intacct and the storefront sync has not caught up, or the storefront is showing available-to-sell (net of committed) while Sage shows gross on-hand. Before manually correcting, the operations lead should check whether this is a real drift or a definition mismatch, because manually editing a count that the next sync would have fixed introduces a new error. 4. **The 14 long-tail SKUs at 6-9% drift and under 2 units a day are real drift but low risk, and the right response is to find the common cause rather than fix them one by one.** Fourteen low-velocity SKUs drifting just over the threshold usually share a root cause: a location not included in the fulfilment-eligible set, a UOM mapping gap, or a sync that excludes a product type. Fixing the 14 individually is busywork; finding the one configuration cause clears all 14 and prevents the next batch. This is where the card feeds [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift), which looks at whether drift persists across refreshes (a plumbing problem) or resolves on its own (a timing artefact). 5. **This table is the cross-channel join made actionable, and it is the level at which oversell is actually prevented.** The catalogue gauge tells leadership there is a parity problem; this card tells the operations lead exactly which SKUs to touch and in what order. Sage knows the true on-hand because it is the book of record; the storefront knows what it has promised customers; neither can compute the per-SKU disagreement alone. On this account the join caught PLNT-204 drifting two hours after a large wholesale receipt was posted to Intacct but failed to push to Shopify, before a single oversell order landed. That two-hour head start is the difference between a quiet count correction and a day of cancelled bestseller orders. It is the cross-channel finding that pays for the connector, and where the Implementation Partner usually demonstrates value to operations. ## Sibling cards merchants should reference together | Card | Why pair it with SKUs with Intacct-vs-Ecom Inventory Drift >5% | | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | [ERP-vs-Ecom Inventory Variance %](/nerve-centre/kpi-cards/sage/erp-vs-ecom-inventory-variance) | The catalogue-level gauge. This card is the SKU-level drill behind it. | | [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) | Tells you whether the drift is a one-off timing artefact or a persistent plumbing fault. | | [OOS with Open Order Demand](/nerve-centre/kpi-cards/sage/oos-with-open-order-demand) | Negative drift plus open demand is a confirmed oversell in flight. | | [Inventory Item On-Hand Went Negative](/nerve-centre/kpi-cards/sage/inventory-item-on-hand-went-negative) | A negative Intacct on-hand guarantees drift and flags a data integrity fault. | | [Low Stock Alerts](/nerve-centre/kpi-cards/sage/low-stock-alerts) | Drift near the reorder point is where oversell happens fastest. | | [Sage Total Inventory Value](/nerve-centre/kpi-cards/sage/sage-total-inventory-value) | Attaches a dollar figure to the drifting SKUs so you can size the exposure. | | [Slow-Moving Inventory (>90d)](/nerve-centre/kpi-cards/sage/slow-moving-inventory-90d) | Drift on dormant SKUs matters less; this tells you which rows are cold. | ## Reconciling against Sage **Where to look in Sage Intacct:** The native Sage Intacct views to run side by side with this card: > **Reports → Inventory Control → Item Stock Status** (real-time on-hand by Warehouse, the book-of-record quantity this card compares against the storefront) > **Reports → Inventory Control → Inventory Valuation** (on-hand by Location to confirm which locations should feed the sellable basis) > **Inventory Control → Items** with the on-hand and committed columns exposed, exported per SKU to compare against the storefront stock export > **Inventory Control → transaction history** for a specific drifting SKU, to see the recent receipt, sale, adjustment, or transfer that opened the gap > **Interactive Custom Report (ICR)** on the Inventory data source listing `ItemID`, `QuantityOnHand`, committed quantity, and `WarehouseID`, joined against the storefront export by SKU The reconciliation discipline is per-SKU timestamp alignment and definition matching. A SKU that drifts in a manual comparison but not on the card is almost always an available-vs-on-hand or a location-scope difference. Pull the Intacct transaction history for the disputed SKU: a recent receipt, return, or transfer usually explains the gap and tells you whether it is real drift or a sync that has not yet run. Common reconciliation pitfalls: * **Available-to-sell vs on-hand.** The storefront usually shows on-hand minus committed; Intacct on-hand is gross. A SKU with committed stock reads as positive drift in a raw comparison that the card correctly nets out. * **Location scope.** Intacct holds on-hand per location. If the storefront only fulfils from two of five locations, summing all five overstates the sellable basis and manufactures drift the card avoids by scoping to fulfilment-eligible locations. * **Unit of measure.** A SKU stocked in cases and sold in eaches drifts massively in a raw comparison until the UOM conversion is applied. The card applies it; a manual export does not. **Why our number may legitimately differ from a manual per-SKU comparison:** | Reason | Direction | Why | | ------------------------------------ | ---------------- | ---------------------------------------------------------------------------------------------------------------------------- | | **Available vs on-hand** | Card lists fewer | Card nets committed stock to compare like-for-like; a gross comparison reports committed-stock SKUs as drifting. | | **Location scope** | Card lists fewer | Card scopes to fulfilment-eligible locations; an all-location sum overstates the sellable basis. | | **Unit of measure** | Card lists fewer | Card applies UOM conversion; a raw case-vs-each comparison reports huge false drift. | | **Timestamp alignment** | Either | Card snapshots both sides at one moment; exports pulled hours apart show order and receipt activity as phantom drift. | | **Threshold and velocity weighting** | Card lists fewer | Card lists SKUs over 5% and ranks by velocity; a raw comparison lists every non-zero difference. | | **Negative on-hand** | Card lists more | A negative Intacct on-hand (data integrity issue) registers as drift; some manual reports floor on-hand at zero and hide it. | | **Unmatched SKUs** | Card excludes | SKUs with no storefront match are reported separately, not as 100% drift, which a naive join would do. | **Cross-connector reconciliation:** | Card | Expected relationship | What the comparison reveals | | ----------------------------------------------------------------------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | [shopify.inventory\_value](/nerve-centre/shopify/inventory_value) | Per-SKU source | Shopify's per-variant stock is the storefront side of each row. The drift against Intacct on-hand is what the card lists. | | [bigcommerce.inventory\_value](/nerve-centre/bigcommerce/inventory_value) | Per-SKU source | Same for the BigCommerce catalogue; channel-scope exclusions must be mapped so by-design gaps are not listed. | | [adobe\_commerce.inventory\_value](/nerve-centre/adobe_commerce/inventory_value) | Multi-source caveat | Adobe Commerce Multi-Source Inventory holds per-source stock; the row must target the source mapped to the Intacct location. | | [ERP-vs-Ecom Inventory Variance %](/nerve-centre/kpi-cards/sage/erp-vs-ecom-inventory-variance) | Roll-up | This table aggregates into that gauge. The SKUs here are the ones moving the catalogue number. | | [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) | Diagnostic | A SKU drifting on this card every refresh is a connector mapping fault, not real movement. | | [OOS with Open Order Demand](/nerve-centre/kpi-cards/sage/oos-with-open-order-demand) | Oversell confirmation | A negative-drift SKU with open demand is a confirmed oversell already in flight, the most urgent row. | The cross-channel high-leverage finding is that Sage Intacct is the book of record for what you physically hold and the ecommerce platform is the promise you make to customers, and the two drift apart constantly: a receipt posts to Intacct but does not push to the storefront, a return goes back into Intacct but the storefront count is stale, an adjustment corrects Intacct but the sync lags. Each of these opens a per-SKU gap that neither system can see on its own, because Intacct does not know what the storefront promised and the storefront does not know what Intacct actually holds. This card joins them at the SKU level, ranks the drift by how much damage it can do, and surfaces the dangerous oversell rows before a customer ever sees an out-of-stock cancellation. Catching a high-velocity bestseller drifting two hours after a botched sync, before the first oversell order lands, is the kind of finding that single-system dashboards structurally cannot produce, and it is where the Vortex IQ Implementation Partner conversation with operations usually begins. ## Known limitations / merchant FAQs **Why does this card not appear in my dashboard?** The card requires the Sage Intacct Inventory Control module. Sage Accounting and standard Sage 50 / 200 do not maintain a perpetual inventory ledger, so there is no on-hand quantity to compare per SKU. The card hides itself for those merchants rather than showing a misleading empty table. **Why does the card sort by velocity and not by the size of the drift?** Because a small percentage drift on a fast-moving SKU does far more damage than a large drift on a dormant one. A 6% gap on a SKU selling 200 a day oversells dozens of units within the day; a 40% gap on a SKU selling one a month harms almost nobody. Sorting by drift times velocity puts the rows that will actually cause cancelled orders at the top, which is where triage time should go. **Negative drift and positive drift, which do I fix first?** Negative drift (storefront higher than Sage) first, always, because it causes oversell: cancelled orders, refunds, support load, lost trust, all visible to customers today. Positive drift (Sage higher than storefront) is missed revenue, which costs money but harms no customer and can be batched into the daily review. The direction column tells you which is which. **A SKU shows positive drift but I think the count is right, what is happening?** Most often a definition mismatch. The storefront shows available-to-sell (on-hand minus committed) while Intacct shows gross on-hand, so a SKU with committed stock reads as Sage-higher. Or stock was just received or returned into Intacct and the storefront sync has not run yet. Check the Intacct transaction history before manually editing; a manual correction of a count the sync would have fixed introduces a new error. **Several low-velocity SKUs are drifting together, is that one problem?** Usually yes. A cluster of low-velocity SKUs drifting just over the threshold typically shares a root cause: a location excluded from the fulfilment-eligible set, a UOM mapping gap, or a sync that skips a product type. Find the common cause rather than fixing them one by one; the shared fix clears the cluster and prevents recurrence. [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) helps confirm whether the drift is structural. **Is 5% the right per-SKU threshold?** It depends on velocity. High-velocity SKUs should drop to 2% because a small percentage is a large unit count at speed. Slow movers can relax to 10% because the drift self-corrects before it causes harm. Tune per Class so the threshold matches the risk profile of each part of the catalogue. **Does unit of measure cause false rows?** Yes, and it is the most common first-connect false positive. A SKU stocked in cases in Intacct but sold in eaches drifts massively until the UOM conversion is mapped. Whenever a SKU shows an implausibly large drift, check UOM first; once mapped, the row disappears. **How fresh is the comparison?** The Intacct side refreshes from the most recent inventory movement, typically within 5 to 15 minutes. The storefront side refreshes on the connector's sync cadence. The card timestamps both sides and reports drift as of a single aligned moment, which is why it is more reliable than two manual exports pulled at different times of day. **How does this relate to the catalogue variance gauge?** This card is the line-item drill behind the [ERP-vs-Ecom Inventory Variance %](/nerve-centre/kpi-cards/sage/erp-vs-ecom-inventory-variance) gauge. The gauge tells leadership how bad the parity problem is overall; this table tells the operations lead exactly which SKUs to fix and in what order. Read the gauge for the headline and this card for the action. **Implementation Partner role on this metric?** The Partner usually owns the Intacct Inventory Control configuration, the location and UOM setup, and the connector field map that aligns SKUs and definitions across systems. If SKUs appear here that the operations lead believes are in parity, the cause is almost always a definition mismatch (available vs on-hand, all-locations vs fulfilment-locations, case vs each) the field map can resolve. Bring the Partner in to confirm the field map before treating the list as a manual-correction backlog. *** ### Tracked live in Vortex IQ Nerve Centre *SKUs with Intacct-vs-Ecom Inventory Drift >5%* is one of hundreds of KPI pulses Vortex IQ tracks across Sage 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.