Why Amazon, Shopify & ERPs
Show Different Inventory Counts
— And How to Fix It

You sell the same product on Amazon, Shopify, and Mercado Libre. Your ERP — whether it's NetSuite or Odoo — is supposed to be the source of truth. But log into each system and you'll see five different numbers for the same SKU. One says 138, another says 155, your ERP says 161. Which one do you trust? And more importantly — which one is Amazon about to delist you for?

This is one of the most common operational problems we solve at Molten Logistics. It's not a bug. It's not a coincidence. It's the predictable result of how each platform counts inventory — and the mismatched sync patterns between them. This guide explains exactly why it happens, platform by platform, and gives you a concrete fix strategy.

Why the numbers never match

Each platform has its own definition of "inventory on hand" — and they're genuinely different, not just synced poorly. Before fixing the problem, you need to understand what each number actually means.

All three numbers can be simultaneously correct — within each platform's own definition. The problem is that your team, your 3PL, and your customers are all seeing different numbers and acting on them differently.

Platform-by-platform breakdown

Amazon — the most complex inventory model

Amazon's inventory API returns multiple quantity types that must be understood before you can build a sync:

Shopify — deceptively simple, with a catch

Shopify's inventory model is cleaner but has its own trap. Each SKU has an inventory_quantity (what's shown) and a incoming count (on the way). The inventory_quantity Shopify shows in-store is already net of committed units for open orders — but only if you have "continue selling when out of stock" disabled.

If that setting is enabled, Shopify will happily sell into negative inventory and never fire a webhook to warn you. You find out when you can't fulfill.

NetSuite — accurate but slow and location-aware

NetSuite is usually the most accurate ledger of inventory — when it's kept up to date. The key integration traps:

• Location-level sync: Never push the company-total quantity to a single-location channel. Query by location (inventoryLocation) and push only the correct location's quantityAvailable.
• Committed quantity: NetSuite's quantityOnHand includes committed stock. Use quantityAvailable (on hand minus committed) for channel updates.
• Saved search latency: NetSuite's SuiteScript or REST API reads can have 5–15 minute lag on saved searches during peak hours. Build your sync to handle this gracefully.

Odoo — flexible but requires location discipline

Odoo's inventory tracks qty_on_hand, virtual_available (on hand + incoming − outgoing), and qty_available (immediately available). For channel sync, use qty_available filtered by the specific warehouse location you're selling from.

def get_odoo_available_qty(sku: str, warehouse_id: int) -> float:
    models, uid = odoo_connect()

    # Get the product first
    products = models.execute_kw(ODOO_DB, uid, ODOO_KEY,
        "product.product", "search_read",
        [[("default_code", "=", sku)]],
        {"fields": ["id", "name"], "limit": 1}
    )
    if not products:
        raise ValueError(f"SKU not found in Odoo: {sku}")

    product_id = products[0]["id"]

    # Read qty_available at the specific warehouse location
    # Use with_context to scope to the warehouse location
    quant = models.execute_kw(ODOO_DB, uid, ODOO_KEY,
        "stock.quant", "search_read",
        [[
            ("product_id", "=", product_id),
            ("location_id.usage", "=", "internal"),
            ("location_id.warehouse_id", "=", warehouse_id),
        ]],
        {"fields": ["quantity", "reserved_quantity", "location_id"]}
    )

    total_on_hand  = sum(q["quantity"] for q in quant)
    total_reserved = sum(q["reserved_quantity"] for q in quant)
    return max(0, total_on_hand - total_reserved)   # never push negative

How to fix it — the sync strategy

The solution is a single source of truth with a unidirectional sync pattern. Your ERP (NetSuite or Odoo) is the master. Channels (Amazon, Shopify, Mercado Libre) are subscribers. Nothing updates the ERP except warehouse operations. Everything else reads from it.

import threading
from dataclasses import dataclass

# In-memory committed counter — backed by Redis in production
committed_qty: dict[str, int] = {}
committed_lock = threading.Lock()

def on_order_placed(sku: str, qty_sold: int, source_channel: str):
    """
    Called immediately when any channel fires an order webhook.
    Decrements local committed counter and pushes to all other channels.
    """
    with committed_lock:
        committed_qty[sku] = committed_qty.get(sku, 0) + qty_sold

    # Get current ERP available qty
    erp_available = get_odoo_available_qty(sku, warehouse_id=1)

    # Subtract committed (sales not yet reflected in ERP)
    effective_qty = max(0, erp_available - committed_qty.get(sku, 0))

    # Apply safety buffer
    SAFETY_BUFFER = get_safety_buffer(sku)
    push_qty = max(0, effective_qty - SAFETY_BUFFER)

    # Push to all channels except the one that just sold
    channels = {"amazon", "shopify", "mercadolibre"} - {source_channel}
    for channel in channels:
        update_channel_inventory(channel=channel, sku=sku, qty=push_qty)

def update_channel_inventory(channel: str, sku: str, qty: int):
    if channel == "shopify":
        shopify_set_inventory(sku=sku, qty=qty)
    elif channel == "amazon":
        # Amazon FBA quantity is managed by Amazon — only update FBM
        if is_fbm_sku(sku):
            amazon_update_fbm_qty(sku=sku, qty=qty)
    elif channel == "mercadolibre":
        meli_update_stock(sku=sku, qty=qty)

def daily_reconciliation_report() -> list[dict]:
    """
    Compares ERP qty against each channel for every active SKU.
    Flags SKUs where any channel diverges by more than tolerance %.
    """
    TOLERANCE_PCT = 0.05   # 5% variance is acceptable drift
    discrepancies = []

    active_skus = get_all_active_skus()   # from your ERP

    for sku in active_skus:
        erp_qty      = get_odoo_available_qty(sku, warehouse_id=1)
        shopify_qty  = shopify_get_inventory(sku)
        amazon_qty   = amazon_get_fulfillable(sku)   # FBM only
        meli_qty     = meli_get_stock(sku)

        checks = {
            "shopify":      shopify_qty,
            "amazon_fbm":   amazon_qty,
            "mercadolibre": meli_qty,
        }

        for channel, channel_qty in checks.items():
            if erp_qty == 0:
                continue
            variance = abs(erp_qty - channel_qty) / erp_qty
            if variance > TOLERANCE_PCT:
                discrepancies.append({
                    "sku":          sku,
                    "channel":      channel,
                    "erp_qty":      erp_qty,
                    "channel_qty":  channel_qty,
                    "variance_pct": round(variance * 100, 1),
                    "delta":        channel_qty - erp_qty,
                })

    # Sort by severity (largest absolute delta first)
    return sorted(discrepancies, key=lambda x: abs(x["delta"]), reverse=True)

Sync patterns that create more problems

Inventory sync health checklist

Run through this list for every SKU that sells on more than one channel. If you can't check every box, you have an active oversell risk.

Inventory drift is fixable

Every discrepancy in this post has a technical solution. The reason most operations don't fix it isn't that the engineering is too hard — it's that there's always a fire burning somewhere else. The inventory count problem stays in the background, quietly causing oversells, Amazon suspensions, and customer refunds, until it becomes the fire.

A properly implemented unidirectional sync with event-driven updates, per-channel safety buffers, and a daily reconciliation report will eliminate 95% of the discrepancy problems described in this guide. The remaining 5% — FBA return reconciliation, bundle kitting edge cases, and rate limit resilience — are operational refinements you add as you stabilize the core.