One SKU shows 14 units in the store admin, 9 in the ERP and 11 on the warehouse shelf. The instinct is to ask which system is wrong, yet often none of them is: each answers a different question at a different moment. Most inventory mismatches between an ecommerce store and an ERP trace back to four things: different definitions of “available”, updates that arrive late or never, two systems allowed to change the same number, and products, units or locations mapped inconsistently. Identifying which applies before changing the ERP integration matters, because each cause needs a different fix, and the wrong one can leave overselling and manual corrections in place.
The useful question is therefore not which number is right, but what each number includes and when it last changed. A store’s figure usually reflects what can be sold now; an ERP’s may be physical stock, stock minus allocated orders, or a projection. Part of the gap often turns out to be definition rather than fault, and the rest follows a pattern that can convert a vague complaint into a scoped piece of ecommerce ERP integration work with a clear owner.
Symptom or Cause: Reading the Pattern Before Changing the ERP Integration
A mismatch is a symptom, and the shape of the gap usually points to the cause more reliably than its size. Four questions do most of the work:
- Direction. Is the store higher or lower than the ERP? A store showing more stock tends to point to orders or reservations it has not yet subtracted, or to an ERP deduction that never arrived. A store showing less often points to allocations counted twice or a buffer applied in both systems.
- Persistence. Does the gap close on its own? A difference that disappears by the next sync cycle is usually timing. One that survives several cycles is more likely a rule, mapping or failure problem.
- Scope. Does it affect every SKU, one location, one product type such as bundles, or a scattered handful of items? Broad gaps suggest a calculation or location setting; narrow ones suggest mapping or manual edits.
- Timing. Did it begin after a sale, a nightly job, a returns batch, a new warehouse or a platform upgrade? Mismatches that start on a particular date usually have a change behind them.
Answering these for a sample of SKUs is modest work, and it guards against a costly response to inventory mismatches: replacing an ERP integration that was doing what it had been configured to do.
Eight Causes of Inventory Mismatches Between a Store and an ERP
Two or three of these can overlap on the same SKU, which is one reason a single fix sometimes works briefly and then stops.
1. The two systems define “available” differently
Ecommerce platforms and ERPs rarely publish the same quantity, even when both behave correctly. Adobe Commerce, for example, displays a salable quantity that is calculated rather than counted: its documentation describes aggregating the quantities of every source assigned to a stock, then subtracting reservations and the configured Notify for Quantity Below threshold. The number a merchant sees is therefore lower than what is physically held, by design.
ERPs make their own choices. Microsoft Dynamics 365 Business Central offers two standard stock calculations for its Shopify Connector, and Microsoft’s example shows how timing alone changes the result: with 10 units on hand and orders for one unit shipping Monday and two shipping Thursday, a projected-balance sync sends 9 on Tuesday and 7 on Friday. Neither figure is wrong, yet a team comparing the store with an on-hand ERP screen will see a gap every day. The fix is agreement rather than code: decide which figure the store displays, and make reconciliation reports compare like with like.
2. Reservations and held stock that only one system can see
Between checkout and shipment, stock passes through states that may exist in only one system. WooCommerce can hold stock for unpaid orders for a configurable number of minutes; according to its settings documentation, once that limit is reached the pending order is cancelled and the held stock is released back to available inventory. If the ERP imports pending orders immediately, or does not see them at all, the two figures diverge for that window. Adobe Commerce reservations behave in a comparable way, turning into actual quantity deductions only when products are invoiced and shipped.
Reservations can also fall out of balance. Adobe’s Inventory Management CLI reference lists causes such as upgrading while orders are not in a final state, and provides commands to list inconsistencies and create compensating reservations. On any platform, a store figure that stays low for SKUs with old, unfinished orders is worth checking for this residue before the connector takes the blame.
3. Sync windows and batch schedules
Integrations typically have some delay between a stock movement and its arrival elsewhere. Microsoft suggests running Business Central’s inventory sync through the job queue every 15 to 30 minutes, which suits many catalogues but lets a fast-selling SKU sell several units between updates. Batch designs add more delay when a warehouse file is processed only overnight.
Timing gaps open around sales peaks and stock receipts and close by themselves, so they rarely justify a rebuild. Shorter intervals, event-driven updates for stock movements or a modest buffer on low-stock SKUs are usually proportionate.
4. Updates that fail, or are never sent
A sync that reports success has not necessarily sent anything. Microsoft’s troubleshooting guidance for the Business Central connector explains that a product can be skipped before any request reaches Shopify if the item type, location set-up or variant mapping is wrong. Custom integrations have equivalents: a batch that stops partway through a file, or a REST or GraphQL API error absorbed by a retry loop. The result is persistent, scattered inventory mismatches with no link to product type, and the evidence sits in the logs, which is why an ERP integration without searchable logs is difficult to diagnose.
5. More than one system changing the same number
When a merchandiser adjusts stock in the store admin, a marketplace app deducts units, and the ERP then pushes its own figure, the last writer wins and the other changes disappear. Shopify’s inventory adjustment history exposes this by recording, for the last 180 days, each change and the staff member, app or sales channel behind it. Manual adjustments followed by ERP overwrites suggest ownership of the number has not been settled.
The same problem can sit outside both systems, when a spreadsheet used to allocate stock becomes a third record whose corrections do not reach the inventory sync.
6. Product, unit and bundle mapping
An ERP item and a store variant are not always the same thing. Duplicate or recycled SKUs, variants created in the store without an ERP match, and products sold in more than one pack size can break the one-to-one link that an inventory sync relies on. Bundles are a frequent example: Microsoft notes that the Shopify Bundles app calculates availability from components and blocks API updates, so it recommends mapping bundles to non-inventory items in Business Central.
Mapping problems produce narrow, stubborn gaps on the same product types day after day. Master-data clean-up and a clear mapping rule often resolve them, although complex kits may need custom logic.
7. Locations that do not line up
An ERP may hold stock across several warehouses, bins or quarantine areas, while the store sells from one or two locations. Microsoft points out that adding a location in Shopify does not create inventory records for existing products, so Business Central syncs no stock for them there until those records exist. Any stack shows similar gaps when a new 3PL or returns warehouse is added without updating the mapping. They usually start on a specific date and affect many SKUs at once, which makes them easier to spot once someone asks what changed.
8. Returns, cancellations and inaccurate physical records
Returns generate two events that are easy to merge: the refund and the physical receipt. If the store restocks at refund but the ERP only after inspection, the store shows stock still in transit or later written off as damaged.
Some mismatches begin before any system is involved. In a study of nearly 370,000 inventory records from 37 stores of one retailer, published in Management Science in 2008, Nicole DeHoratius and Ananth Raman found 65% of the records to be inaccurate. That research concerned physical store records rather than online integrations, but the principle holds: an integration copies what the ERP believes, including receiving errors and unrecorded damage.
Matching the Mismatch Pattern to Its Likely Cause
The four questions and eight causes combine into a quick reference, a starting point for investigation rather than a verdict.
| Pattern observed | Likely cause | Where to check first | Typical fix |
|---|---|---|---|
| A steady gap across most SKUs, every day | Different definitions of available stock | Connector stock calculation; the ERP screen used for comparison | Agree one definition and compare like with like |
| Store higher than the ERP shortly after orders | Reservations or orders not yet imported | Pending and unpaid orders; order import queue | Align the point at which each system deducts stock |
| Gap opens at peaks or receipts, then closes | Sync window or batch schedule | Job schedule and time of the last successful run | Shorter intervals, events for stock movements, selective buffers |
| Scattered SKUs, persistent, no pattern | Failed or skipped updates | Integration logs and error queues | Repair error handling and add reconciliation |
| Corrections reverted within hours | Two systems writing one number | Store adjustment history; app and staff permissions | Name one owner and remove edit rights elsewhere |
| The same product types wrong every day | SKU, pack-size or bundle mapping | Variant-to-item mapping; bundle configuration | Clean master data; mapping rules or custom logic |
| Many SKUs wrong from a specific date | Location mapping | New warehouses, 3PLs or store locations | Update location filters and inventory records |
| Store higher after refunds | Returns posted at different stages | Refund events versus goods-received events | Restock only on receipt or inspection |
Causes often overlap: a timing gap can conceal a mapping error until a quiet weekend shows the difference never closes. The pattern should therefore be tested against evidence rather than accepted on sight.
How to Trace an Inventory Mismatch to Its Cause
A structured trace usually costs less than speculative connector changes, and it leaves a record operations, finance and ecommerce can all review.
- Select a sample and fix the moment. Pick ten to twenty affected SKUs plus a few unaffected ones, and record both figures with the exact time of each reading. Without timestamps, timing gaps and genuine errors look identical.
- Write down what each figure includes. Note whether each number is on hand, available, salable or projected, and which locations feed it. Part of the gap often disappears at this step.
- Read the change history for each SKU. Store adjustment history, ERP item ledger entries and warehouse movements show who changed the number and when, including overwrites.
- Check the integration logs for the same window. Confirm whether an update was calculated, sent, accepted or rejected. A gap with no matching message points to a skip or a mapping issue; a rejected message points to validation or permissions.
- Fix the rule before the data. Match the evidence to a cause and change the definition, mapping, ownership rule or schedule that produced it. Only then correct the quantities, because correcting first erases the evidence and lets the gap return.
- Reconcile and monitor. Schedule a comparison of store and ERP figures per SKU and location, set an agreed tolerance, and name the person who responds when it is exceeded.
When the trace points to several causes at once, or the logs are too thin to show what happened, a broader technical audit of the store and its integrations may be a more efficient starting point than fixing SKUs one at a time.
Choosing the Fix: Configuration, Process or a New Integration
Once the cause is known, the response is often smaller than expected. Definition, location and schedule problems can usually be solved in the existing connector’s settings, while ownership problems are mostly organisational: someone gives up the right to edit a number. Retailers with a widely supported ERP and a simple catalogue often resolve inventory mismatches this way, and a packaged connector remains the sensible choice.
A new or custom integration becomes worth considering when the cause is structural. That includes a connector that cannot express the business’s availability rules, map kits or route several warehouses, or keeps no logs. There, configuration changes treat symptoms and the gaps return after each catalogue or warehouse change. The trade-off is cost and ownership: a custom ERP integration follows the business’s actual rules but needs maintaining, while a packaged connector is cheaper for as long as the business fits its data model.
Removing unofficial records can matter as much as the connector itself. In WD Market’s A.M. Ozoli sales operations and data centralisation project, the case study records that the business “moved from 15+ disconnected Excel files to one real-time centralized database”. That project centred on B2B pricing rather than store stock, but the lesson transfers: while a second record exists, people keep editing it.
Internal expert input required: insert one WD Market diagnosis of a store-to-ERP stock discrepancy (symptom, cause identified, fix applied), approved by the client for publication.
Key takeaway: an inventory mismatch is evidence, not a verdict. Establish what each number means and when it last changed before deciding whether the integration, the data or the process is at fault.
Mistakes That Keep Mismatches Coming Back
- Correcting quantities before finding the cause. A bulk stock correction makes the dashboard look healthy for a day but removes the evidence that would explain the gap, so the same pattern tends to reappear within weeks.
- Hiding gaps behind safety stock everywhere. A buffer can absorb short delays on low-stock lines, but applied across the catalogue it withholds sellable stock and masks mapping or failure problems that still need fixing.
- Treating the integration as finished. New warehouses, sales channels, bundles and platform upgrades each change the assumptions an inventory sync was built on, so a short review after each change costs far less than a clean-up months later.
What to Check Before Blaming the Integration
Store and ERP figures disagree for a limited set of recurring reasons, from differing definitions of available stock and invisible reservations to sync delays, failed updates, competing writers, mapping gaps, location changes and returns. Each leaves a pattern in direction, persistence, scope and timing. Reading it on a timestamped sample, and fixing the rule before the data, separates configuration problems from the structural limits that justify new ERP integration work. A sensible next step is to take a handful of mismatched SKUs and establish what both numbers include and when they last changed.
From Recurring Stock Corrections to Numbers the Team Can Trust
If stock corrections are part of the weekly routine and the cause is unclear, an assessment can show whether the set-up needs reconfiguring, monitoring or replacing. To see what such an assessment covers, including data flow mapping, sync rules, and automatic retries with logging, explore WD Market’s ecommerce ERP integration services. A useful assessment will also say when the existing connector only needs better configuration.
To talk through a specific case, schedule a discovery call with WD Market and bring the platform, ERP, warehouses and a few example SKUs. Shorter notes on integrations and ecommerce operations are shared on the WD Market LinkedIn page.
Inventory Mismatches: Questions Operations Teams Ask
How large a difference between store and ERP stock is acceptable?
There is no universal tolerance; it depends on sales velocity, sync frequency and what an oversold order costs the business. A difference that closes within one sync cycle is normally acceptable timing. One that persists across several cycles, or grows, deserves investigation even when small, because it suggests a rule or mapping fault rather than delay. Many teams set a tolerance per SKU and location and review exceptions daily.
When the store and the ERP disagree, which figure should we trust?
Neither automatically. First confirm that both figures measure the same thing, for example available stock for the same set of locations, since a store’s sellable quantity and an ERP’s on-hand balance are expected to differ. If they still disagree, the system designated as the owner of physical stock, typically the ERP or warehouse system, is the usual reference point. Its records can be wrong too, so a physical count settles what records cannot.
Will a safety stock buffer stop overselling caused by mismatches?
It can reduce overselling when the cause is a short delay between systems, because the store stops selling before the final units are gone. It does not remove the underlying difference. Where gaps come from mapping errors, failed updates or competing edits, a buffer conceals them while keeping available products off sale, which may cost revenue on popular lines. It works best as a temporary measure on specific SKUs.
When is it worth replacing our integration instead of fixing it?
Replacement is justified when the investigation shows structural limits, such as a connector unable to reflect the company’s availability rules, map multipacks or route several warehouses to the right storefront, or one that offers no record of what it sent. When the causes are definitions, schedules, permissions or master data, repairing the existing set-up tends to be cheaper and quicker. Specialists in ecommerce ERP integration can review the evidence and recommend a route before any budget is committed.