The ERP marketplace synchronisation and oversell problem has become the biggest operational nightmare in multi-channel e-commerce. A customer seeing an 'out of stock' message after placing an order both damages brand reputation and creates a direct loss of revenue.
The Oversell Problem: Cost and Causes
Overselling occurs when a product is sold simultaneously across more than one sales channel while the actual stock is insufficient. For businesses selling at the same time on marketplaces such as Trendyol, Hepsiburada and Amazon, this problem can reach critical proportions. The average oversell incident generates four separate cost items: order cancellation, the customer complaint process, return shipping costs and potential penalty points. Research shows that poor stock management costs a mid-sized e-commerce business between 3-7% of its annual turnover.
- Instantaneous stock inconsistencies: When each platform updates stock at a different frequency, real-time synchronisation breaks down.
- ERP delays: When systems such as SAP, Netsis or Logo run batch updates, thousands of units can appear incorrectly within minutes.
- Multi-warehouse complexity: Orders fulfilled from more than one warehouse create race conditions without reservation logic.
5 Architecture Recommendations: Solving Overselling at the Root
At Toserof Tech., having managed the integration processes of hundreds of e-commerce companies over the years, we have observed that the five architectures below resolve the oversell problem at a rate of 95%. We also indicate which scale each recommendation is suited to.
1. Central Stock API Gateway
All channels (Trendyol, Hepsiburada, Amazon, your own site) connect to a single central stock service. No channel is connected directly to the ERP; everyone reads and writes through the gateway. This approach ensures that stock information is preserved as the single source of truth. Where required, the gateway can be protected with rate limiting and circuit breakers. For businesses handling 500+ orders a day, this is the fundamental architectural component.
2. Event-Driven Synchronisation
Every stock change is published as an event (Kafka, RabbitMQ or AWS SQS). Interested systems subscribe to these events and update their own caches. In this approach no system polls; it receives a notification whenever a change occurs. Latency drops to the order of milliseconds. It is ideal in particular for multi-channel businesses experiencing high-frequency stock changes.
3. Buffer (Safety) Stock Automation
For high-volume channels such as Trendyol, 5-10% of physical stock is hidden and released only in moments of sudden high demand. This ratio can be adjusted dynamically based on purchase history and purchase frequency analysis. The ERP integration manages this hidden stock automatically. In categories with strong seasonal fluctuations, the buffer ratio can be increased automatically.
4. Real-Time Webhook System
Each platform sends a webhook notification the moment an order arrives. The ERP integration processes these webhooks instantly and reserves the stock immediately. No order is confirmed without a reservation. This approach provides stock locking measured in milliseconds. The official Trendyol and Hepsiburada APIs provide webhook support; however, correct configuration and error handling are critically important.
5. Distributed Stock Reservation Architecture
In multi-warehouse operations, a separate microservice runs for each warehouse. When an order arrives, stock in the nearest and most suitable warehouse is reserved automatically. If two warehouses attempt to sell the same product at the same time, a distributed lock mechanism prevents it. This architecture is critical in particular for businesses working with 3PL providers. Distributed lock management is delivered with technologies such as Redis or etcd.
SAP, Netsis and Logo Integrations
The vast majority of the ERP ecosystem in Turkey is built on SAP Business One, Netsis or Logo Tiger. Each has a different API structure and different update frequency characteristics; the right integration strategy must take these differences into account.
- SAP Business One: Real-time queries are possible via the Service Layer API; however, request performance at high frequency must be managed carefully.
- Netsis: A service API is available; since webhook support is limited, a polling + cache combination is recommended.
- Logo Tiger: Well suited to modern integration thanks to REST API support; it is particularly easy to adapt to an event-driven architecture.
Which Architecture Suits Which Scale?
Not every business needs the same architecture. For small-scale businesses receiving fewer than 50 orders a day, a simple webhook + buffer combination may be sufficient, whereas for large multi-warehouse operations an event-driven and distributed reservation architecture becomes essential. Choosing the right architecture depends on factors such as daily order volume, number of channels, warehouse structure and ERP characteristics. Choosing the wrong architecture can add complexity rather than solve the existing problem.
Success Stories and Results
The results we have achieved at Toserof Tech. across our ERP integration projects present a consistent picture. Among clients who implemented a central API gateway + event-driven synchronisation, the oversell rate fell by an average of 92% within the first three months. Companies integrated with buffer stock automation experienced zero oversell incidents even during seasonal campaign periods. Stock update time dropped from an average of 18 minutes to under 2 seconds. These results prove that the right architecture delivers a tangible return on investment in a short time.
Frequently Asked Questions
How often does overselling occur?
In non-integrated or poorly integrated systems it can happen several times a day. With a well-configured synchronisation architecture, this can be reduced to once a month or even less.
How long can an ERP update delay be?
In ERP systems that run batch updates, this delay can range from 5 to 30 minutes. With a real-time webhook and event-driven architecture, latency drops below 1 second.
Which solution is suitable for small-scale businesses?
For businesses handling between 50 and 200 orders a day, a webhook + buffer stock combination is generally sufficient. This solution is both economical and quick to set up.
Is there a standard solution for Trendyol and Hepsiburada integration?
Both platforms provide official API documentation. However, for high-volume sales, rate limit management and customisation of the order confirmation flow are required.
Conclusion
When ERP and marketplace integration is built on the right architecture, the oversell problem is almost entirely eliminated, operational efficiency increases and customer satisfaction rises. Contact Toserof Tech. for expert support with ERP integration and multi-channel synchronisation.
