Stop double data entry without replacing your systems

A customer moves. The salesperson updates the address in the CRM. Accounts still has the old one in the ERP, and the delivery spreadsheet has a third version that someone typed in two years ago. Three tools, three versions, and nobody knows which one is right.

The temptation is to replace everything with one system that does it all. That is rarely the right first move. It’s a long, expensive project that makes the whole team change habits at once, and it can recreate the same problems in a brand-new tool. Most of the time, you get most of the benefit by connecting the tools you already have, one flow at a time, with a few clear rules.

One system of record per type of data

The first decision isn’t technical. For each type of information, decide which tool is the reference.

A simple rule: information belongs where it is created, or where it has legal weight. A customer’s contact details and sales history live in the CRM. Invoices, payments and payment terms live in the ERP or accounting software. IBM’s guide to CRM and ERP integration makes the same point: name the authoritative system for each type of data, and give someone ownership of keeping it up to date.

You can go further and think field by field. The billing address belongs to accounts; the contact’s phone number belongs to sales. Each field is edited in one tool only. The others read it, or receive a copy.

That decision settles most conflicts in advance. Without it, two tools syncing both ways end up overwriting each other.

Five ways to connect two tools

From the most solid to the most fragile.

1. The vendor’s own connector. Many tools ship ready-made links to common software. When one exists and covers your need, it’s usually the simplest option. Still check what it actually syncs, and in which direction.

2. APIs and webhooks. An API is the door a program uses to read or write in another tool. A webhook works the other way: the tool tells you when something changes. Microsoft presents its change notifications as the alternative to repeatedly polling its service, which can run into throttling limits.

3. An integration platform. Make, Zapier, n8n or Power Automate connect hundreds of tools without writing everything from scratch. It’s worth knowing how they notice a change. In Zapier, an “instant” trigger relies on a webhook, while a polling trigger checks at intervals: every 15 minutes on the Free plan, every 2 minutes on Professional and every minute on Team and Enterprise, according to its documentation. For a customer reminder, that doesn’t matter. For a stock alert, it might.

4. File import and export. A CSV export every evening, imported into the other tool. It’s basic, sometimes enough, and often the only option with older software. You then need a stable format and someone who checks that the import actually ran.

5. A robot that imitates a user. When a tool has no API and no import, a program can click and type in place of a person. It gets you out of a hole, but it’s the most fragile option: Microsoft itself says these automations often need maintenance when an application or web page changes its structure. Keep it as a last resort.

What about Excel? It’s often where everything starts, and it’s an awkward target. Microsoft’s Excel Online (Business) connector, for example, documents a 25 MB maximum file size, a file lock of up to 6 minutes after the connector last used it, and no support for simultaneous edits made by hand or by other connectors. A spreadsheet the whole team edits while an automation writes to it is a conflict waiting to happen. Let the automation write to a tool built for it, and use Excel for reading and analysis.

Before you connect anything

Three checks prevent most trouble.

A shared identifier. To know that “Martin Ltd” in the CRM is the same customer as “MARTIN” in the ERP, you need a common key: customer code, company number, email address, order number. Without one, every sync creates duplicates. Tools rely on these keys too: HubSpot, for instance, deduplicates contacts by email address and companies by domain name.

Clean data. If the CRM already holds three records for the same customer, the connection will copy all three. Deduplicate before, not after.

Field mapping. What does “Won” in the CRM correspond to in the ERP? Picklists, date formats, fields that are required on one side and optional on the other: settle all of this on paper before writing a single rule.

Add a volume question. APIs have limits. In HubSpot, a privately distributed app on the Free or Starter tier gets 100 calls per 10 seconds and 250,000 per day for the account; beyond that, every call returns an error. For a few hundred records a day, that’s plenty. For loading your whole history, you need a plan.

And a personal data question. Under the GDPR, personal data must be limited to what is necessary and kept accurate. In practice, only copy into a tool the fields it actually needs, and check who has access to them there.

Plan for failure

A sync will fail one day: a service down, a limit reached, an incomplete record. What matters is what happens then.

A few ground rules:

• A visible failure queue. Every error has to land somewhere someone will see it. In Make, for example, the feature that stores failed runs so they can be resolved later is disabled by default: you have to switch it on.
• Automatic retries, for temporary errors only. A service that is briefly unavailable? Retry. A record with no customer code? Retrying won’t help; a person needs to fix it.
• An alert, and a named owner. A flow nobody owns will stop one day without anyone noticing.
• A log of what was created, where and when. So you can answer “where did this record come from?”

What stays human, and when not to connect

Automations move information; people make the decisions. They keep the job of approving ambiguous or incomplete information, handling commercial exceptions, merging two records that might be the same customer, and anything that commits the company, such as accepting a job or issuing a credit note.

Sometimes it’s better not to connect at all:

• when one of the tools will be replaced within months;
• when volume is so low that retyping takes a few minutes a week;
• when the data is too messy: clean it first;
• when nobody will be able to look after the flow the day it breaks.

An example: job orders arriving by email

A transport or field-service company receives job orders by email. Each one is retyped into the schedule, the client file and then invoicing. A sensible flow looks like this: a dedicated inbox; reading the details, with a template per client when the format is stable; a record that a person approves; the client’s order number as the duplicate key; one entry in the tool that is the reference for jobs, then sending the details on to the others.

We’ve written this scenario up as a use case: Job orders received by email, entered only once. For a real project connecting a survey tool, the client file and a dashboard, see customer satisfaction tracked at every step.

One last piece of advice: start with the flow that costs you the most retyping each week, not the one that looks most impressive. If you’d like help finding it, tell us how information moves around today.

Sources

• IBM, CRM - ERP Integration (system of record per data type, ownership of updates).
• Microsoft Learn, Change notifications overview, Excel Online (Business) connector and AI-assisted UI automation repair.
• Zapier, How Zap triggers work (polling intervals by plan, checked in November 2026).
• HubSpot, API usage guidelines and limits and Deduplication of records, checked in November 2026.
• Make, Incomplete executions.
• GDPR, Article 5 (data minimisation and accuracy), EUR-Lex.