SKUs whose on-hand count differs between Sage Intacct (system of record) and commerce platform. Sync-failure detector.
At a glance
SKUs whose on-hand count drifts between Sage Intacct (the system of record for Inventory Control) and the commerce platform’s published storefront stock count. The operational twin of the Revenue Gap card: same root cause (sync failure between Intacct and commerce), different symptom (inventory not revenue). Each row is one Item with the Intacct on-hand, the commerce-platform on-hand, the absolute drift, and the owning Intacct dimension (Item, Location, Warehouse).
Calculation
Calculated automatically from your Sage 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 US B2B distributor on Sage Intacct Multi-Entity Console with three Locations: a primary warehouse in New Jersey (USD entity), a secondary in Texas (USD entity), and a Canadian DC in Ontario (CAD entity). BigCommerce B2B Edition on the front-end. Intacct’s Inventory Control module is the system of record. Reading: real-time on 02 May 26. Headline: 47 Items showing drift, total absolute drift across all Items: 1,184 units. Largest single-Item drift: SKUWIDGET-PRO-A at 142 units.
Top 8 drift cases:
Five things to notice:
- WIDGET-PRO-A’s 142-unit drift is the highest-priority but lowest-risk row. Intacct shows 384, commerce shows 526. The Implementation Partner posted a 142-unit Inventory Adjustment yesterday afternoon (a cycle count revealed the warehouse had over-counted in the prior period and the adjustment wrote down the on-hand). The commerce-side stock count has not yet refreshed because the integration runs on a 60-minute pull cadence. Risk: in the next 4 hours, customers can place orders for stock that does not exist (commerce thinks 526, reality is 384). Recovery: force-refresh the integration immediately, then post a manual stock-adjustment to commerce. Systemic fix: configure inventory-adjustment webhooks from Intacct (push) rather than poll-based (pull); most integrations support this but it requires the Web Services User permission to be configured.
- GADGET-2026-X’s 84-unit drift is the killer over-sell risk. Intacct shows 0, commerce shows 84. This is not “stock we cannot sell”; this is “stock the storefront thinks it can sell that does not exist on the floor”. Every order placed against GADGET-2026-X right now generates a customer-promised order with no fulfilment. Recovery, immediate: pause the SKU on commerce (set on-hand to 0 or hide it) within the next 30 minutes. Investigate the source of the phantom 84: a stale CSV import that loaded a planning forecast as on-hand, a duplicate Item record in commerce, or a manual override an admin set. The 84 units never existed in Intacct; the commerce side is wrong.
- KIT-VEGA-2026’s 64-unit drift traces to the credential rotation. Yesterday’s credential rotation broke the webhook delivery; 64 units of Sales Order fulfilment shipped from the warehouse and were posted to Intacct’s Item.on_hand reduction, but the webhook to commerce did not fire because the credential was bad. Recovery: replay the webhook queue (Vortex IQ stores the failed deliveries in its dead-letter queue for 7 days) once the credential is rotated. Systemic fix: monitor webhook delivery success rate as a separate alert; this should be the first card the Operations team checks at 9am.
- BUNDLE-SOLAR’s drift = 0 is interesting because the Location split has shifted, not the total. Intacct shows 100 NJ + 45 TX = 145; commerce shows 145 all-NJ. From a total-stock perspective the drift is zero, but from an order-routing perspective the commerce side will route every order to NJ even if TX is closer to the customer. This is the silent multi-Location issue. The fix is to enable per-Location stock display on the commerce platform (BigCommerce supports this, Shopify Plus supports this, Adobe Commerce supports this), then map Intacct Locations to commerce locations in the field map.
- WIDGET-PRO-B’s 78-unit drift in the TX warehouse highlights the Location-dimension mapping gap. TX-Secondary was added to Intacct last week as a new Location dimension, but the commerce integration only had NJ-Primary configured at setup. Until the field map is updated to include TX-Secondary, every TX-on-hand unit is invisible to commerce. 78 units of WIDGET-PRO-B sit unsellable because the storefront never sees them. Recovery: extend the field map’s Location-dimension mapping to include TX-Secondary, then resync the affected Items.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Sage Intacct: Sage Intacct’s Inventory Control module is the system of record for on-hand. The closest native views are:Reports → Inventory → Stock Status by Item with the Location dimension pinned (the per-Location on-hand snapshot) Reports → Inventory → Inventory Adjustment Log for recent stock-corrections that may explain transient drift Interactive Custom Report against the Inventory Item data source for an audit-grade tie-out, joined onThe commerce-platform side: BigCommerce Admin’s Products report, Shopify Admin’s Inventory page, Adobe Commerce’s Catalog → Inventory view. Manually diff per Item and per Location. The Implementation Partner pattern: most Partners run the cycle-count workflow inside Intacct (cycle count posts as an Inventory Adjustment), which corrects Intacct’s on-hand. The commerce-side correction is downstream of the integration; if the Partner’s adjustment is large and the integration is poll-based, the drift appears immediately and resolves on next sync. If the integration is webhook-based with proper retry logic, the drift appears for under a minute. Why our drift list may legitimately differ from a manual cross-check:ITEM.NAMEandLOCATION.NAMEOrder Entry → Open Orders by Item to see SOs that have committed stock and reduced available-to-promise
Cross-connector reconciliation:
This card IS the cross-connector inventory-leak detector. The Sage Intacct dimensional advantage shows up most clearly in the per-Location split case (BUNDLE-SOLAR in the Worked Example) and the new-Location-mapping case (WIDGET-PRO-B in TX-Secondary): both are Location-dimension issues that need a dimensional read to diagnose. Other ERP equivalents (NetSuite Locations, SAP Plants, Acumatica Warehouses) have similar concepts but lack the queryable-dimension parity that makes the Intacct read so direct. For multi-Location merchants, this card is one of the strongest reasons to choose Intacct as the financial spine.
Known limitations / merchant FAQs
My drift count is consistently 5 to 10 Items. Should I worry? Probably not. A small steady-state drift count usually reflects the integration’s poll cadence (Items in flux during the sync window) and a few low-velocity SKUs near the tolerance edge. Investigate when the count spikes above your normal baseline, not when it sits at the baseline. My drift count just spiked from 4 to 78. What happened? Three usual causes: (1) a credential rotation broke webhook delivery (KIT-VEGA-2026 case in the Worked Example), (2) the Implementation Partner posted a large Inventory Adjustment outside the integration’s notification window (WIDGET-PRO-A case), or (3) a new Location dimension was added in Intacct without updating the field map (WIDGET-PRO-B case). Open the Vortex IQ event log and the Intacct Inventory Adjustment Log for the time the spike occurred; one of those three causes will be evident. Should I tune tolerance per Item? Yes for any merchant with mixed-velocity inventory. Set tighter tolerance (±1) for top-50 velocity Items where over-sells are reputationally damaging; set looser (±10 or ±20) for the long tail where small drifts are economically inconsequential. The field map supports per-Item tolerance overrides; most merchants configure tolerance by Item Class (high-velocity Class = ±1, slow-velocity Class = ±10). Multi-Location: how do I read drift when commerce shows aggregated stock and Intacct shows per-Location? Configure the field map to aggregate Intacct on-hand across the configured Location set before comparison. The card then reads as a total-stock comparison; the Location-dimension column shows the Locations included in the aggregate. The per-Location split issue (BUNDLE-SOLAR case) requires the commerce platform to support per-Location stock display; if it does not, this is a structural limit not a sync issue. Available-to-promise vs on-hand: which does Intacct sync to commerce? Configurable. Most Intacct integrations sync available-to-promise (on-hand minus committed Sales Orders) because that is the number a commerce shopper should see. Some merchants prefer to sync raw on-hand and have commerce subtract committed-SO at the storefront level. Vortex IQ reads whichever Intacct field your field map points at; confirm the setting if you see persistent drift equal to the committed-SO total. Sage Intacct Inventory Control vs the Sage Intacct ASSETS module: which feeds this card? Inventory Control. The ASSETS module tracks fixed assets, not stock. This card readsINVENTORYITEM.QTYONHAND from the Inventory Control module’s data source.
REST vs XML API freshness, does it affect this card?
Yes, more than for revenue cards. Inventory changes happen at higher frequency than revenue postings (every Sales Order fulfilment, every Purchase Order receipt, every Inventory Adjustment). The XML API is faster for bulk reads of the on-hand snapshot; REST is used for incremental change-event delivery where supported. For real-time intraday accuracy, ensure the field map is configured for the highest-frequency available source.
My Implementation Partner says all my drifts are normal “in-flight” inventory. Are they right?
Sometimes. In-flight inventory (units committed to an open Sales Order but not yet shipped) is normal and accounts for some drift. The diagnostic test: drift on Items with no open SOs is a sync issue; drift on Items with large open-SO totals matches the available-to-promise vs on-hand setting (see above). Cross-reference Open Orders per Item to separate the two cases.
Can I auto-resync drifted Items from this card?
Yes via Ask Viq. Vortex IQ supports a “force resync” action that re-reads Intacct on-hand for the listed Items and pushes the corrected count to commerce. Requires merchant authorisation and the relevant integration permissions. The action is idempotent: if Intacct’s on-hand has already changed since the drift was detected, the resync uses the new Intacct value as authoritative.
What about kits, bundles, and assemblies?
Sage Intacct’s Inventory Kit functionality (or assemblies in some configurations) means a “kit Item” is composed of component Items. Commerce platforms typically treat the kit as a single sellable Item with a single on-hand count. The drift comparison runs at the kit-Item level, not the component-Item level, so a kit shows drift only if the kit’s published count diverges from Intacct’s kit-availability. Component-level drift is invisible to this card; for component-stock visibility, run a separate per-component query.
Sage Intacct vs NetSuite vs Acumatica on this card?
NetSuite has the most mature multi-Location support (Inventory Item Locations subrecord) but the dimensional cut requires SuiteAnalytics workbooks. Sage Intacct’s Location dimension is queryable directly from the GL Detail and Inventory Item data sources, which makes the card’s per-Location decomposition cleaner. Acumatica’s warehouse model is similar to Intacct but the API surface is less mature. For multi-warehouse mid-market merchants, Intacct is typically the cleanest fit; for single-warehouse merchants, all three behave similarly on this card.
My Multi-Entity Console account: should I run drift detection per entity or consolidated?
Per entity. Each entity in Multi-Entity Console has its own Inventory Control module and its own Locations. Aggregating across entities would mix US-warehouse stock with Canadian-warehouse stock, which is operationally meaningless. The card defaults to per-entity drift; the dashboard filter respects the entity scope.