There’s a particular kind of business where the website says there are six units of something, the warehouse shelf has four, the accounting system thinks there are nine, and the person who could tell you which is right is on holiday. Orders get taken for stock that isn’t there, purchase orders get raised for stock that is, and once a quarter someone does a count and adjusts all three systems by hand, which fixes the numbers until Tuesday. We get called about this a lot, usually after an oversell that upset a good customer. The fix is mostly about deciding, and then about plumbing.
Quick answer: Pick one system as the record of truth for stock, usually the one closest to the physical goods. Make every other system read from it and never write to it. Then find the handful of events that change stock without going through that system (returns, damaged goods, kits, manual adjustments, marketplace orders) and route each one through it. Reconcile weekly with a report rather than a full count, and keep a small buffer on channels where an oversell hurts most.
Why do three systems disagree?
Because each of them is allowed to change the number, and they tell each other about it late or not at all. The ecommerce platform decrements stock when an order is placed. The warehouse system decrements when the order is picked, which might be the next day, and increments when a return comes back, which the website never hears about. Accounting adjusts when an invoice is raised or a credit note issued. A bundle of three products sells on the website as one SKU and reduces one number, while the warehouse pulls three items and reduces three. A manager fixes a count on the shelf by editing the warehouse system directly. Every one of those is reasonable on its own, and together they guarantee drift.
The other big cause is SKU discipline, or its absence. The same product exists as SHIRT-BLU-M on the website, SHIRTBLUM in the warehouse, and “Blue shirt (medium)” in accounting, and the sync tool someone set up two years ago matches on the first two and silently skips the third. Variants are the usual casualty: colour and size combinations that were added on the website after the warehouse import and never mapped.
Which system should be the record of truth?
The one nearest the shelf, in most cases. If you run your own warehouse with a warehouse management system, that’s it, because it’s the only system where a person can look at the number and then look at the shelf. If you use a third-party fulfilment provider, their system is the truth for what they hold and you’re reading from it. If you have no warehouse system and stock is managed on the website, then the website is the record of truth by default, and the question becomes whether it’s up to the job; Shopify and WooCommerce both handle single-location stock reasonably and get awkward with multiple locations, which our Shopify vs WooCommerce comparison touches on.
Accounting is almost never the right choice. Accounting systems care about the value of stock, and they learn about movements after the fact from invoices and bills. Trying to make Xero or QuickBooks the live stock record is how you end up with the finance team blocking a sale because a bill hasn’t been entered yet.
Once you’ve chosen, the rule is simple to state and takes some discipline to keep: other systems read stock from the record of truth, and every stock change is sent to the record of truth first, from wherever it happens.
What events change stock without anyone noticing?
Returns are the biggest. A return comes back to the warehouse, gets put on the shelf, and the website still shows it as sold; or worse, it gets restocked on the website by customer service before the warehouse has inspected it, and it was damaged. Then kits and bundles, mentioned above, which need a rule for which component’s stock limits the bundle. Damaged and written-off stock, which usually goes into accounting as an adjustment and nowhere else. Marketplace orders from Amazon or eBay, which reduce real stock and reach the website’s count only if there’s a channel integration, and only as fast as it polls. Purchase orders received, which increase stock on the day the goods arrive rather than the day the PO was raised, and stock on order that sales counts as available.
Multi-location makes each of these worse, because now the question is how many, and where, and whether the website should sell stock that’s in the wrong location for the customer.
How do you set the sync up properly?
- Choose the record of truth and write it down, along with who is allowed to make manual adjustments in it and how they record why.
- Clean up SKUs. One identifier per sellable variant, identical across systems, and a mapping table for the legacy ones you can’t change. This is dull and it is most of the work.
- Connect every other system to read from the record of truth, on a schedule that matches how fast stock moves. Hourly is fine for most businesses; a flash sale wants minutes.
- Route the invisible events through it: returns get received in the warehouse system before anyone restocks them online; bundles get a rule; marketplace channels feed in through an integration rather than a spreadsheet.
- Add a buffer per channel. Show the website two fewer than the warehouse has for products where an oversell would be expensive, so the last unit isn’t sold twice while the sync catches up.
- Build a reconciliation report: for every SKU, the count in each system, the difference, and the last movement in each. Look at it weekly and only cycle-count the SKUs that disagree. Full stocktakes become a once-a-year exercise instead of a quarterly emergency.
Off-the-shelf connectors cover a lot of this if your systems are common ones. Where they run out is the rules: the bundle logic, the returns inspection step, the buffer per channel, the reconciliation report itself. Those tend to be where a small custom integration earns its cost, and the decision follows the same logic as our post on custom software vs off-the-shelf: buy the commodity connectors, build the part that encodes how your business works. If you sell to trade customers as well, the B2B ordering portal post covers the additional wrinkle of reserving stock for account customers.
We build these integrations as part of custom software development for small business, and the first week is almost always the SKU cleanup rather than any code.
Frequently asked questions
Can we fix this with a spreadsheet?
You can reconcile with one, and plenty of businesses do, but a spreadsheet can’t stop the next oversell because it isn’t in the path when the order is placed. Use it for the weekly comparison while the sync is built, then retire it.
How often should stock sync?
As often as stock changes materially. Hourly suits most businesses selling from a single location. If you run promotions that sell through a product in an afternoon, you want near-real-time on the website channel, which usually means webhooks from the warehouse system rather than polling.
What do we do about stock that’s on order?
Show it separately. Available-to-promise is on-hand minus allocated, and stock on order is a different number with a date attached. Websites that add incoming stock to available stock are the source of a lot of “we’ll ship it this week” emails that turn out to be wrong.
Should the website ever be the record of truth?
If there’s no warehouse system and one location, yes, and it works fine at small volume. The moment there’s a second location, a fulfilment partner, or a marketplace channel, the website is a sales channel like the others and should read from something else.
How do we handle returns without restocking damaged goods?
Two steps in the warehouse system: received, then inspected and either restocked or written off. Only the restock step should change available stock. Customer service refunding a customer shouldn’t touch inventory at all.
Our fulfilment provider’s numbers are wrong too. Now what?
Then the reconciliation report is between your record and theirs, and their contract should say how discrepancies are resolved. In practice this is where the cycle count on disputed SKUs, done by them at your request, settles it.