Syncing data between systems: one source, no duplicate work
The same customer details are in your CRM, your accounting system and your email tool. A change of address means updating three times, and sooner or later someone forgets one. Syncing data between systems solves that: you change something once and it is correct everywhere. But synchronisation only works if it is first clear which system holds the truth. That is where it starts.
What is syncing data between systems?
Syncing data means that the same data stays identical in multiple systems automatically. If something changes in system A, that change is passed on to system B, without anyone retyping anything.
That can be one-way or two-way. With one-way sync, one system is the source and the others are copies. With two-way sync, changes can originate on both sides and are sent to each other. That sounds more flexible, but it calls for rules: what happens if the same field changes on both sides at the same time? Where possible, we choose one-way sync per data type. That is simpler to build and to check.
Why does synchronisation start with a single source of truth?
Without a fixed source, nobody knows which figure is correct. Sales sees a different revenue in the CRM from finance in the accounting system, and a separate spreadsheet gives yet another number. Meetings are then about which data is correct instead of about what you do with it.
A single source of truth means that for each type of data, one system is leading. All other places are derivatives. An example of such a division:
- Customer and contact details: the CRM
- Invoices and payments: the accounting package
- Stock and product data: the ERP or PIM
- Hours and planning: the project tool
That division is a decision, not a technical setting. Record it, share it with the team and build the integrations on it. If you distribute product data across many channels, that source is often placed in a separate PIM system.
How does duplicate data actually arise?
Almost never through a deliberate choice. It grows. A company starts with a spreadsheet, adopts a CRM, later a separate invoicing package, and nobody decides which system is leading. Departments choose their own tools. It is quicker to put something in your own list than in the central system. And as soon as the central system is wrong once, people start keeping their own records, which makes the central system even less accurate.
The consequences are familiar: invoices sent to an old address, orders processed twice, quotes with an outdated price and hours lost working out which version is correct.
How do you approach syncing data step by step?
You build a reliable synchronisation in fixed steps.
1. Determine the source per data type
Make the division as described above explicit. Only then do you know which way the data needs to flow.
2. Map the fields
In the CRM it is called a company, in the accounting system a debtor, in the email tool a contact. Fields have different names and different formats. A field mapping records which field in system A corresponds to which field in system B, and which conversion is needed.
3. Choose the speed
Does a change need to be everywhere within seconds, or is every fifteen minutes enough? That determines how complex the integration becomes. We go into this in more depth when comparing real-time synchronisation with batch.
4. Build the integration
We build simple synchronisations with Make or Zapier. For situations with custom logic, large volumes or multiple systems, we use our own intermediate layer, for example in Supabase or Xano. Which route fits depends on the systems and the volume, not on a fixed preference.
5. Clean up existing data and link records
Your systems have been running for years. A customer in the CRM has to be matched with the same customer in the accounting system, usually on email address or customer number. Duplicates and old records are removed before the synchronisation starts. This step is often underestimated and regularly takes more time than the integration itself.
6. Monitor
A synchronisation is never a case of set and forget. Systems are updated and APIs change. Set up notifications for errors and periodically check whether the data still matches.
What does that look like in practice?
Take a company with a webshop, a CRM and an email tool. Customers change their address in the webshop, sales works in the CRM and marketing sends emails from the email tool. Without synchronisation, sales knows nothing about the new address and marketing emails an outdated profile.
The solution: the webshop is the source for customer details, because that is where customers manage their own details. Changes go automatically to the CRM and from there to the email tool. Sales can add notes and appointments in the CRM, but the basic details are not overwritten. One version of the customer, identical everywhere.
We see the same pattern at manufacturers where product data from the ERP needs to reach the website, dealers and marketing material. A central source with integrations to every channel is often the basis of a data management system there.
What determines the scope of a synchronisation project?
No two integrations are the same. The effort depends mainly on:
- the number of systems and the direction of the data
- the quality of the APIs on both sides
- how much data needs to be translated or merged
- the required speed
- the state of the existing data
- the requirements for logging and error handling
An integration between two systems with a handful of fields in one direction is manageable. A synchronisation between four systems with two-way traffic and historical clean-up is a project in its own right.
Technology helps, agreements decide
The best integration does not help if people keep working in the wrong system. Where possible, restrict write access in systems that are not a source, clear out parallel spreadsheets and build reports on the source systems instead of on copies. Then the data stays correct.
Want to know what this looks like for your systems? See our approach to system integrations or get in touch.
