What Two-Way ERP Sync Actually Means

The most common misunderstanding in integration conversations is that two systems being connected means data flows in both directions. In plenty of installations the connection exists but runs one way: the ERP pushes data to the portal, and the portal tells the ERP nothing.

That distinction is not a technical footnote. It is the decision that determines what daily operations will feel like.

The quiet cost of a one-way setup

The portal takes the order, somebody downloads it as a PDF, and somebody keys it into the ERP. The order channel looks digitized, but the data entry has only moved, and now there are two order numbers in two places. When a line is corrected, which one is right becomes a matter of opinion, and that opinion always surfaces at the moment of shipping.

What flows from the ERP to the portal

Product records and technical attributes, price lists and discount definitions, stock quantities, account balances and open invoices, shipment and invoice status. What these have in common is that the ERP is where their truth is produced. The portal displays them; it does not calculate them, correct them, or keep a version of its own.

What flows from the portal to the ERP

Order headers and lines, the collection record from a dealer's virtual POS transaction, quotes approved through quote management, and the outcome of dealer user requests. On this side what matters is that the record reaches the ERP at the moment the order is placed, and exactly once.

Who wins a conflict

Every field needs a single owner. If the ERP owns price, then a price typed into the portal by hand is overwritten at the next sync, and that is the correct behavior. Where ownership is not written down, the two systems take turns overwriting each other, and the result is not data loss but something worse: a quiet drift nobody notices.

A latency budget

"Real time" is a cost, not a requirement. Stock quantities need refreshing on the order of minutes; a product description is fine once a day; the gap between a collection and the account balance should be short, because it directly determines whether a dealer can place their next order. Setting a latency budget per field is both cheaper and healthier than one blanket decision that everything must be instant.

When the connection drops

The portal does not have to stop when the ERP goes down for maintenance or the link fails. Outbound records wait in a queue and are processed in order when the link returns, and every message carries a unique identifier so the same record is never processed twice. There is one more piece nobody should skip: an end-of-day report comparing order and collection counts on both sides. The queue prevents errors; the reconciliation report makes visible the ones that could not be prevented.

The one question to ask

Evaluating an integration proposal, the question that separates the serious answers from the rest is this: which field moves in which direction, how often, and which side wins a conflict? If the answers do not fit in a table, the integration has not been designed yet.