Syncing stock and orders between eMAG Marketplace and your ERP: how to stop overselling and penalties

The problem that costs the most: stock that matches nowhere

If you sell on eMAG Marketplace and keep your real stock in an ERP, you have two numbers that should always be equal and almost never are. Between the moment a product sells in your physical shop or website and the moment eMAG "learns" you're out of that unit, time passes. During that time, someone buys it again.

The result is called overselling, and on eMAG it's not a cosmetic issue. Every order you cancel for lack of stock hurts your performance metrics — the merchant-fault cancellation rate is tracked directly and affects offer visibility, campaign eligibility, and, if it repeats, can lead to account suspension.

The numbers we see at merchants with 500-5,000 active SKUs on Marketplace:

• 2-6% of orders cancelled because of desynced stock, in months without automated integration
• Stock updated manually 1-3 times a day, via file export-import — meaning a 4-8 hour window where the eMAG number is wrong
• 15-40 minutes/day per operator lost downloading orders, copying them into the ERP and re-entering tracking numbers
• Pricing errors on every campaign, because the price changes in the ERP but not on the offer

They all share one cause: two systems that don't talk to each other in real time.

Why spreadsheets and manual updates fix nothing

Almost every merchant's first solution is a file: export stock from the ERP in the morning, import it into eMAG, done. It works right up until the day you have a sales spike. Then:

• The morning stock is already stale by noon, and you find out tomorrow
• Someone forgets the import on a busy day — the exact day you needed it
• The file has one misspelled SKU and 40 products drop to zero stock without anyone noticing

Manual updates scale inversely with success: the more you sell, the more often you're wrong. An integration through the eMAG Marketplace API fixes the problem at the source — stock propagates in seconds, not hours, and orders flow into the ERP on their own.

What a correct integration actually looks like, in two directions

A serious sync isn't "a sync button." It's two separate flows that must be treated differently:

Direction 1 — Stock and prices: from ERP to eMAG. The ERP is the source of truth for how many units you have and at what price. Every stock movement (sale, receipt, transfer, reservation) triggers an offer update on eMAG via the API. Ideally not on a fixed interval, but on an event: a unit sold, the offer adjusts immediately.

Direction 2 — Orders and fulfillment: from eMAG to ERP. Every new order is pulled automatically from the API and turned into an order/dispatch note in the ERP, with the customer, products and address filled in. On shipping, the tracking number and status flow back to eMAG without the operator touching anything.

The part most amateur integrations miss is the reliability of these two flows:

• Idempotency. If you pull the same order twice (and you will, on a network timeout), the system must recognize it has already seen it and not create a duplicate in the ERP. The idempotency key is the eMAG order ID, not arrival order.
• Retry with backoff. The eMAG API has rate limits. A correct integration doesn't give up on the first 429 error — it retries intelligently with growing pauses and queues whatever failed.
• Safety buffer. For fast-moving products, it's wise to publish real stock minus 1-2 units on eMAG. The cost is an occasional missed sale; the benefit is zero cancellations on hot products.
• Periodic reconciliation. Once an hour, a job compares ERP stock against the live offer and corrects any drift. The event flow is fast; reconciliation is the safety net.

Case study: a merchant with 2,800 SKUs on Marketplace

A home-and-garden merchant we worked with at NEXVA SYSTEM sold on eMAG and in two physical shops, with a local ERP as the stock source. They updated stock by file twice a day. During one campaign month, the out-of-stock cancellation rate hit 5.4%, and two people together lost nearly 2 hours/day processing orders and entering tracking numbers.

What we built:

• A connector on the eMAG Marketplace API, with event-based stock sync from the ERP (under 20 seconds from movement to updated offer)
• Automatic order pull into the ERP, with deduplication on the order ID and an hourly reconciliation job
• Automatic push of tracking numbers and statuses back to eMAG, integrated with the courier account
• A per-category configurable buffer and alerts for products dropping below a stock threshold
• A dashboard for cancellations, processing times and ERP–eMAG stock drift

Results after 3 months:

• Out-of-stock cancellation rate: from 5.4% to 0.7%
• Order processing time: from ~2 hours/day to under 25 minutes/day
• Wrong-stock windows: from 4-8 hours to under 1 minute on fast-moving products
• Zero orders lost or mis-entered into the ERP across three campaigns
• An unexpected effect: with offers always accurate, the merchant score rose, and several products re-qualified for campaigns they'd been dropped from

What it costs and when it pays back

For a merchant with 500-5,000 active SKUs:

| Component | Cost |

|-----------|------|

| Flow analysis + field mapping ERP ↔ eMAG | 1,500-3,000 EUR |

| API connector: stock + prices (ERP → eMAG) | 4,000-7,000 EUR |

| API connector: orders + tracking (eMAG → ERP) | 4,000-7,000 EUR |

| Reconciliation, buffers, alerts, dashboard | 3,000-5,000 EUR |

| Monthly costs (hosting + monitoring + maintenance) | 200-500 EUR/month |

The ROI math is direct. At a merchant with 3,000 orders/month and an average value of 180 EUR, cutting the cancellation rate from 5% to 1% means ~120 saved orders per month — over 21,000 EUR/month in orders that no longer vanish. Add 1.5-2 hours/day of manual work removed and the investment typically pays back in 4-7 months.

The mistakes that sink these projects

• Fixed-interval sync instead of event-based. An update every 30 minutes beats a spreadsheet, but still leaves an overselling window during traffic peaks.
• No idempotency. On the first network hiccup you'll have duplicate orders in the ERP and double shipments. Deduplication is not optional.
• Ignoring rate limits. Without retries and queues, a big campaign floods your integration with 429 errors and you lose updates exactly when they matter most.
• Planning for one channel only. If you also sell on your website or another marketplace, stock must be designed centrally from the start, or you'll build the same integration twice.

Where to start

1. Measure the current state: out-of-stock cancellation rate, how many manual updates you do per day, minutes lost on processing

2. Map the fields between ERP and eMAG: SKU, stock, price, category, and the order and tracking fields

3. Start with stock → eMAG on events — that's the biggest loss and the fastest win

4. Add order pull and tracking numbers, then hourly reconciliation as a safety net

5. Expand to multichannel only after the first integration runs stable through two or three campaigns

The marketplace rarely forgives a high cancellation rate, and competition on eMAG is played at the level of score and visibility. The difference between merchants is no longer who has stock, but who manages to show it correctly, in real time, without throwing people at the problem.

Want to see how many orders you lose each month to desynced stock, and how much of the eMAG–ERP flow can be automated? Book a free consultation.