The phone call is always the same one. "Hello, about your order from yesterday — it turns out we're out of that item." The customer had paid. Now they wait days for a refund, and they tell people about it.
Overselling is not a website problem and it is not a warehouse problem. It is the problem of the two never talking to each other.
This is how the gap opens, the three ways to close it, which one your business actually needs, and what it costs.
Where the gap comes from
Four sources, almost always the same ones.
Manual updates. Someone types stock levels into the website when they remember to. Between one update and the next, your shop is showing the past.
Sales in the physical shop. If you sell both in store and online from one stock, every counter sale should reduce the website figure. It almost never does in real time.
Marketplaces. Add Amazon or eBay and now three channels compete for the same units. This is where overselling stops being occasional and becomes weekly.
Variants. In clothing and footwear one product is thirty references across sizes and colours. Stock can be correct at product level and wrong at size level — which is what the customer actually buys.
There is a fifth case that costs more than people think: the reverse problem. The item is sitting in the warehouse but the site says "out of stock". Nobody complains, nobody calls, and you never learn about the sale that did not happen. That loss appears in no report you run.
The three ways to connect
Three technical levels, three price points.
File exchange. Your accounting or stock software exports a file and the website reads it. Simplest and cheapest. Runs once or a few times a day. Fine if your stock moves slowly.
Scheduled sync. The two systems exchange data automatically every
15 or 30 minutes. Middle cost, middle complexity. For most shops this is exactly what is needed.
Event-driven sync. A sale happens and stock changes on both sides immediately. Most accurate, most expensive. Necessary when you sell single units or when volume is high.
The choice depends on turnover, not budget. Selling building materials with twenty units per line? Scheduled sync is more than enough. Selling vintage clothing where every piece is unique? You need event-driven, because with a fifteen-minute delay you will sell the same jacket twice.
A quick test: how many units do you hold of your best-selling line? If the answer is one or two, you need real time. If it is twenty, you do not.
Reserving stock at the right moment
This detail decides whether the integration works at all, and it gets skipped constantly.
The question is when a unit stops being available. There are three possible moments and only one of them is sensible.
Deduct stock when the item goes into the basket and abandoned carts will lock up goods nobody intends to buy. With enough traffic your shop shows as sold out while the shelves are full.
Deduct stock when payment completes and there are several minutes between the customer entering their details and finishing payment. In that window another customer can buy the same unit. This is where most real overselling happens.
What works is a temporary reservation when checkout begins, fifteen or twenty minutes, released automatically if payment is not completed. The customer paying has their unit guaranteed and stock is never locked indefinitely.
What happens when the sync fails
It will fail. Connections drop, servers restart, software gets updated. The question is not whether it happens but what happens when it does.
A badly built system does one of two things, both bad: it keeps selling on stale data as if nothing happened, or it stops showing stock and your entire shop appears empty.
A well built system stores the order, sends it once the connection returns, and alerts an administrator that something is wrong. The shop keeps working, you find out, and no order is lost.
When you take quotes, ask this exact question: "what happens if the sync goes down for an hour?" If the answer is "that won't happen", keep looking.
Multiple locations and returns
Two situations that break simple setups.
More than one stock location. Own warehouse, shop floor, sometimes goods held at a supplier. The website needs one number, but that number has to come from a rule you decide: do you sell from all locations, or only from the warehouse? Selling from shop-floor stock means the shop assistant and the website are competing for the same item, and the assistant always wins because they are physically holding it.
Returns. A returned item is not automatically sellable again. It may need checking, repackaging or writing off. If the system puts returns straight back into available stock, you will sell damaged goods. There should be a step between "returned" and "available", even if that step is one person clicking a button.
What integration does not fix
Worth saying plainly, because it works against our commercial interest: connecting your website to your stock system does not improve data that is already wrong. It only spreads it faster.
If the same product exists three times under different names, if theoretical stock does not match what is on the shelf, or if deliveries get recorded whenever someone gets round to it, the integration will display those errors on your website, in front of your customers.
Which is why the order is this and not any other:
- Clean the data. One product, one code, one name. Remove
duplicates. Dull work, cannot be skipped.
- Do a real stock count. Not theoretical — count. System and
shelf must match on day one.
- Get stock control running. Deliveries and dispatches recorded
as they happen, not at the end of the week.
- Connect the website. Now there is something worth connecting
to.
Skipping steps one and two is the most common reason these projects end badly.
Cost and timescale
| Work | Price | Timescale |
|---|---|---|
| Online shop | from $1,250 | 2-4 weeks |
| Stock control system | from $700 | 2-4 weeks |
| Integration between them | quoted separately | 1-2 weeks |
The integration has no fixed price, and that is the honest answer. It depends entirely on which software you use now and whether it offers an API or only file export. With Xero, QuickBooks or most modern platforms there are known routes. With an older in-house system and no API, file exchange still works but updates hourly rather than instantly.
That is the first thing we check, before quoting anything.
Doing the shop and the stock system together costs less than two separate projects, because the data structure gets designed once instead of twice.
When it is not worth doing
Four cases where we would tell you not to bother:
Few lines that rarely change. Twenty stable products: updating by hand costs less than integrating.
Five orders a month from the site. Copying those by hand is ten minutes a month. The integration would take years to pay for itself.
You sell services. There is no stock. What you need is a CRM.
You have no stock control yet. Do that first. Connecting a website to an out-of-date spreadsheet makes things worse, not better.
Summary
Overselling comes down to three decisions: match the sync frequency to your actual turnover, reserve stock when checkout starts rather than earlier or later, and have a plan for when the connection drops.
Plus one non-negotiable condition: the warehouse data has to be true before you connect anything to it.
Tell us what you sell, how many lines you carry and what you use for stock today. We will tell you whether your software can connect, which level of sync you genuinely need, and what it costs. One working day for a written answer.