CRM and ERP integration is almost always described as a connection problem, and it is almost never a connection problem. Both systems have documented interfaces. Both have connectors available. The difficulty is that sales and finance have spent years describing the same business in two different vocabularies, and the integration is where those vocabularies are forced to agree.

The moment somebody asks whether a lead that has been converted twice should create one account or two, the project stops being technical. That conversation, repeated across thirty fields, is the actual work.

Start here: Before choosing a connector or a platform, write down which system owns each shared field and what happens when both are edited. Integrations that skip this step get built quickly and then spend years producing duplicate records, mismatched totals and reports that nobody trusts.

Why CRM and ERP Data Never Quite Lines Up

The two systems were designed for different purposes, and their data models reflect that honestly.

A CRM is built around the pursuit of revenue. Its central objects are people, opportunities and activities, and it tolerates imprecision because a half-known prospect is still worth recording. An ERP is built around the recording of obligations. Its central objects are accounts, orders, invoices and ledgers, and it tolerates nothing, because its output has to reconcile.

The consequences show up immediately. A single organisation is one account in the CRM and three customer records in the ERP, because it buys through three subsidiaries with different payment terms. A quantity of “one” means one licence in the CRM and one line item of twelve monthly charges in the ERP. A quote total calculated by the sales team differs from the invoice total by a few pounds, because tax and rounding live in the finance system and were approximated in the other.

None of these are defects. They are two correct models of the same business. Integration means deciding, field by field, which model wins, and that decision requires people from both departments in the same room. Any vendor who proposes to start building before that has happened is deferring the hardest part until it is most expensive to change.

The Four Integration Methods

There are only four approaches in common use, and the right one depends mostly on how many systems you have and how much money is on the line.

Point-to-point. You write a direct connection between the two systems. This is the fastest and cheapest option for a single pairing, and it works perfectly well when you genuinely only have two systems. The problem arrives with the third. Each new system multiplies the number of connections, and a landscape of six systems joined this way becomes impossible to change safely.

Integration platform. A hosted middleware product sits between your systems and provides pre-built connectors, mapping tools, retry handling and monitoring. It removes a large amount of undifferentiated work and gives non-developers visibility into what is flowing. The trade-offs are licence cost that scales with volume, limits on how far the pre-built connectors can be bent to fit unusual requirements, and a new vendor dependency in a critical path.

Buses and Batch Exchange

Message bus or event-driven. Systems publish events and interested parties subscribe. This suits larger landscapes, gives you a natural audit trail and decouples systems so that one being unavailable does not stall the others. It requires more engineering maturity than the alternatives, and it is over-engineered for a company connecting exactly two systems.

Scheduled file exchange. Unfashionable, still widespread, and sometimes correct. Nightly extracts and imports are simple, auditable and easy to reprocess. They are entirely appropriate for finance data that is reconciled daily anyway, and entirely inappropriate for anything a salesperson expects to see immediately after saving.

Most mid-sized companies are best served by a platform for the routine flows and a small amount of custom code for the two or three cases the platform handles badly. Purity in either direction tends to cost more than the mixture.

Deciding Who Owns What

Master data ownership is the decision that determines whether the integration succeeds, so make it explicitly and write it down.

The workable pattern is single ownership per field rather than per record. Sales owns the contact name, the phone number and the opportunity stage. Finance owns the credit limit, the payment terms, the invoice address and anything that appears in the ledger. Each field flows in one direction only, and the receiving system displays it read-only so that nobody wastes time editing a value that will be overwritten tonight.

Read-only fields in a user interface are unpopular and they are still the right answer. The alternative is two people editing the same value in two places, both convinced they are correct, and a synchronisation process quietly discarding one of them.

Identity matching deserves its own attention. The two systems will not share an identifier at the start, so something has to decide that “Acme Ltd” in one is “ACME LIMITED” in the other. Fuzzy matching on name, postcode and registration number gets you most of the way, and the remainder needs human review. Build that review queue deliberately, because the alternative is automatic matching that silently merges two genuinely different customers, which is far harder to unpick than a backlog.

Once matched, store the cross-reference. A mapping table holding both identifiers, maintained by the integration itself, is worth more than any amount of re-matching logic.

What Actually Goes Wrong

The failure patterns are consistent enough to plan around.

Duplicates multiply quietly. A record created in one system arrives in the other, is created there, and syncs back as new. Without cross-reference storage and idempotent handling, one customer becomes four over a weekend. This is the single most common integration defect in this category.

SaaS platforms enforce limits you did not budget for. Cloud CRM and ERP products cap the number of API calls per period, and those caps are tied to your licence tier rather than your needs. An integration designed around per-record calls will exhaust the allowance during month-end, exactly when it matters. Use bulk interfaces for volume, batch where possible, and calculate expected call counts before building rather than after the first failure.

Customisation drifts. Someone adds a required custom field in the CRM on Tuesday, and the integration starts rejecting records on Wednesday because it does not populate it. Change control that covers both systems and the integration between them is unglamorous and prevents most of these incidents.

Problems That Surface After Go-Live

Sandboxes lie and then get refreshed. Test environments are frequently copies taken months ago, with different configuration and different data volumes. Worse, a sandbox refresh often wipes integration configuration, which teams discover mid-test. Document the rebuild procedure the first time.

Timing produces phantom problems. If the CRM syncs immediately and the ERP nightly, a salesperson will report an “error” that is simply the delay. Agree the latency for each flow, state it plainly to the users, and show a last-updated timestamp in the interface. Most complaints about integrations are complaints about unexplained lag.

Vendor upgrades break connectors. Both platforms update on their own schedule, and managed packages occasionally change behaviour. Subscribe to deprecation notices for both, and keep a maintenance allocation for the work they generate. The broader patterns here apply to any external system, and our guide to third-party API integration covers the engineering practices that contain them.

What CRM and ERP Integration Costs

Costs vary enormously with the number of objects in scope, so the useful framing is by ambition rather than by system.

A single-direction flow covering one object, such as pushing closed opportunities into the ERP as sales orders, typically runs from £8,000 to £20,000 including mapping, error handling and testing. Two-way synchronisation of accounts and contacts, with matching and a review queue, commonly lands between £25,000 and £60,000. A full landscape integration spanning accounts, contacts, products, pricing, orders, invoices and payments is a programme rather than a project, frequently starting around £75,000 and rising with the number of custom objects involved.

Add platform licensing if you use middleware, which is usually priced by volume or connector count and becomes a permanent operating cost. Add ten to twenty per cent of the build cost annually for maintenance, because both vendors will keep changing their products.

The saving that matters is not in the build. It is in restricting scope. Most organisations that integrate everything discover that a third of the flows are never used, and each one still needs maintaining. Start with the two or three flows that remove real manual effort, prove them, then extend. Our custom software development cost guide covers how this fits into a wider budget, and our build versus buy guide is worth reading first if you are still choosing the systems themselves.

Making It Survive Contact With Reality

A durable integration is defined by its operational qualities rather than its features.

Every flow should be observable, meaning somebody can answer “did this order reach the ERP?” in under a minute without database access. Failed records should land in a queue where they can be corrected and replayed, not disappear into a log. Alerts should reach a person who is accountable, and they should distinguish between a transient failure and a genuine data problem.

Above all, there should be a reconciliation routine that compares counts and totals between the systems on a schedule and reports differences. Finance will build one informally if you do not build one formally, and their version will be a spreadsheet.

Get Your Systems Talking Properly

Mecanik delivers CRM and ERP integration work as part of our custom software development services . We start with the ownership map rather than the connector, because that is where the arguments live and where the cost is decided.

We build the matching logic, the cross-reference store, the replay queue and the reconciliation job as standard, and we are happy to work with whatever middleware you already license rather than insisting on a particular platform. If your integration is part of a wider growth programme, our e-commerce scaling playbook covers how these systems fit together as order volume increases.

Tell us which two systems you are joining and which three things you want to stop doing manually, and we will scope it from there.

Related reading: Software Licensing Models: An Enterprise Guide 2026 , AI Integration for UK SMEs - A Practical Guide for 2026 , OpenAI API Integration: Adding GPT to an Existing App and Medical & Healthcare Website Development UK 2026 .

Frequently Asked Questions

How long does CRM and ERP integration take? A single one-way flow typically takes three to six weeks including mapping and testing. Two-way synchronisation of accounts and contacts usually takes two to four months, largely because identity matching and ownership decisions require input from both sales and finance teams.

What is the most common CRM and ERP integration mistake? Failing to decide which system owns each field before building. Without that decision, both systems keep editing the same values, the synchronisation overwrites changes unpredictably, and users lose confidence in the data within weeks of go-live.

Do I need an integration platform or custom code? Most mid-sized organisations use a platform for routine flows and a small amount of custom code for the cases the connectors handle badly. Custom code alone is reasonable for exactly two systems, while a platform earns its licence cost once you have four or more.

Why do duplicate records appear after integration? Usually because there is no stored cross-reference between the two systems’ identifiers, so a record created in one is re-imported as new when it syncs back. Store both identifiers in a mapping table and make every handler idempotent.

How much should I budget for ongoing integration maintenance? Plan for ten to twenty per cent of the original build cost each year. Both vendors update their platforms independently, connectors get deprecated, and configuration changes made in either system can break flows that worked the day before.