Why do your ecommerce store and ERP show different stock levels?

Sources checked on 9 November 2026.

This guide is for the person responsible for ecommerce or operations at a distributor or manufacturer who sees the store showing different availability from the ERP. The goal is to find the cause for a specific item, not to choose a new system.

A mismatch may come from, among other things, one of four causes: the systems count a different quantity, data lands in the wrong warehouse, variant or unit, an update arrives late or not at all, or an exception (cancellation, return, manual correction) does not change the reservation the way the team assumes. Each of these can be checked on one SKU before any larger project starts.

Two people can see different numbers with no data error at all if one looks at physical stock and the other at stock available for new sales. Before you look for an integration fault, write down which quantity each screen shows.

For example, Shopify distinguishes on hand, available, committed, unavailable and incoming quantities, with on hand being the total of committed, unavailable and available. See Shopify inventory states. This illustrates one platform; it is not a definition every ERP uses.

Also agree the warehouse or location, the unit of measure (each, pack, pallet) and the product variant. The same number in a different unit or for a different variant looks like a mismatch even when the data is correct.

Pick one item where the mismatch is visible now and one recent order containing it. A small, concrete case shows the cause faster than a review of the whole catalogue.

1. Record both numbers with the time of reading: the store value, the ERP value and the exact time of each reading.
2. Name the quantity: next to each number, note whether it is physical, available or committed stock.
3. Check where the store value comes from: which system and which location the store reads for this SKU.
4. Find the last successful update: when the store last received a new value and whether that exchange succeeded.
5. Trace one order: when it was recorded, when and in which system the reservation was created, and when the store received the changed availability.
6. Check exceptions for this SKU: cancellations, returns, manual corrections and integration errors from the last few days.
7. Write down the hypothesis and the evidence: which cause you suspect, what supports it and what is still unknown.

This is a hypothetical example, not a client project. One item is left in the warehouse. The first customer orders it, while a second customer still sees the product as available and also places an order.

The time gap in the table is a clue to investigate, not proof of the cause. It may reflect an exchange schedule, a message queue, a failed attempt or a rule that creates the reservation only after payment. The right conclusion depends on the actual systems and the agreed process.

Use this list to form hypotheses. Not every item applies to every store and ERP connection, and several causes can occur at once.

• Different definitions: the store shows available stock while the ERP shows physical stock, or one side deducts a safety buffer and the other does not.
• Mapping: the SKU, variant, warehouse or unit points to a different record than the team assumes.
• Timing and order: updates arrive in periodic batches or in a different order from the events.
• Unhandled errors: an exchange failed, nobody was told, and the store keeps showing the last known value.
• Reservations: a cancellation, return or unpaid order does not release or create a reservation the way the process assumes.
• Manual corrections: a stock count or fix in one system never reaches the other.
• Several channels: a marketplace, wholesale and the store draw on the same stock without a shared rule.

A mismatch may only surface in an exception rather than in a normal order. What happens after a cancellation, return, integration error or manual correction? Who is told that data did not arrive, and how do they reconcile it safely?

Write this down before changing anything in the systems. The details depend on the actual tools and the agreed process, so the list below contains questions rather than ready answers.

• Which system is the source of truth for this SKU's stock, and for which location.
• Who owns the reservation rule and changes to it.
• How the team checks the time and result of the last successful update.
• Who is told about a failed exchange and how quickly they respond.
• How stock is safely reconciled after a failure without deducting items twice.

The scope of the change should follow from the diagnosis. An existing SaaS platform does not need replacing just because a mismatch occurred, and broader modernisation makes sense only when smaller changes do not remove the cause.

These materials shorten the conversation and let the scope be assessed without guessing. You do not need all of them; a missing answer is also a useful result.

If you are also considering a new ordering channel for business customers, see the guide B2B ordering portal or mobile app.

1. Names and versions of the store and ERP, plus any middleware in between.
2. One SKU with a mismatch, both numbers and their reading times.
3. The path of one order with the times it was recorded, reserved and updated in the store.
4. A description of today's reservation, cancellation and return rules.
5. Who finds out about a failed data exchange, and how.