Oversell protection: how the stock buffer works
The risk: selling the last unit twice
You have one piece of an SKU left. A buyer on eMAG adds it to cart at the same second someone else does on your own store. Both orders go through. Now you owe two units and you have one. Someone gets a cancellation, the marketplace counts a missed order against your seller metrics, and you spend the afternoon apologizing.
This isn't a rare edge case on fast movers and end-of-line stock. The more channels you list on, the more often two of them race for the same last unit. Oversell is the single most expensive failure mode in multi-channel selling, and it's the one a thin sync layer exists to prevent.
The formula: max(0, available − buffer)
MEGZO never publishes your raw available quantity to a channel. It publishes a held-back number:
channelStock = max(0, available − buffer)
The buffer is a configurable safety margin. Your ERP says 5 on hand and the buffer is 2, so eMAG sees 3. The max(0, …) floor means the channel never sees a negative number: if available drops to 1 with a buffer of 2, the channel sees 0 and the offer goes out of stock rather than into the red.
The buffer is the cushion that absorbs the gap between when a sale happens and when every channel hears about it. Poem, the first tenant on the platform, runs a buffer of 2. That covers the normal lag without parking much inventory.
Why a buffer beats real-time only
The instinct is to skip the buffer and just sync faster: push stock the instant it changes and the race never happens. It doesn't hold up.
- Marketplaces aren't instant either. A stock update you send to eMAG takes time to accept, index, and reflect on the live offer. During that window the old number is still sellable. No webhook closes that gap to zero.
- Channels move independently. An order can land on eMAG in the same window an order lands in your own store. Even with both wired to the same source of truth, neither knew about the other when the buyer clicked.
- Failures happen mid-flight. A dropped call, a rate limit, a retry: any of these stretches the window. A buffer keeps you safe while the system catches up instead of betting everything on perfect delivery.
So MEGZO does both. Stock moves on a 5-minute pull heartbeat plus push and webhook wake-ups where the channel supports them, which is fast, and it ships behind a buffer so the moments between syncs can't oversell you. Speed narrows the window; the buffer covers what's left.
How reconciliation heals drift
Buffers and fast syncs reduce drift; they don't eliminate it. Counts still wander, whether from a manual stock adjustment in the ERP, a channel that silently rejected an update, or a cancelled order that freed a unit nobody re-published.
That's what reconciliation is for. MEGZO continuously re-checks what each channel currently shows against what your ERP says it should show, and corrects the difference. If eMAG is sitting on a stale quantity, the next sweep pushes the right one. Drift gets caught and healed on a schedule rather than discovered by an angry customer.
The pairing is the point: the buffer prevents oversell in the live moment, reconciliation keeps the published numbers honest over time. Neither alone is enough.
How to tune the buffer
The buffer is a knob, not a constant, and it's a direct trade-off: a bigger buffer is safer against oversell but hides more sellable stock; a smaller one exposes more inventory but leaves less cushion. How to set it:
- Raise it for fast movers and thin stock. An SKU that sells several units an hour needs more cushion than one that moves a unit a week.
- Raise it as you add channels. More places racing for the same pool means more chances to collide.
- Keep it low on slow, deep stock. If you hold hundreds of a part that sells rarely, a buffer of 1 or 2 is plenty and you're not hiding sellable units.
- Watch the out-of-stock floor. On low-count SKUs the buffer decides when the channel shows zero. A buffer of 2 means an item goes out of stock with 2 still physically on the shelf, usually the trade you want, but know you're making it.
The buffer is configured per tenant, and because the per-field mapping is yours, stock rules live in config you can change rather than code you have to wait on a deploy for.
Where this sits in the bigger picture
Oversell protection is one of a few non-negotiables MEGZO runs by default. Order ingestion is idempotent: one channel order becomes exactly one ERP Sales Order, enforced by a unique key, a per-order lock, and an ERP-side duplicate pre-check, so a retry never doubles an order. Your ERP and invoicing stay the single source of truth; MEGZO is the thin, configurable sync layer in between. If you're migrating off BaseLinker, the shift is architectural: there, the data hub lives in BaseLinker; here, your ERP stays in charge and MEGZO maps to it on your terms.
See all integrations or get started.