DISC-101 · Discovery

Why Inventory Numbers Disagree Across Sales, Warehouse and Finance

When sales sees stock available, the warehouse sees less, and finance reports a third number, the organisation does not have one inventory problem. It has several systems applying different rules to the same physical reality.

Mellorca Discovery·Inventory & Order Operations·2 September 2026

The problem in plain language

A customer is told an item is available. The warehouse cannot find enough stock. Finance still carries inventory at a value that reflects a different quantity. Operations exports three reports and starts reconciling.

The instinct is to ask which number is correct. That is necessary, but it is not the whole problem. Different systems may be answering different questions: physical on-hand quantity, sellable quantity, available-to-promise quantity, reserved stock, stock in transit, damaged stock or accounting inventory. If those definitions and events are not aligned, “one number” is impossible.

What buyers search for

Problem-aware searches include “inventory numbers don't match”, “sync inventory between systems”, “ecommerce stock different from warehouse”, “real-time inventory visibility”, “ERP WMS inventory integration” and “inventory reconciliation automation”. The searcher is trying to make availability dependable enough for customers and operations to act on it.

Evidence: current inventory platforms expose synchronisation as an explicit architecture problem

Microsoft's current Dynamics 365 Supply Chain documentation describes synchronising external inventory adjustments through Inventory Visibility, configuring multiple data sources and dimensions, and setting inventory-summary synchronisation frequency. Those capabilities exist because inventory visibility is not simply a field in one table; it is the result of transactions from systems, locations and measures that must be mapped and synchronised.

The important lesson is architectural. A warehouse movement, ecommerce reservation, return, purchase receipt or manual adjustment has to be represented consistently across the systems that depend on it. Otherwise reconciliation becomes the integration layer.

Who owns the problem?

Operations or supply chain owns physical flow. Warehouse teams create many of the stock events. Sales and ecommerce depend on availability. Finance owns valuation and accounting. IT owns the interfaces. The COO and CFO often become budget owners because stock disagreement affects both customer promises and working capital.

Why it becomes urgent

Urgency rises when a business adds a warehouse or sales channel, expands SKU count, introduces bundles, increases transaction volume, changes ERP/WMS platforms or suffers visible overselling and stockout incidents. Manual reconciliation can hide the problem for a while; scale exposes it.

Economic consequence

  • Lost sales or customer trust: stock is promised but unavailable.
  • Excess inventory: planners buy more because availability data is not trusted.
  • Working-capital distortion: finance and operations make decisions from inconsistent quantities.
  • Warehouse labour: teams investigate discrepancies rather than moving goods.
  • Write-offs: damaged, returned or aged inventory is not represented correctly.
  • Fulfilment delay: orders wait while staff determine whether stock really exists.

The root cause is usually definition plus event flow

Typical causes include inconsistent product identifiers, locations mapped differently across systems, reservations not separated from physical stock, returns or damaged stock handled differently, delayed batch synchronisation, failed transactions, duplicate adjustments, bundles that do not decrement components correctly, and no agreement on which system owns which inventory event.

“Make all systems show the same number” can therefore be the wrong requirement. The stronger requirement is that every system uses the same definitions and receives the events needed to calculate the quantity relevant to its purpose.

A practical intervention

  1. Define the inventory measures that matter: on-hand, reserved, available, in-transit, damaged, sellable and accounting quantity.
  2. Identify the authoritative owner for each stock event.
  3. Standardise product, location, lot/serial and unit-of-measure identifiers.
  4. Map every event that changes inventory: receipt, pick, ship, return, transfer, adjustment, reservation, cancellation and write-off.
  5. Choose the required synchronisation method and latency for each channel.
  6. Create monitoring for rejected, delayed and duplicated inventory transactions.
  7. Separate operational exception handling from month-end accounting reconciliation.
  8. Measure variance by cause, not only total value.

Diagnostic questions

  • Can the business explain the difference between on-hand and sellable stock?
  • Which system creates a reservation, and which systems receive it?
  • How quickly do warehouse adjustments reach customer-facing channels?
  • Are product and location identifiers consistent?
  • Can operations identify the transaction that created a variance?
  • Does a cancellation release reserved stock automatically?

What good looks like

Good inventory architecture makes definitions explicit and event flow observable. Sales sees a quantity suitable for promising. Warehouse sees physical work and stock state. Finance receives controlled inventory movements for valuation. When a transaction fails, it appears in an exception queue rather than silently becoming tomorrow's spreadsheet reconciliation.

Where Mellorca fits

Mellorca can map the inventory data and transaction architecture, define ownership and measures, design integration across ERP, WMS and sales channels, and implement monitoring and exception workflows. The commercial goal is dependable operational truth at the point where a customer or employee must act.

Commercial path

Discovery article → inventory-visibility diagnostic → transaction and system map → architecture/integration roadmap → implementation → variance and synchronisation monitoring.

Sources and further reading

Method noteThis article diagnoses a class of operating problem. The cited platform documentation demonstrates current workflow and integration mechanisms; it does not prove that every organisation has the same failure mode. Quantify impact from your own process, transaction, labour and exception data.