Your ERP says 412 units. Your online store says 398. The warehouse counted 405 this morning. Nobody made a mistake.
Inventory data is different across your systems when two of them show different stock numbers for the same product. It usually happens because they were updated at different times, they are counting different things, or one of them never got the update. It is almost never a counting problem. If you run an ERP such as SAP Business One, Oracle NetSuite or Microsoft Dynamics 365 Business Central alongside an online store, a marketplace, or a warehouse system, the gap is usually built into the way those systems talk to each other.
The Short Version
This is a systems problem, not a warehouse problem. Counting more often fixes the number, but not the cause.
Timing is the most common cause. If the gap disappears overnight and comes back during the day, that is your answer.
The most misunderstood cause is the word available. Different systems use it to mean different things.
The most damaging cause is a failed update that nobody sees. Count orders against orders, not units against units, and you will find it.
To fix it for good, decide which system owns each number, set a limit for how far apart they can drift, and get alerted when they do.
Five causes explain most of it:
- Your systems update at different times
- Your systems mean different things by the word available
- Product codes, units or warehouses do not match up
- Updates are failing without telling anyone
- Stock is moving without being recorded
Each one leaves a different clue. Below you will find the clue, a check you can run today, and the fix.
Start Here: Find Your Symptom
Before you change any settings, match what you are seeing to the most likely cause.
Find Your Symptom
| What you are seeing | Most likely cause | Go to |
|---|---|---|
| The gap closes overnight, then comes back by lunchtime | Systems updating at different times | Cause 1 |
| The gap stays the same size, and it matches your unshipped orders | Different meanings of available | Cause 2 |
| Your store sells stock you do not have during a sale or promotion | Timing, or the wrong stock number being shared | Cause 1 and 2 |
| Only bundles, kits or product variants are wrong | Product code and unit problems | Cause 3 |
| One warehouse is always wrong, the rest are fine | Warehouse settings | Cause 3 |
| The gap keeps growing and never corrects itself | Updates failing silently | Cause 4 |
| The gap jumps after returns, damages or stock counts | Stock moving without being recorded | Cause 5 |
| Everything was fine until you added a new sales channel | Product codes, or no agreed owner of the number | Cause 3 and the last section |
Cause 1: Your Systems Update at Different Times
What it looks like
The gap shows up during the working day and shrinks overnight. On Monday morning everything matches. By the afternoon your Shopify store is 30 units behind SAP Business One.
Both systems are right. They are just right at different moments.
This is the most common cause of inventory sync issues. It is also the easiest to miss, because if you check the numbers in a quiet period, everything looks fine.
The check
Pick one product that sells fast. Write down its stock number in every system, all within the same minute. Then do it again after a quiet night with no sales.
If the overnight gap is close to zero but the daytime gap is large, your problem is timing.
Next, look at two settings. First, how often each system is set to send stock updates. Second, whether updates are piling up in a queue. If updates arrive faster than they can be processed, the gap grows as sales grow. That is why the problem always looks worst during a sale.
For the IT Owner
Check queue depth and message age during peak trading hours, not after. A queue that drains overnight will look healthy on a morning report while having been hours behind all afternoon.
The fix
Send stock updates the moment something happens, instead of waiting for the next scheduled run. A sale, a delivery, a transfer or a stock adjustment should trigger an update straight away.
Some older systems can only send updates on a schedule. If that is your situation, tell your sales and support teams how often stock actually refreshes. A team that knows the number updates every 15 minutes will behave differently from a team that thinks it is live.
You can also hold back a small buffer of stock on your store so you do not oversell. That hides the problem during a busy week. See appse ai’s ready-made ERP and eCommerce workflows for instant-trigger stock sync instead — it is not a fix, and you lose a sale on every unit you hold back.
Cause 2: Your Systems Mean Different Things by "Available"
What it looks like
This is the most misdiagnosed cause on the list, and the one teams spend the longest chasing.
The gap does not move around. It stays roughly the same size, and it matches the number of orders you have taken but not yet shipped. When unshipped orders go up, the gap gets bigger. When you ship them, it closes.
Nothing is broken here. The two systems are answering two different questions, and both are giving the right answer.
The check
For one product, write down exactly which stock number each system is showing. Then compare the ERP on-hand figure and the ERP available figure against what your store is showing.
If on-hand matches your store but available does not, or the other way around, this is your cause. Changing how often you sync will not help, because the two systems were never measuring the same thing.
These are the stock numbers people mix up most often. Each one is defined in your own system documentation, so check yours rather than assuming.
Common Stock Number Definitions
| Stock number | What it means | What it leaves out | Where it usually comes from |
|---|---|---|---|
| On hand | Everything physically sitting in the warehouse right now | Nothing is taken off for orders you have already received | SAP Business One, Oracle NetSuite, or your warehouse system |
| Available (also called available to promise) | On hand, minus stock set aside for orders you have taken | Stock reserved for orders, plus damaged or quarantined stock | Oracle NetSuite, Microsoft Dynamics 365 Business Central |
| Committed (also called allocated) | Stock set aside for orders that have not shipped yet | Free stock you can still sell | Your ERP |
| In transit | Stock a supplier has sent but you have not received yet | Anything already in your warehouse | Your ERP or supplier feed |
| Sellable | What your store will actually let a customer buy | Whatever that channel is set to exclude | Shopify, BigCommerce, or your channel tool |
For the exact definitions in your own stack, see Oracle’s NetSuite available-to-promise documentation, Microsoft’s Business Central item availability overview, and Shopify’s inventory states guide. (SAP Business One documents its Available-to-Promise report in the SAP Help Portal for your specific version — link to be confirmed before publishing.)
The fix
Decide which number each sales channel should use. A trade portal and a consumer store often need different numbers, and that is a business decision, not a technical one.
Write the decision down, then set it up on purpose. Most setups share whatever number the connector picked by default. Nobody chose it, so nobody thinks to question it when the numbers stop matching.
Cause 3: Product Codes, Units and Warehouses Do Not Match Up
What it looks like
Most of your catalogue is fine. A small group of products is always wrong.
It is usually bundles and kits, Shopify product variants, items you sell in one unit but store in another, or anything held in more than one location.
The check
Export the product list from every system and line them up side by side. Look for three things:
- Products that exist in one system but not another
- Products that appear twice, usually because an old code and a new code are both still in use
- Products where the unit does not match, for example a case of 12 in SAP Business One but single units on your Shopify store, with no conversion set between them
Then check which warehouses and locations each system counts as sellable. If a returns shelf or a quarantine area is included in one system and left out of another, you get a permanent gap that nobody can explain.
For the IT Owner
The duplicate-code check is worth automating as a scheduled report rather than running it once. Duplicates reappear every time someone creates a product outside the normal process.
The fix
Give every product one master code. Old codes should point to that master code instead of creating a second product.
Set up unit conversions properly in your integration. If the conversion only lives in someone’s head or in a spreadsheet, it will go wrong within a few months.
Decide how bundles work, once, and apply it everywhere. Either a bundle uses up its component stock, or it holds its own stock. Pick one and make every channel follow it.
Write down which locations count as sellable and keep that list updated. These settings change quietly, usually when someone adds a location for a one-off job and never removes it.
Cause 4: Updates Are Failing Without Telling Anyone
What it looks like
The gap keeps growing in one direction. It never corrects itself. No error appeared, no alert went off, and your integration dashboard says everything is fine.
This is the most damaging cause and the one people talk about least. Nothing looks wrong until the gap is big enough to hurt.
The check
Count orders, not units. Take the last 30 days. Count how many orders your store took. Then count how many matching order sync between systems records were created in your ERP.
If orders are missing, updates are being lost somewhere. That is a different problem from a wrong number, and it needs a different fix.
Next, look at the error log for your integration. Two things to look for. First, updates that were retried but never confirmed. If a retry is not handled safely, the same update can be applied twice, which takes stock off twice for one sale. Second, updates that failed, stopped retrying, and were quietly parked somewhere nobody looks.
For the IT Owner
Parked and dead-lettered messages are the usual home of an ERP inventory discrepancy that has been growing for months. Check the age of the oldest parked message, not just the count.
The fix
Make every stock update safe to repeat. If the same instruction runs twice, it should still only change stock once.
Set up alerts for failed and parked updates, not just for a system going offline. A connection can be online and still be dropping every third update.
Retry small, temporary failures automatically. Send the rest to a named person, with the details attached: which product, which order, what went wrong. An error nobody can act on is the same as an error nobody saw.
Cause 5: Stock Moves Without Being Recorded
What it looks like
The gap follows physical events rather than sales. It jumps after a wave of returns, a damaged pallet, a batch of samples, a stock count, or a busy week at your third-party warehouse.
The stock really did move. Only one system was told.
The check
Pull the stock movement history from your ERP for the last 30 days. Split every movement into two groups: created automatically by a system, and typed in by a person.
If a lot of movements were typed in by hand, that is your answer. Manual entry is not the problem on its own. Manual entry into only one system is.
Also check any stock adjustment reports from your third-party warehouse for movements that never made it into your ERP. Adjustments sent as a weekly email attachment reliably get missed, because nobody owns the job of typing them in and nobody notices when it does not happen.
The fix
Give every type of adjustment one owner and one way in. Damages, samples, write-offs and count corrections all need a clear route into your main system.
Put returns through the same automatic process as orders. Returns cause more unrecorded stock movement than anything else, and they are usually the least automated part of the business.
Treat your third-party warehouse feed like a system and watch it like one. If the feed stops arriving, you should hear about it that day, not at the next stock count.
Other Common Causes of Inventory Data Mismatch
If none of the five above fits, check these before going further.
- No agreed owner of the number. Two systems both think they own the stock figure, so they keep overwriting each other. The number changes depending on which one updated last.
- Updates bouncing back and forth. System A sends an update to System B, which sends it straight back as a new change. Stock moves up and down with no real sales behind it. This is one of the more confusing inventory sync issues to diagnose, because activity looks healthy.
- Different day cut-off times. Your ERP closes the day at a different hour from your store, so your end-of-day reports are comparing two different days.
- Marketplace quantities edited by hand. If someone changes a listing quantity directly in an Amazon or eBay seller account, no other system knows it happened.
- A new channel added without updating the process. The setup was built for the channels you had at the time. Nobody extended it when new ones were added.
- A software update that changed a setting. Connector updates sometimes change which stock number gets shared. The change is silent, and the gap starts on a date nobody links to an update.
What This Looks Like in Practice
A pattern worth recognising, because it shows up repeatedly in mid-market businesses running an ERP, a store and an outsourced warehouse. This is an illustrative example rather than a specific customer.
A company sells through Shopify, runs SAP Business One, and holds stock with a third-party warehouse. Stock numbers agree for eighteen months. Then they add a marketplace channel and stock counts start drifting by a few units a week.
The obvious suspect is the new channel. It is not the cause. The marketplace was added correctly, but nobody extended the daily stock check to cover it. Meanwhile, the third-party warehouse had started sending damage adjustments as a weekly email instead of through the feed, and those adjustments had stopped reaching the ERP two months earlier.
The new channel did not cause the problem. It removed the spare capacity that had been hiding it. That is the usual sequence. Something changes, and a gap that was always there becomes visible.
How to Stop It Happening Again
Every fix above works. The problem is that fixes wear off. You add channels, you add products, staff change, and the gap comes back in a slightly different form.
Each recurrence costs the same thing twice. Someone has to notice it, and someone has to spend a day or more tracing it back through order and movement history. For most teams that is a recurring cost, not a one-off.
Definition
What keeps it fixed is inventory reconciliation between systems as a standing check: decide which system owns each number, agree how far apart the numbers are allowed to drift, and get alerted when they drift further than that.
Decide who owns each number, not each system
The obvious answer is to make the ERP the master and move on. That does not work, because different numbers genuinely start in different places.
On-hand belongs to whichever system physically counts the stock, usually SAP Business One, Oracle NetSuite or your warehouse system. Committed stock often belongs to the channel that took the order. In-transit stock belongs to purchasing. See how ERP and eCommerce integration handles this ownership split for systems like yours.
Decide number by number, write it down, and share it with the people who use those numbers. Most long-running gaps survive because this decision was never actually made.
Agree how far apart the numbers can drift
Set a limit for each type of product. A fast-selling low-value item and an expensive tracked item do not need the same limit.
Check agreement daily against that limit. Get alerted when it is breached, instead of waiting for a customer complaint or a stock count.
This does not stop the gap appearing. It turns an invisible problem into one with a date, a size and an owner.
Automate what happens when something goes wrong
Most integrations only automate the part where everything works. When something fails, it lands with a person who may or may not be looking.
That is why the problem survives every fix. The automation handles the 97% that was never causing trouble, and the 3% that causes every gap sits in an inbox.
Automate the detection. Automate the corrections that are safe to make without judgement. Send the rest to a person with enough detail to sort it out in one go.
"We can do all of this ourselves"
You can. Every check in this article is something your team can run with the tools you already have.
The question is not whether you can do it once. It is what happens on the fourth repeat. Each new sales channel, each new warehouse, each new product range brings the risk back, and each time someone has to notice, investigate and fix it by hand.
The decision point is usually the same. It arrives when the time spent finding the gap costs more than the gap does.
Your Step-by-Step Checklist
Work through this in order. Each step either finds the cause or rules it out.
Diagnostic Checklist for Inventory Data Differences
Record the stock number — Record the stock number for one fast-selling product in every system, within the same minute
Compare the overnight gap — Do the same check again after a quiet night and compare the two gaps
Check update frequency and queueing — Note how often each system sends stock updates, and whether updates are queueing up
Identify which stock number each system shares — Write down which stock number each system is sharing: on hand, available, committed or sellable
Compare ERP fields against the store — Compare ERP on-hand and ERP available against what your store is showing
Cross-check product lists — Line up product lists from every system and look for missing, duplicated or mismatched-unit products
Check sellable location settings — Check which warehouses and locations each system treats as sellable
Count orders against orders — Count 30 days of store orders against 30 days of ERP orders
Read the integration error log — Read the integration error log for retried, failed and parked updates
Split stock movements by source — Split 30 days of stock movements into automatic and manually entered
Check third-party warehouse adjustments — Compare third-party warehouse adjustment reports against your ERP
Assign number ownership — Decide which system owns each stock number and share the decision
Set drift limits and alerts — Set a drift limit for each product type and turn on alerts
Route errors to a named owner — Make sure errors go to a named person with the full details attached
Want this as a one-page checklist you can take into a meeting? [Gated checklist download — destination pending; no landing page/asset exists yet for this lead-capture CTA.]
How appse ai Handles This
The result of getting this right is fewer stockouts, fewer oversells, and stock numbers your sales team can quote from without checking first. Across appse ai deployments, businesses running this pattern have seen a 40% reduction in stockout incidents.
Four things do the work, and they map directly to the five causes above.
- Timing. appse ai sends updates the moment something happens. A sale, an ERP record change or a system event triggers the update straight away instead of waiting for a scheduled run, which removes the timing gap at the source.
Product codes and settings. Ready-made, pre-checked field connections between SAP Business One, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Salesforce, HubSpot and Shopify mean the right stock number is shared on purpose, not by default. Ready-to-use templates cover common setups, including stock reorder sync.
- Silent failures. AutoDetect watches for anything unusual, tries to correct it automatically, and passes anything it cannot fix to a person with the details attached. It looks for problems rather than waiting for them to be reported.
Unrecorded stock movement. The AI Inventory Intelligence Agent watches stock levels, reordering and demand continuously, so adjustments and problems show up as they happen.
It runs in the cloud, on your own servers, in a private cloud, or a mix of these, which matters if your ERP cannot leave the building.
None of this replaces the decisions in the section above. It carries them out.
The Takeaway
Inventory data being different across your systems is not about people being careless. It is about how your systems were connected, which stock numbers they were told to share, and what happens when an update fails.
Work out the cause before you change any settings. Check the numbers at the same moment. Check which stock number each system is sharing. Line up your product lists. Count orders against orders. Split your stock movements into automatic and manual. One of those five checks will tell you what you are dealing with.
Then decide who owns each number and how far apart they are allowed to drift. Without that, you will be fixing the same problem again in a few months, in a slightly different form.
Stock differences do not get fixed once. They get managed, or they come back. appse ai keeps stock updated across your ERP, online store and marketplaces in real time, spots problems before they reach your stock numbers, and passes anything it cannot fix to a person with the full details.
See How AI Automation Works along with SAP Business One
Book a 20-minute demo and we'll walk through your specific process.
Book a Demo
