The last unit sells at the till at 7 p.m. Your website, which last updated its stock that morning, sells it again at 9 p.m. The online customer gets a refund and a story they tell in a review. That is overselling, and it is rarely a staff mistake: it happens when POS and store each keep their own stock count and nobody has decided which is true.
The short answer: pick one stock authority, reserve at payment, sync in near-real time
Decide which system holds the single true stock record — for most retailers the POS, or a central inventory system above both till and store — and make every channel read and write back to it. Sell only the available-to-sell number, not the physical count. Reserve a unit the moment a customer pays, not when staff pack it. And sync in near-real time: even an hourly export leaves a window in which the last unit can be sold twice.
Why you oversell: two ledgers, scheduled syncs and stock nobody reserved
Two ledgers is the root cause. The till decrements its count at scan; the web store decrements its own at checkout; if the two are reconciled later — nightly file, spreadsheet, or a person — they disagree for most of the trading day, and both will sell the final unit.
Scheduled syncs widen the gap: a polling connector is only accurate until the next sale, and fast sellers do not respect the schedule. The third cause is subtler — stock promised but not reserved. An item awaiting packing still shows as available to the till unless reserved at payment, so the shop floor sells a unit already owed to someone.
Available-to-sell is not on-hand: the number every channel must share
On-hand is what a stocktake finds on the shelf. Available-to-sell is on-hand minus what is already promised: units reserved by paid online orders, click-and-collect holds, and a safety buffer if you run one. Channels must sell from available-to-sell. If the till sells from on-hand while the website sells from available-to-sell, the ledgers disagree by exactly the promised units.
Pick the definition once — available-to-sell, calculated by the stock authority — and require every channel, including marketplaces, to sell from that figure. Shopify's inventory documentation distinguishes stock states and locations for the same reason, and WooCommerce's stock management works from a single product stock quantity; one calculation must serve every channel.
The four sync architectures: same-platform POS, connector app, OMS/middleware, custom integration (table)
Four architectures solve the problem, at rising cost and control.
| Architecture | How it works | Best fit | Main limit |
|---|---|---|---|
| Same-platform POS | The till is the store platform's own POS: one shared inventory record | Single-platform retailers, few branches | Locks till and store to one platform |
| Connector app | A connector passes orders and stock changes between POS and store | One store, one POS, modest volume | Sync method is the vendor's; polling gaps possible — verify in its docs |
| OMS / middleware | An order management system becomes the stock authority and allocates stock across all channels | Multi-branch, multi-channel sellers | Another system to run; justified only at volume |
| Custom integration | Store and POS exchange stock and orders via APIs/webhooks built for you | Retailers whose POS or rules fit no connector | Build and maintenance sit with you |
Vendors describe their own capabilities on their own pages — Anchanto's UAE order-management page, for example, presents real-time cross-channel synchronisation with stock allocation and buffer stock. Treat such claims as descriptions to test in your acceptance run, not guarantees.
How to choose by branches, channels and order volume
Start with the simplest architecture that covers your channel mix. A single shop adding a web store on its till's platform should start there: one record, nothing to synchronise. If your POS is separate and staying, a connector is the honest next step, provided its sync is event-driven or frequent enough for fast sellers — check the vendor's documentation, and test the delay yourself.
An OMS earns its place when allocation becomes the problem: several branches, a warehouse, and Amazon.ae or noon listings drawing on one pool, with rules for which location fulfils which order. Custom integration suits retailers who have outgrown the connectors' rules — unusual reservation logic, or a legacy POS with an API but no connector. Volume is the tiebreaker: more daily orders on the same SKUs means a polling gap costs more. Still choosing the store platform? Our Shopify vs WooCommerce comparison covers that; settle stock architecture alongside it.
The unglamorous prerequisites: one SKU list, matching barcodes, returns and transfers done properly
No sync architecture survives dirty data. The POS and the store must share one SKU list: the same code for the same product, with variants — size, colour — modelled identically in both. The classic failure: one SKU at the till, three on the website, or a barcode that scans to a different item online. Reconcile the lists first, and give one named person ownership of new SKUs.
Process discipline matters as much as codes. A return re-enters available-to-sell only when physically back and booked in; a branch transfer decrements the sending branch when it leaves, not when it arrives; deliveries are booked in before shelving. Trust is the point: a record staff work around with a spreadsheet will lose at the worst moment.
Marketplaces too: Amazon.ae and noon in the same count
Marketplaces are more channels selling from the same pool, and they punish stale stock hardest: no apologetic phone call reaches an Amazon.ae customer. The stock authority must feed marketplace listings too — directly, through the OMS, or through seller tools — so a till sale cuts marketplace availability in near-real time.
Where a direct feed is not possible, protect the channel with allocation: ring-fence a quantity other channels cannot sell, and accept the occasional missed sale as the price of never overselling there. Never list full on-hand stock everywhere at once; that is a promise to refund. For the store side, see how we scope channel-ready builds under ecommerce website development in Dubai and our overview of ecommerce website design for online stores.
The five-sale acceptance test: prove sync works before you spend on ads
Do not accept "it syncs" as a deliverable. Run five sales against one low-value SKU with a known count, watching the other channels after each. One: sell at the till — store and marketplace availability must drop. Two: buy online — till availability must drop, with the unit reserved at payment. Three: refund the online order — the unit returns only under your returns rule. Four: transfer a unit between branches — both numbers must move. Five: sell the final unit anywhere — every other channel must show it unavailable, timed.
Record each delay: a sync that takes twenty minutes to close the last-unit window will oversell during a promotion whatever the brochure says. If a step fails, you have found the gap while it costs nothing. Retailers who need the integration built can scope it inside a store project — see our guide to ecommerce website costs in Dubai and our custom web application development team.
Buffers, alerts and what to do while the fix is in progress
While the real fix is being built, reduce the blast radius. Set a safety-stock buffer on your fastest sellers: when available-to-sell falls to the buffer, online channels show out of stock while the shop can still sell in person. Turn on low-stock alerts at the stock authority, so a human hears about a thin SKU before it sells twice.
For the interim, reconcile at close of trade, correct the web store first, and log every oversell with its cause — that log is the requirements list for the permanent fix.
Common mistakes that bring overselling back
The first is choosing a connector on price without checking how it syncs — a scheduled poll dressed up as real time is how overselling usually returns after an expensive "fix". The second is letting a spreadsheet live on beside the new system — a shadow count means two ledgers again.
Other repeat failures: creating SKUs in one system only; counting display or damaged units as on-hand; treating marketplace stock as a separate pool nobody owns; never re-running the acceptance test after a platform update, new branch or new channel. Sync has to be re-proven whenever anything in the chain changes.
FAQ
Can I sync my POS and online store without changing my POS?
Usually, yes. A connector app or custom API integration can bridge an existing POS to your store, provided the POS exposes the data — an API, webhooks or a reliable export. The limit is the POS's sync method, so verify it in the vendor's own documentation first.
Is real-time sync actually necessary, or is hourly enough?
It depends on how fast your SKUs move. If the last unit can sell twice inside your sync interval — in a promotion, on a bestseller, almost certainly — hourly is not enough. Fastest sellers set the requirement.
Which system should be the single source of truth for stock?
The system that sees every movement first — for most shop-plus-store retailers, the POS or a central inventory/OMS layer above both. Other channels should read and reserve against that record, not keep their own counts.
How do I stop overselling on Amazon.ae and noon?
Feed marketplace availability from the same stock authority as your store, or ring-fence an allocation other channels cannot touch. Never list full on-hand stock everywhere at once; include a marketplace sale in your acceptance test.
What is a safety stock buffer, and how big should it be?
A small quantity held back from online availability so a sync delay cannot oversell the final units. Size it from your oversell log: cover the sales inside your worst measured sync delay on fast lines — often one or two units.
Get the sync built into your store (CTA)
If your till and your store still keep two counts, the fix is an architecture decision followed by a tested build — not another spreadsheet. Bring us your channel list, your POS and your worst oversell stories, and we will propose the simplest sync that fits, with an itemised proposal within 24 business hours. Start with our ecommerce web development service, or reach us on WhatsApp at +971 52 595 3174 and hello@webstackrank.com.
