A reliable CRM and ERP integration starts with a clear answer to one question: which system is allowed to create and change each important piece of data?
In most organisations, the CRM should own prospects, sales activity, opportunities and relationship history. The ERP should usually own financially controlled data such as customer account codes, products, stock, approved orders, invoices and payment status. The integration should then show each team the information it needs without letting both systems compete to update the same field.
That is a starting pattern, not a universal rule. Your order process, finance controls and customer journey should determine the final design. Vivato builds bespoke and semi-bespoke CRM systems for UK organisations, and the strongest integration specifications make those decisions before anyone chooses a connector or writes code.
What does data ownership mean in a CRM and ERP integration?
Data ownership means naming the authoritative system for a field or business event. If two systems disagree, the authoritative system wins.
This is sometimes described as choosing a “system of record” or “source of truth”. Those phrases can be misleading when applied to an entire customer. A customer is not one indivisible record. It contains identity, contact, commercial, operational and financial data that may have different owners.
For example, a salesperson might create an organisation and contact in CRM. When the opportunity becomes an order, the ERP may create the formal customer account and return its account number to CRM. Sales can still maintain relationship notes in CRM, while finance controls credit status and invoice addresses in ERP.
Microsoft’s integration guidance reflects this need for scenario-specific choices. It distinguishes between synchronous and asynchronous patterns and notes that shared entities can support two-way integration, while virtualised approaches can make data available without storing it in both systems.
Which data should CRM and ERP usually own?
Use the following table as a workshop starting point. “Own” means create or authoritatively update, while “view” means display a controlled copy or live result from the owning system.
| Data or event | Usual owner | Other system's role | Questions to resolve |
|---|---|---|---|
| Leads and unqualified prospects | CRM | Usually none | When does a prospect become a finance customer? |
| Contact details and sales preferences | CRM | View where operationally necessary | Which changes require validation or consent controls? |
| Legal customer account and account code | ERP | Store the ERP identifier and view status | Can sales request creation, or can CRM create it automatically? |
| Opportunities and sales activity | CRM | View only if needed for forecasting or fulfilment | What event marks an opportunity as won? |
| Product codes, tax treatment and standard prices | ERP or product system | CRM uses approved data for quoting | Can sales apply discounts, and who approves exceptions? |
| Quote | CRM, CPQ or ERP, depending on complexity | Receive the approved version | At what stage are price and availability revalidated? |
| Confirmed sales order | ERP | CRM shows fulfilment progress | Can an accepted quote be amended, cancelled or resubmitted? |
| Stock and availability | ERP | CRM displays current or cached values | How current must the figure be when a promise is made? |
| Invoice, credit note and payment status | ERP | CRM displays a relevant summary | Which roles may see balances or payment details? |
| Service case and relationship history | CRM or service platform | ERP receives operational outcomes only when needed | Does a case trigger a return, credit or replacement? |
The correct answer may differ. A manufacturing business with configurable products may create the quote in a specialist configurator. A membership organisation may manage renewals in CRM but post invoices to an accounting platform. A field service business may need an operational system between CRM and ERP.
The aim is not to make CRM dominant. It is to give each data item one clear authority and each workflow a traceable handover.
Why do integrations fail when both systems can edit the same data?
Uncontrolled two-way synchronisation creates ambiguity. A user corrects an address in CRM, finance changes it in ERP, and the next sync overwrites one version. Similar conflicts can affect prices, order status, credit limits and contact details.
The visible symptom is “bad data”, but the underlying problem is usually an undefined business rule. Common consequences include:
- duplicate customer accounts because the matching rule is weak;
- approved values being overwritten by an older update;
- automations firing twice when each system treats the other’s update as a new event;
- orders entering fulfilment before all mandatory information is present;
- silent failures that leave sales and finance looking at different states; and
- excessive personal data being copied into systems that do not need it.
The last point has a compliance dimension. The Information Commissioner’s Office says personal data should be adequate, relevant and limited to what is necessary for its purpose. A CRM and ERP integration should therefore transfer the fields needed for a defined process, rather than copying every available field “just in case”.
What should be decided before CRM and ERP development begins?
Vivato recommends resolving seven areas during discovery and software project scoping before estimating the final integration.
1. Map the business events
Start with meaningful events, not databases. Examples include “lead qualified”, “customer approved”, “quote accepted”, “order released”, “invoice posted” and “payment received”. For each event, document who acts, what must be true and what the next system needs.
This reveals where the workflow crosses a system boundary and where an integration should trigger an action rather than merely copy data.
2. Assign authority at field level
Create a data ownership matrix covering important fields, not just broad entities. One system may own the customer name while another owns credit status. State whether the receiving system can display, propose, create or update each value.
3. Choose stable identifiers and matching rules
Names and email addresses change and are rarely reliable integration keys. Decide how the CRM record, ERP account and any site, contact or order records will be linked. Store cross-system identifiers so that an update can find the correct record without fuzzy matching.
Also define what happens when no match or several possible matches are found. Sending these cases to a review queue is often safer than guessing.
4. Set the direction and timing of each data flow
Not every field needs real-time, two-way synchronisation. Choose among:
- a live lookup when a user needs current information but no local copy;
- an event-driven update when a business event must move the process on quickly;
- a scheduled batch for less urgent or high-volume data; and
- a one-off migration for historical information that will not continue changing.
“Real time” should be a measurable requirement, such as an accepted order reaching ERP within two minutes, rather than a general aspiration.
5. Define validation and transformation rules
CRM and ERP may represent the same concept differently. One may allow free-text countries while the other requires codes. One may hold a single address while the other distinguishes billing, shipping and site addresses.
Specify required fields, permitted values, formats, rounding, currency and tax rules. Decide whether invalid data is rejected, corrected automatically or held for review.
6. Design for failures and reconciliation
An integration is an operational service, not a one-off technical task. Specify retries, duplicate protection, alert ownership and an audit trail. Users need to know whether an order is pending, accepted or failed, and support teams need enough context to resolve the problem.
Reconciliation should compare business outcomes as well as record counts. For example, confirm that every CRM order marked as submitted has one corresponding ERP order, the same total value and an expected status.
7. Apply proportionate security and data controls
The UK National Cyber Security Centre recommends robust API authentication and authorisation, least privilege, permission checks and protection for data in transit. Your specification should cover service identities, access scope, secrets management, logging and monitoring, as well as the fields being exchanged.
Retain integration logs long enough to investigate problems, but avoid putting unnecessary personal or sensitive data into them. Define who can see financial summaries in CRM and how leavers or role changes affect access.
Should the integration be one-way or two-way?
Prefer one-way ownership unless users have a genuine need to update the same concept from both systems. A two-way integration can be appropriate, but every bidirectional field needs conflict rules, loop prevention and clear behaviour during outages.
Ask four questions before making a flow two-way:
- Which users need to change the value in each system?
- Can one system present the other system’s value without storing an editable copy?
- If changes happen at the same time, which update wins?
- What happens when one system is unavailable?
Two-way synchronisation is a business commitment as much as a technical feature. It expands testing, monitoring and support effort throughout the life of the integration.
When is a standard connector enough?
A standard connector is often suitable when your process follows the products’ expected data model, the required entities are supported and modest delays are acceptable. It can be the quickest and lowest-risk option.
A configured or semi-bespoke integration may be better when mappings, triggers and approvals need adjustment but the standard APIs still support the workflow. Bespoke development becomes more credible when you have specialist quoting, several operational systems, unusual entity relationships, high transaction volumes or strict recovery and audit requirements.
Do not choose bespoke integration merely because the business has bespoke terminology. First test whether configuration, an integration platform or a small workflow change can meet the requirement. Conversely, do not force a critical process through a connector that cannot express its states, controls or exception paths.
Vivato’s API and third-party integration service covers design, data mapping, authentication, error recovery and ongoing compatibility. For organisations considering a broader operational platform, our CRM and ERP development capability can bring customer, order and fulfilment workflows into one coherent design.
What should you ask a CRM integration supplier?
Before approving a proposal, ask the supplier to explain:
- which system owns every important field and event;
- how records are matched and duplicate creation is prevented;
- which flows are live, event-driven, scheduled or manual;
- how changed and deleted records are handled;
- what users see when a transaction is pending or fails;
- how retries avoid creating duplicate orders or invoices;
- how the integration is authenticated, authorised, logged and monitored;
- how releases and third-party API changes will be tested; and
- who supports the integration after launch and what evidence is available during an incident.
A credible answer should describe the operational behaviour, not just name a connector or API.
Frequently asked questions
Can CRM be the single source of truth for all customer data?
CRM can be the main view for sales and service users without owning every underlying value. It may display invoice status, credit information and fulfilment progress supplied by ERP while continuing to own relationship activity and opportunities. A useful single customer view does not require unrestricted editing in one database.
Should invoices be copied into CRM?
Usually, CRM users need a summary such as invoice number, date, value, due date and status rather than a complete accounting record. A live view or limited synchronised dataset may meet the need with less duplication. Finance requirements and access controls should determine the design.
How early should we involve finance and operations?
Involve them during discovery, before choosing the integration pattern. Sales can describe the customer journey, but finance and operations often own customer approval, pricing, tax, stock, order release and invoice rules. Leaving those rules until testing commonly exposes missing states and exceptions late in the project.
Make ownership the first integration deliverable
CRM and ERP integration is easier to estimate, test and support when every critical field and event has a named authority. Begin with the customer-to-cash workflow, document the handovers and decide what each role needs to view or change. Only then choose between a native connector, configured integration, integration platform or bespoke development.
If your current CRM and ERP disagree, or your teams rely on rekeying and spreadsheets between them, Vivato can help map the workflow and assess the smallest credible integration approach. The first conversation can focus on the process and its exceptions, without assuming that a bespoke build is the answer.
