The moment an online store no longer just receives data from the ERP but writes back itself, a simple transfer becomes a bidirectional synchronization - and that is where the real problems begin. Customer accounts, orders and status changes now originate in the shop and have to flow back into the ERP, while items, prices and stock flow from the ERP into the shop. When both sides are allowed to change the same field, data conflicts arise: an overwritten stock level, a reset price or an endless loop of mutual updates. Poor data quality costs organizations an average of 12.9 million US dollars per year according to Gartner (Gartner), and only 3 percent of company data meets basic quality standards (Harvard Business Review). This article shows how to resolve conflicts in bidirectional ERP-shop synchronization systematically - with clear field ownership per data category instead of blind last-write-wins, and with mechanisms that prevent sync loops. The related but distinct topics of master data governance in an MDM and idempotency and retry strategies are deliberately left aside.
Key takeaways
- As soon as the shop no longer only reads but writes back, the question is no longer whether a conflict occurs but when: overwritten stock, reset prices or endless loops of mutual updates.
- Poor data quality costs organisations an average of 12.9 million US dollars (Gartner) per year, and only 3 percent (Harvard Business Review) of company data meets basic quality standards.
- Last-write-wins decides purely by timestamp (coraltree-systems.de): it assumes perfectly synchronised clocks, treats every field alike and discards the losing change without a log entry, so unnoticed.
- The workable alternative is field ownership: exactly one system owns the truth per field (loskan.io). The ERP leads items, prices and stock, the shop leads customer accounts and orders; the line runs through fields, not through systems.
- Sync loops are broken by origin tagging, echo suppression, correlation IDs and a change comparison before writing. Field ownership, master data management and idempotency complement each other but each solves a different problem.
Why Shops Now Write Back and Conflicts Arise
In the early years of shop integration the direction was clear: the ERP or inventory system was the source, the shop the display window. Items, prices and stock flowed in one direction, and the shop itself created hardly any data of its own. That has changed. Modern shops are account, order and partly pricing platforms: customers register, maintain delivery addresses, place orders, cancel and store payment methods. This data has to flow back into the leading system so that order processing, accounting and planning can work with it. The connection therefore inevitably becomes bidirectional.
The economic pressure behind this is real. German online retail has grown to 92.3 billion euros (HDE Online-Monitor 2026), and the online share of retail sales stands at 13.5 percent (HDE Online-Monitor 2026). At the same time, 44 percent of B2B buyers have switched supplier at some point because of a poor digital experience (Forrester), and 73 percent of younger decision makers belong to the generation that expects frictionless digital processes (Forrester). Anyone who fails to mirror orders, accounts and status cleanly between shop and ERP risks exactly that experience. But this is also where the danger lies: once two systems are allowed to write the same data field, the question is no longer whether but when the first conflict occurs. 61 percent (Bitkom, Digitalisation of the Economy 2025) of companies cannot fully exploit their data potential because information sits in unconnected systems.
Items and Prices
Originate in the ERP. If the shop writes back here, a spontaneous campaign quickly overwrites the calculated sales price.
Stock Levels
Belong in the ERP. If the shop reserves while the ERP posts a goods receipt at the same time, two figures collide on the same field.
Customer Master Data
Often originate in the shop. If accounting changes the billing address in parallel, it is unclear which version should apply.
Orders and Status
Come from the shop, the status travels back and forth - an ideal breeding ground for sync loops.
Payment Data
Payment method in the shop, incoming payment in the ERP: the reconciled status must come from exactly one direction.
Discounts and Promotions
Maintained temporarily in the shop, calculated permanently in the ERP - without an ownership rule they overwrite each other.
The Problem with Last-Write-Wins
The most obvious conflict resolution is last-write-wins: in a collision the chronologically most recent write simply wins, identified by its timestamp (coraltree-systems.de). For non-critical fields that may suffice, but as a general strategy it is risky. First, it assumes that the clocks of both systems run exactly in sync - even a few seconds of drift can let an older update overwrite a newer one. Second, last-write-wins treats all fields equally, even though a manually maintained sales price in the ERP has a completely different authority than an automatic stock report from the shop. Third, with every conflict one of the two changes is lost without comment - the loss often only surfaces when a customer sees a wrong price or an item has been sold twice.
The Silent Data Loss
Defining Field Ownership per Data Category
The viable alternative is a clear ownership rule: for each data category, exactly one leading system is defined that authoritatively owns that field (loskan.io). All other systems may read but not overwrite it. This is the core of the single-source-of-truth principle, applied not to entire systems but to individual data fields. Item master data, prices and stock typically belong in the ERP; customer accounts, carts and orders originate in the shop and are leading there. What matters is that this assignment is explicitly documented and technically enforced in the middleware instead of being left to the chance of ordering. With an online share of 13.5 percent of retail sales (HDE Online-Monitor 2026) and ever-growing write-back volumes, this explicit assignment is not a luxury but the basis of every reliable integration.
| Data Category | Leading System | Sync Direction |
|---|---|---|
| Item master data | ERP / Inventory | ERP → Shop |
| Prices and tiers | ERP | ERP → Shop |
| Stock levels | ERP | ERP → Shop |
| Customer accounts | Shop | Shop → ERP |
| Orders | Shop | Shop → ERP |
| Order status | ERP | ERP → Shop |
Single Source of Truth per Field, Not per System
A common misconception is to apply the single source of truth to entire systems - "the ERP is the truth" or "the shop owns the customers". In practice the ownership boundary runs finer, often right through a single record. For the customer master, for example, the shop maintains name, login and delivery address, while credit limit and payment terms come from the ERP. Both write the same customer record, but different fields. Ownership is therefore defined at field level, not at object level. Only this granularity prevents a harmless address update from the shop from overwriting the credit limit maintained in the ERP. That the investment pays off is clear from the scale of the risk alone: poor data quality amounts to an average of 12.9 million US dollars per year according to Gartner (Gartner).
Ownership Is a Field Property
Detecting and Breaking Sync Loops
The second major failure mode of bidirectional sync is the endless loop. It arises when system A reports a change to system B, B then updates the same record and reports this update back to A as a supposedly new change - whereupon A notifies B again. Without countermeasures, both systems circle in a growing number of updates, strain the interface and produce contradictory intermediate states. Such loops are especially treacherous in event-driven architectures because every webhook event can immediately trigger the next.
- Origin tagging: Every change carries its source. An update that originally came from the shop is not processed again in the shop.
- Echo suppression: The middleware remembers the last written value per field and ignores the incoming echo when it is identical.
- Correlation ID: Each synchronization receives a unique identifier that is carried across both systems and makes returning messages recognizable.
- Dirty flag instead of timestamp: Only fields that have actually changed in business terms are marked as worth updating, not every technical write.
- Change comparison before writing: If the incoming value does not differ from the stored one, the update is skipped - and the loop breaks.
Conflict Strategies Compared
Not every data category needs the same strategy. For fields with clear ownership the direction rule suffices; for rare cases of shared responsibility finer methods are needed. The following overview classifies the common approaches - from the simple but risky timestamp rule to field-based ownership, which also proves itself in real-time scenarios. Given that only 3 percent of company data reaches basic quality standards (Harvard Business Review), the deliberate choice of strategy is not a detail but a matter of principle.
| Strategy | How it decides | When it fits |
|---|---|---|
| Last-write-wins (timestamp) | Most recent write wins | Only non-critical fields with synchronized clocks |
| Field ownership (leading system) | The owner of the field always wins | Standard for items, prices, stock, customers |
| Version or change counter | Higher version wins, regardless of the clock | Distributed systems with clock drift |
| Merge | Non-colliding fields are combined | Records with shared field ownership |
| Manual resolution | Conflict is flagged for review | Rare, economically critical collisions |
A Clear Distinction: Neither MDM nor Retry
Conflict resolution is easily confused with two neighbouring topics that deserve their own treatment. The first is master data governance in the sense of master data management: it is about data quality, approval processes and the organizational upkeep of master data across the entire lifecycle - a layer above the technical sync. How an MDM organizes master data synchronization is a governance topic, not a pure conflict rule. The second is delivery reliability: idempotency and retry strategies ensure that a message delivered several times does not take effect several times and that a failed call is safely repeated. That prevents duplicates through technical repetition, but not the business conflict when two systems deliberately change the same field. Field ownership, MDM and idempotency interlock but solve different problems.
Implementation Step by Step
- Map the data flow: Capture every data category and record in which system it originates and where it flows. A clean data mapping between ERP and shop is the foundation.
- Define field ownership: Determine exactly one leading system per field and document the sync direction. Ambiguous fields are clarified with the business, not guessed technically.
- Enforce ownership in the middleware: The middleware only allows writes from the respective leading direction and rejects or logs opposing updates.
- Activate loop protection: Build in origin tagging, echo suppression and change comparison so that returning messages are not processed again.
- Log and monitor conflicts: Every rejected or resolved collision is logged and made visible through interface monitoring.
- Test with collision scenarios: Deliberately provoke simultaneous changes to the same fields and check that the ownership rule takes effect correctly before the integration goes live.
How robust this setup has to be becomes clear at the latest when a leading system is itself migrated. Anyone who, for example, migrates their shop interfaces because of the SAP ECC end of maintenance should have field ownership documented before the data flows are moved. And once the shop writes back reliably, customer services can be expanded, such as the live order status fed from the ERP in the B2B account - a benefit that would not be sustainable without a clean conflict rule. After all, 44 percent of B2B buyers have already switched supplier because of poor digital processes (Forrester), so conflict-free write-back is also a sales argument.
Bidirectional sync does not fail on the technology of transfer, but on the missing answer to a single question: who owns this field?