> ## 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. # Inventory Item On-Hand Went Negative, Sage > Inventory Item On-Hand Went Negative. A real-time alert table of inventory items whose on-hand quantity dropped below zero in Sage Intacct Inventory Control. 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) > A real-time alert table of inventory items whose on-hand quantity dropped below zero. Each row is an oversell, a mis-sequenced receipt, or a sync race that is quietly corrupting your inventory valuation. ## At a glance > A live alert table, not a single number. Each row is an Inventory Item whose `QuantityOnHand` has gone below zero in Sage Intacct's Inventory Control module. Negative on-hand is never physically real (you cannot hold minus three units), so every row is a data event: an oversell that shipped before stock was received, an issue posted before its receipt, a sync race between the commerce platform and Intacct, or a costing artefact. It matters because negative on-hand silently distorts inventory valuation, average cost, and COGS, and it is the symptom that most reliably predicts an oversold customer order about to disappoint someone. This card is Intacct Inventory Control only; for Sage Accounting merchants who do not run perpetual inventory, the card hides itself rather than showing an empty state. | | | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | One row per Inventory Item where `QuantityOnHand < 0` at any tracked Location. Read live from Intacct's Inventory Control item stock status. The card surfaces the item, the offending Location, the negative quantity, the unit cost basis, and the resulting negative valuation impact. | | **Why negative is impossible but happens** | On-hand cannot be physically negative, so a negative value is always a sequencing or sync problem: an issue (sale, transfer out, adjustment) posted before the matching receipt; an order shipped against stock the system thinks exists but has not yet recorded; or a race where the commerce platform decremented faster than Intacct recorded the receipt. | | **Intacct only** | Requires the Inventory Control module with perpetual inventory tracking. Sage Accounting / 50 / 200 merchants without perpetual inventory have no `QuantityOnHand` concept, so the card hides for them rather than rendering empty. | | **Costing impact** | Negative on-hand corrupts average-cost calculations. Under average costing, issuing more than you hold forces the system to cost units it does not have, which skews the running average and therefore COGS and margin on every subsequent transaction for that item. | | **What each row shows** | Item ID and name, Location, negative quantity, unit cost, negative valuation impact, last movement timestamp, and the transaction type that pushed it negative. | | **Currency** | Valuation impact in the entity's base currency, summed in reporting currency at the configured FX cadence per entity. | | **Entity scope** | Card respects the dashboard entity filter; for Multi-Entity Console run on all entities during peak trading so a remote warehouse's oversell does not slip. | | **Time window** | `RT` | | **Alert trigger** | `any quantity on hand < 0 (Intacct only)`. Configurable per workspace; some teams tolerate a small negative buffer for known backorder workflows. | | **Roles** | owner, operations, engineering | ## 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 UK DTC brand on Sage Intacct with the Inventory Control module, selling through Shopify Plus (DTC) and BigCommerce B2B (wholesale), fulfilling from two warehouses tracked as Intacct Locations (Main DC and Returns DC). Average costing. Snapshot 23 Jun 26, during a flash-sale weekend. Reporting currency GBP. Threshold set to any negative. | Item | Location | On-hand qty | Unit cost (GBP) | Valuation impact (GBP) | Likely cause | | ------------------------------ | ---------- | ------------- | --------------- | ---------------------- | -------------------------------------------------- | | SKU-APP-114 (hero hoodie) | Main DC | -38 | 22.00 | -836.00 | Oversell during flash sale, receipt not yet posted | | SKU-ACC-007 (gift box) | Main DC | -12 | 4.50 | -54.00 | Issue posted before goods receipt | | SKU-APP-220 (bundle component) | Main DC | -9 | 18.00 | -162.00 | Assembly build consumed before component receipt | | SKU-RET-003 | Returns DC | -3 | 31.00 | -93.00 | Return processed at wrong Location | | **Rows on this card** | | **-62 units** | | **-1,145.00** | | Five things to notice: 1. **SKU-APP-114 at minus 38 is the row that becomes a customer-service incident, and it is the reason this card is a hero, not a footnote.** During the flash sale the Shopify storefront kept selling the hoodie because the inventory sync had not yet pushed the sold-out signal, while Intacct recorded the issues against stock whose replenishing receipt was still sitting on a goods-in desk. Thirty-eight orders are now committed against stock that does not exist. Every one of those is a delayed shipment, a refund, or an angry email, and the brand will not know until the warehouse cannot pick them. The card surfaces it in real time so operations can pause the listing, expedite the inbound receipt, or proactively contact the affected customers before they contact you. Pair with [OOS with Open Order Demand](/nerve-centre/kpi-cards/sage/oos-with-open-order-demand) to see the demand side of the same event. 2. **SKU-ACC-007 and SKU-APP-220 are sequencing problems, not oversells, and they are fixed differently.** The gift box went negative because an issue (a sale or a kit consumption) posted before the matching goods receipt was entered, a classic timing gap when the warehouse ships before the receiving clerk keys the inbound. The bundle component went negative because an Assembly Build consumed it before its own receipt posted. Neither is a true oversell; both correct themselves the moment the missing receipt is entered with the correct date. The fix is process discipline (receive before you issue) plus, in Intacct, considering whether to allow negative inventory at all for these Locations. 3. **The valuation impact column is why finance cares, not just operations.** Under average costing, every unit issued below zero forces Intacct to cost stock it does not hold, which distorts the running average unit cost. That distorted average then flows into COGS and margin on the next sale of the same item, so a negative-on-hand event quietly poisons margin reporting until it is cleared. The GBP 1,145 negative valuation here is small, but the second-order effect on average cost and reported margin is the real cost. This is why the card carries owner and engineering roles, not just operations: it is a data-integrity problem with a financial tail. 4. **SKU-RET-003 at the Returns DC is a Location error, the cheapest kind to fix.** A return was processed against the Returns DC Location when the physical stock went back to the Main DC, so one Location reads negative while another reads artificially high. The net group on-hand is correct; the per-Location split is wrong. The fix is an inventory transfer or a corrected return Location, and it is worth fixing promptly because per-Location accuracy is what feeds the commerce sync, so a negative Returns DC can suppress availability the storefront should be showing. 5. **An empty table is the goal, and a card that never empties is a process diagnosis.** Occasional rows during peak trading are normal and self-correcting. A table that is never empty means one of three structural things: negative inventory is allowed at a Location that should not allow it, the goods-receipt process consistently lags the issue process, or the commerce sync is racing Intacct under load. Pair with [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) and [SKUs with Intacct vs Ecom Inventory Drift > 5](/nerve-centre/kpi-cards/sage/skus-with-intacct-vs-ecom-inventory-drift-5) to tell a sync race apart from a sequencing-discipline gap. The cause determines whether the fix is a setting, a process, or an integration change. ## Sibling cards merchants should reference together | Card | Why pair it with Inventory Item On-Hand Went Negative | | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) | A sync race is a leading cause of negative on-hand. Drift tells you it is the integration, not the warehouse. | | [SKUs with Intacct vs Ecom Inventory Drift > 5](/nerve-centre/kpi-cards/sage/skus-with-intacct-vs-ecom-inventory-drift-5) | The per-SKU variance view that confirms which items the commerce platform and Intacct disagree on. | | [OOS with Open Order Demand](/nerve-centre/kpi-cards/sage/oos-with-open-order-demand) | The demand side of an oversell: orders committed against stock that is not there. | | [Low Stock Alerts](/nerve-centre/kpi-cards/sage/low-stock-alerts) | Items approaching zero are the ones most likely to tip negative under a sync race. | | [ERP vs Ecom Inventory Variance](/nerve-centre/kpi-cards/sage/erp-vs-ecom-inventory-variance) | The headline variance between systems that negative on-hand feeds into. | | [Sage Total Inventory Value](/nerve-centre/kpi-cards/sage/sage-total-inventory-value) | Negative on-hand corrupts the valuation total. This is the number it distorts. | | [Sage COGS Total](/nerve-centre/kpi-cards/sage/sage-cogs-total) | Negative on-hand skews average cost, which flows straight into COGS. | | [Sage Health Score](/nerve-centre/kpi-cards/sage/sage-health-score) | Data-integrity faults like this pull the composite ledger-health number down. | ## 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** is the real-time on-hand by Location, where the negative values are directly visible. > **Reports → Inventory Control → Inventory Valuation** shows the dollar impact of the negative quantities on the asset value. > **Lists → Inventory Control → Item → (item) → Transactions** is the per-item movement history that reveals the issue-before-receipt sequencing that pushed it negative. > **Company → Setup → Inventory Control → Warehouse / Location** configuration shows whether "allow negative inventory" is enabled for each Location. > **Interactive Custom Report (ICR)** on the inventory data source filtered to `QuantityOnHand < 0`, grouped by Location and Item. For Multi-Entity Console accounts, run Item Stock Status at the same entity scope as the dashboard filter, because a negative at a remote-entity Location will not show in a single-entity report. Common reconciliation pitfalls: * **Allow-negative-inventory setting.** If Intacct is configured to allow negative on-hand at a Location, the GL will happily post issues below zero and the negatives accumulate silently. If it is configured to block them, the offending transaction errors instead, which moves the problem to [Transactions Failing Validation (imbalance / missing VAT)](/nerve-centre/kpi-cards/sage/transactions-failing-validation-imbalance-missing-vat). Know which mode each Location is in before reconciling. * **Location vs total.** A SKU can be negative at one Location and positive at another, with a correct net group total. The card surfaces the per-Location negative because that is what feeds the commerce sync and the per-Location valuation; the total report can look fine while a Location is wrong. * **Costing method.** Average costing produces a cost distortion when on-hand goes negative; standard costing values at the standard regardless, so the valuation impact reads differently. Confirm the item's `COSTMETHOD` before reconciling the dollar figure. **Why our number may legitimately differ from a Sage Intacct stock report:** | Reason | Direction | Why | | --------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Refresh timing** | Either | Card refreshes live (typically 5 to 15 minutes from the last Intacct movement); a stock report run mid-correction may show a negative the card has already cleared, or vice versa. | | **Location granularity** | Card may show more rows | Card surfaces per-Location negatives; a total-on-hand report nets Locations and can hide a negative offset by a positive elsewhere. | | **Allow-negative setting** | Either | Where negative is blocked, the failed transaction shows on the validation card instead of here; where it is allowed, the negatives accumulate here. | | **In-transit and on-order** | Card excludes | Goods in transit and open POs are not on-hand, so they do not net against a negative until received. A report that includes available-to-promise can read higher. | | **Costing method** | Card may shift valuation | Average vs standard costing values the negative impact differently; the unit count is identical, the dollar figure moves. | | **Threshold buffer** | Card may show fewer rows | Some workspaces allow a small negative buffer for known backorder workflows; rows within the buffer are suppressed. | | **Entity scope** | Either | Card respects the dashboard entity filter; a consolidated report includes entities the dashboard may exclude. | **Cross-connector reconciliation:** | Card | Expected relationship | What the comparison reveals | | ------------------------------------------------------------------------------------------------------------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | [shopify.inventory\_value](/nerve-centre/shopify/inventory_value) | Diagnostic | If Shopify shows stock available while Intacct is negative, the storefront is still selling stock that does not exist. That gap is the live oversell. | | [bigcommerce.inventory\_value](/nerve-centre/bigcommerce/inventory_value) | Diagnostic | Same dynamic for the wholesale catalogue. A negative Intacct Location with positive BigCommerce availability is a B2B oversell waiting to happen. | | [SKUs with Intacct vs Ecom Inventory Drift > 5](/nerve-centre/kpi-cards/sage/skus-with-intacct-vs-ecom-inventory-drift-5) | Causal | The per-SKU drift view that confirms whether a sync race, not a warehouse error, drove the negative. | | [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) | Causal | Persistent drift is the structural condition under which negatives recur. | | [OOS with Open Order Demand](/nerve-centre/kpi-cards/sage/oos-with-open-order-demand) | Downstream | The customer-facing consequence: orders committed against the stock that went negative. | The cross-channel point is that negative on-hand is the place where the commerce platform and the ledger most violently disagree about reality. Shopify and BigCommerce only know what they were told the stock was; Intacct knows what was actually issued and received. When the two desynchronise under load, the commerce platform keeps selling and Intacct records the truth as a negative. Only the ledger can tell you the oversell happened, because the storefront, by definition, thought the stock was there. This card plus the per-SKU drift join is how an operations team catches a flash-sale oversell while there is still time to expedite a receipt or pause a listing, rather than discovering it at the pick face two days later. ## Known limitations / merchant FAQs **Why does negative on-hand even happen if it is physically impossible?** Because the ledger records events, not physical reality, and events can post out of order. The three usual culprits are: an issue (sale, transfer, kit consumption, adjustment) posting before its matching receipt; the commerce platform decrementing availability faster than Intacct records the inbound during a traffic spike; and Intacct being configured to allow negative inventory, which lets the issue post rather than blocking it. The negative is the data system honestly recording that more went out than it has yet seen come in. **Should I configure Intacct to block negative inventory?** It depends on your fulfilment model. Blocking it forces every issue to have a preceding receipt, which keeps valuation clean but will hard-stop a shipment if the receiving clerk is behind, moving the friction to the warehouse and to [Transactions Failing Validation (imbalance / missing VAT)](/nerve-centre/kpi-cards/sage/transactions-failing-validation-imbalance-missing-vat). Allowing it keeps fulfilment flowing but lets negatives accumulate and distort cost. Many DTC brands allow it and rely on this card to catch and clear negatives quickly; many B2B distributors block it for valuation integrity. There is no universally correct answer, only a trade-off between fulfilment flow and valuation purity. **Does this card work for Sage Accounting / 50 / 200 merchants?** No, and it hides itself rather than showing an empty state. The card requires Sage Intacct's Inventory Control module with perpetual inventory, which is what gives an item a live `QuantityOnHand`. Merchants on Sage Accounting, 50, or 200 without perpetual inventory have no on-hand quantity to go negative, so the card is not applicable and does not render. This is intentional so the dashboard does not show a confusing empty card. **How does negative on-hand corrupt my margin?** Under average costing, issuing units you do not hold forces Intacct to cost those units anyway, which pulls the running average unit cost away from reality. That distorted average then values COGS on the next sale of the same item, so the margin on subsequent transactions is wrong until the negative is cleared and the average resettles. Under standard costing the item is valued at its standard regardless, so the margin distortion is smaller, but the valuation total is still off by the negative. **A SKU is negative at one warehouse but we have plenty in total, is that a real problem?** Yes, even though the net is fine. The per-Location split feeds the commerce availability sync and the per-Location valuation, so a negative Location can suppress storefront availability that should be live, or distort which warehouse appears to hold stock. The fix is usually an inventory transfer or correcting the Location on the offending transaction. Per-Location accuracy matters more than the net once you sell across multiple fulfilment points. **Will the row clear itself?** Often, yes. A negative caused purely by issue-before-receipt sequencing clears the moment the missing receipt is posted with the correct date. A negative caused by a genuine oversell does not clear until the inbound stock physically arrives and is received. The card shows the live state, so it removes the row as soon as on-hand returns to zero or above. **How fresh is this card?** Typically 5 to 15 minutes from the most recent Intacct inventory movement. During very high traffic the practical latency is whatever your commerce-to-Intacct sync cadence is, because that determines when the receipt and issue records actually land. This is precisely why a sync race shows up here: the card is reading a real, if transient, state of the ledger. **Does the alert threshold have to be exactly zero?** No. The default is any quantity below zero, but some teams that run deliberate backorder workflows allow a small negative buffer per Location so that expected, managed backorders do not generate noise. Rows within the configured buffer are suppressed. Set this carefully: too large a buffer hides genuine oversells. **How do I tell a sync race apart from a warehouse sequencing problem?** Cross-reference [Inventory Sync Drift](/nerve-centre/kpi-cards/sage/inventory-sync-drift) and [SKUs with Intacct vs Ecom Inventory Drift > 5](/nerve-centre/kpi-cards/sage/skus-with-intacct-vs-ecom-inventory-drift-5). If the same SKUs show persistent drift between the commerce platform and Intacct, the cause is the integration racing under load and the fix is on the sync side. If drift is clean but on-hand still goes negative, the cause is internal sequencing (issues posting before receipts) and the fix is warehouse process discipline. **Does this affect a Multi-Entity Console group differently?** The logic is identical per entity. The operational advice is to leave the card on all entities during peak trading, because a negative at a remote subsidiary's warehouse will not show if the dashboard is filtered to head office. Each row carries its Location and entity so the alert routes to the team that owns that warehouse. **Is engineering really a relevant role for an inventory card?** Yes, because the most persistent cause of negative on-hand at scale is the integration layer racing the ledger, which is an engineering problem, not a warehouse one. Operations clears the individual rows; engineering fixes the sync behaviour that keeps producing them. The card carries owner, operations, and engineering roles precisely because the fix can live in any of those three places depending on the root cause. *** ### Tracked live in Vortex IQ Nerve Centre *Inventory Item On-Hand Went Negative* 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.