ERP integration without double entry: what actually gets synced

"We enter everything twice" is a sentence you hear in every company that runs more than one system. Goods are recorded in the ERP, then again in the shop. A customer is created in the CRM, then again in billing. Someone spends the day retyping what already exists in another system, makes mistakes, and then the two systems slowly drift apart. The natural reaction is: let us connect these so we do not type twice.

That is the right intention and the wrong diagnosis. Double entry is a symptom. The disease is that two systems both believe they own the same record — and as long as both think they are right, integration only speeds up the disagreement. Before anything is connected, one question must be answered for every piece of data: who owns it here.

Double entry is a symptom, not the disease

When two systems hold the same record and neither is declared authoritative, disagreement is not a possibility but a matter of time. Someone changes a price in the ERP and forgets the shop. Someone corrects a customer address in the shop, the ERP keeps shipping to the old one. Every such trifle is a place where the two systems quietly drift, and the drift goes unnoticed until it causes a wrong shipment or a wrong invoice.

Connecting without deciding ownership does not cure this — it automates the drift. If both systems are allowed to change the same price and both push it to the other, you have created a loop in which the last change overwrites the previous one, with nobody who knows which is correct. That is why the first step is not technical. The first step is to name, for each entity, a system of record — one system that is authoritative, while all the others merely read its value.

The system of record per entity

The mistake is looking for a "main system" for the whole company. There is no system that is best at everything. The ERP knows purchase prices and the main warehouse balance best; the shop knows the cart and customer behaviour best; the warehouse system knows where each pallet is best. Ownership is assigned per entity, not per system, and the result of that decision must exist written somewhere everyone can look at.

This table is not universal — for some the prices live in the shop, for some customers live in the ERP. The point is not which field goes where, but that for every field there is exactly one answer and that the answer is written down. Every field without a named owner is a future disagreement on a delayed timer.

Master and transactional data do not sync the same way

Everything that gets synced falls into two kinds, and mixing their rules is a frequent source of trouble. Master data is what stands still: items, customers, price lists. It changes rarely, holds for a long time, and syncs in one direction — from the owner to everyone who reads. Transactional data is what happens: orders, shipments, payments. It is created constantly, is "current" only briefly, and demands syncing per event.

Because of that, the item catalogue and the order status do not follow the same logic. The catalogue can be pushed once a day and nobody notices; if the order status lags an hour, the customer calls to ask where their goods are. When NG Commerce takes the catalogue from the ERP, that is a one-way master sync; when it sends the order back, that is a transactional event that tolerates no delay.

Direction of flow and the "last write wins" trap

When the owner is clear, the direction of flow is obvious: from the owner to the readers, never back. The problem arises with fields two systems are both allowed to change — and this is where the most dangerous apparent solution is born, the rule "last write wins".

It sounds reasonable: if a newer change arrives, it must be the correct one. But newer does not mean more correct. If a warehouse operator corrects a balance based on a physical count, and half an hour later an automatic import from an old report restores the wrong number, "last write wins" has just overwritten the only correct value with a newer wrong one. The conflict is not resolved — it is merely hidden under a timestamp.

Batch or real-time

Not everything has to be instant, and insisting that it is makes the integration more expensive with no benefit. The trick is to separate what genuinely must be real-time from what can go in batches, once every few hours or overnight.

• Genuinely real-time: stock for something that sells out fast, an order status the customer is tracking, reserving goods at the moment of purchase.
• Can go in batches: the item catalogue, descriptions, images, price lists that change rarely, historical reports.
• Depends on the business: prices, which are batch for a stable assortment and real-time for daily changes and promotions.

When NG Operations plans production from orders, and KickOff WMS keeps the physical balance, stock has to travel immediately while master data can wait for the nightly cycle. Putting everything in real time means paying for infrastructure that ninety percent of the data does not use.

Reconciliation: how you prove the systems agree

An integration that works today does not mean the systems will agree in a month. Messages get lost, jobs fail, someone slips in a manual change outside the integration. Without a regular check you do not know the systems agree — you only know that nobody has noticed yet that they disagree. Reconciliation is that check.

1. Compare the totals. Number of items, sum of balances, number of open orders — a quick signal that something is grossly off.
2. Compare line by line periodically. Not on every message, but on a scheduled cycle that finds the quiet drifts.
3. Record the differences, not just a count. Which item, which field, which value on each side — otherwise you know an error exists but not where.
4. Decide in advance what is authoritative. When a difference is found, the system of record for that field settles the dispute, without an argument every time.

The mapping table nobody wants

There is a part of every integration everyone wants to avoid and no one may: mapping codes. Units of measure, tax rates, item and partner codes are rarely the same in two systems. One says "pcs", another "pc.", a third "PCS". One holds the tax rate as a label, another as a percentage. That mapping table must exist, someone must own it, and it must be maintained when a new code appears.

A table without an owner rots. A new unit of measure appears, nobody adds it, and precisely the messages that use it start failing quietly — with nobody knowing why. That is why mapping is not a technical detail but a standing obligation that belongs to someone by name.

The same applies to go-live. Migration and the sequence of switching on are planned, not improvised: first align the catalogue and code lists, then reconcile balances at a single point in time, then switch on the transactional flow, and only then turn off the old double entry. If work like this lies ahead of you, look at how we approach integration or contact us with a list of the systems to connect — the decision about who owns the data is made before the first line of code.