---
id: KB-IN-007
url: https://app.codecontract.io/help/integrations/keeping-two-systems-in-sync
idioma: en
categoria: integraciones
audiencia: desarrollador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-002, KB-IN-005]
citadoPor: [KB-IN-008]
---

# Keeping two systems in sync

_Which one wins when both hold the same value and they disagree._

**Responde a:** sync with erp duplicate data · which system owns a field · data does not match between systems · avoid duplicates when integrating

As soon as two systems store the same value, at some point they stop matching. That is not an integration fault: it always happens. What decides whether it hurts is having agreed beforehand which of the two owns each thing.

## The rule: one owner per field

Not "the ERP wins" or "the platform wins", but field by field. Each value has one place where it is edited, and the other only copies it.

| Value | Usual owner | Why |
| --- | --- | --- |
| Supplier tax details | Your ERP | It is where invoicing happens |
| Documentation status | The platform | It is where it arrives and gets approved |
| Contact for paperwork | The platform | It receives the notices and shows whether they bounce |
| Whether the supplier is active | Your ERP | It is a commercial decision, not a documentary one |

> [!IMPORTANT]
> Write that table before coding anything, even if it is four rows in a document. Integrations that become a problem do not fail technically: they fail because nobody agreed who owns what, and end up overwriting each other in a loop.

## What prevents duplicates

**En corto**

- Your own identifier on every contact, from day one.
- Search by that identifier before creating, always.
- Do not create records from both sides at once.

> [!WARNING]
> If your system creates a supplier whenever it cannot find one by name, you will end up with "Muñoz Engineering", "Muñoz Engineering Ltd" and "MUÑOZ ENGINEERING". Searching by identifier rather than name is what prevents it.

> [!NOTE]
> Start by syncing one way only. Bidirectional is where loops appear, and it is rarely needed at the start.

**What if both change at once?**

The field's owner wins. Which is why it has to be defined first.

**Can I sync only some suppliers?**

Yes, and it is a good way to test.

**How do I spot they have drifted apart?**

By comparing on the identifier occasionally. Without one, you cannot.

## Ejemplos

**An integration creates duplicate suppliers whenever the name arrives with a different comma.**

- Adds the tax identifier as the lookup key
- Searches on it before creating

→ Duplicates stop appearing and the 40 already there are merged without losing history.

**The supplier record is edited here and in the ERP, and each system holds a different version.**

- Decides which one is authoritative for each field
- The other system receives the change rather than editing it

→ There stop being two truths and nobody has to guess which one counts.

**Both systems are edited at once and the last write wins silently.**

- Locks editing where that field is not authoritative

→ The change is made in one place and propagates.

**The sync goes down over a weekend and nobody notices until Tuesday.**

- Sets an alert if activity stops arriving

→ The drift is caught in hours.

**Everything is synchronised when only four fields were needed.**

- Limits the sync to what is used

→ There is less to maintain and less to break.

**A field changes format in the ERP and the sync starts failing.**

- Validates the format before writing
- Returns the error to whoever generated it

→ The fault is fixed at source rather than carried along.