ERP and CRM integration connects the system your sales team uses to win customers with the system your operations and finance teams use to deliver and bill them. The core flows are customer records, quotes becoming sales orders, credit limits and account status, and invoices and payments shown back in the CRM so salespeople see the whole account without asking finance.
When the two are not connected, the symptoms are familiar: customers entered twice with different spellings, salespeople promising delivery on stock that is gone, quotes re-keyed into the ERP with errors, and sales chasing accounts that are on credit hold. The fix is less about technology and more about agreeing who owns each piece of data. For the difference between the two systems in the first place, see ERP vs CRM.
If you are planning the integration, or a CRM built around your ERP, our ERP integration services and CRM development teams handle both sides.
What data should sync between ERP and CRM?
Sync what one team needs to see and the other team owns. In most businesses that is six flows.
| Flow | Direction | Trigger | Why it matters |
|---|---|---|---|
| Customer account (name, tax number, addresses, terms) | CRM to ERP at conversion; ERP to CRM after | Opportunity won or account approved | One customer record, one spelling, correct tax details on invoices |
| Contacts | CRM to ERP (billing contacts only) | Contact created or changed | Invoices reach the right person |
| Products and prices | ERP to CRM | Item or price list change | Quotes use current prices and valid items |
| Quote to sales order | CRM to ERP | Quote accepted | No re-keying; order matches what was sold |
| Order status and delivery | ERP to CRM | Order confirmed, shipped, invoiced | Sales can answer "where is my order?" |
| Credit limit, balance, overdue amount, hold status | ERP to CRM | Daily or on change | Sales knows before promising more |
| Invoices and payments | ERP to CRM (read-only summary) | Posted or paid | Account view for renewals and disputes |
What usually stays in one system: pipeline stages, activities and forecasts stay in the CRM; general ledger, costs, stock and payment allocations stay in the ERP.
Which system owns the customer record?
Split ownership by field, not by record. The CRM usually owns prospects and relationship data; the ERP owns anything that affects money or legal documents once someone becomes a customer.
A field ownership map, illustrative for a B2B distributor:
| Field | Owner | Editable in the other system? |
|---|---|---|
| Account name, industry, account manager | CRM | No |
| Legal name and tax registration number | ERP (finance validates) | No |
| Billing address | ERP | Request change via CRM, approved by finance |
| Delivery addresses | ERP | Request via CRM |
| Payment terms and credit limit | ERP | Never |
| Account status (active, on hold, closed) | ERP | Never |
| Marketing preferences | CRM | No |
The key rule: when a salesperson needs to change a field the ERP owns, the CRM creates a change request, not a direct edit. That request can follow an approval path; our approval workflow design guide covers how to set those up without slowing sales down.
How should a quote become a sales order?
The quote is built in the CRM using ERP prices and items, then becomes a sales order in the ERP when the customer accepts. The ERP validates stock, credit and pricing before confirming.
Checks the ERP should run when the order arrives:
- Customer exists and is active, not on credit hold
- Order value plus open balance stays within the credit limit, or the order goes to approval
- Every item is valid and saleable; discontinued items are rejected with a message back to the CRM
- Prices and discounts match the price list or an approved special price
- Requested delivery date is achievable against stock or production capacity
- Tax treatment matches the customer and delivery address
If a check fails, the order should come back to the CRM with a clear reason, and the quote should not silently disappear. Store the CRM quote ID on the ERP order so both sides can trace it. Agree, too, what happens when an order is amended after confirmation: whether changes are made in the ERP only, or whether the CRM quote is revised and resent, so the two records never tell different stories.
What sync patterns work best?
Use events for anything a person is waiting on (quote accepted, credit hold changed) and scheduled sync for summary data (balances, invoice history). Avoid two-way sync of the same field; it creates loops and overwrite fights.
| Pattern | Use for | Watch out for |
|---|---|---|
| Real-time API call | Quote to order, credit check during quoting | Timeout handling when the ERP is slow or down |
| Event or webhook | Status changes, new invoice, account hold | Duplicate and out-of-order events |
| Scheduled batch | Balances, ageing, invoice list | Staleness; show "as of" time in the CRM |
| Embedded view | Showing ERP invoices inside the CRM without copying them | Access rights and performance |
Whatever the pattern, keep an integration log that someone actually reads, and alert a named person when messages fail.
How do multi-currency and multi-entity setups change the design?
They add mapping rules that must be decided before any code is written. A customer group trading with several of your companies is one account in the CRM but may be several customers in the ERP, one per selling entity, each with its own currency, terms and credit limit.
Decisions to record:
- Which entity a quote is issued from, and whether the salesperson chooses it or a rule does (by country, product line or delivery address)
- Whether credit limits are per entity or for the whole customer group, and which figure the CRM shows
- The currency a quote is priced in, and whose exchange rate applies if prices are converted
- How a parent and child account structure in the CRM maps to bill-to and ship-to customers in the ERP
Get these wrong and orders land in the wrong company, which is expensive to unwind after invoicing.
An illustrative quote-to-cash flow
To show how the pieces fit together, here is an illustrative flow for a B2B supplier with an integrated CRM and ERP:
- A salesperson builds a quote in the CRM. Items and prices come from the ERP price list; a discount above the salesperson's limit triggers approval.
- While quoting, the CRM shows the customer's open balance, overdue amount and credit hold status from the ERP.
- The customer accepts. The CRM sends the quote to the ERP with its quote ID.
- The ERP checks credit, stock and prices. If all pass, it creates a confirmed sales order and returns the order number to the CRM.
- As the order is picked, shipped and invoiced, each status change appears on the CRM opportunity and account.
- When the customer pays, the ERP allocates the receipt and the CRM account view updates overnight with the new balance.
Nobody re-keys anything, sales can answer customer questions without emailing finance, and finance still controls credit, invoicing and cash.
What goes wrong most often?
The common failures are organisational, not technical. Most of them come from skipping the field ownership map or from launching without anyone responsible for data quality after go-live. Name a data owner for customer records on each side, and give them a weekly exception list to clear:
- Duplicate customers. Fix with a match rule (tax number, domain, postcode) before creating ERP accounts, and a merge procedure.
- Two-way edits on the same field. Pick one owner per field.
- Price drift. Salespeople quoting from old spreadsheets. Make the CRM price list read-only from the ERP.
- Hidden credit holds. Sales finds out after the customer complains. Show hold status prominently in the CRM.
- Multi-entity confusion. A group with several companies may hold one CRM account but several ERP customers. Decide the mapping early.
When is deep integration not worth it?
If you have a small team, a few dozen orders a month and finance sits next to sales, a nightly export and a shared dashboard may be enough. A deep integration also makes little sense if either system will be replaced soon, or if your CRM is barely used. In that case, fix CRM adoption first, or consider a CRM module inside the ERP so there is nothing to integrate. If the sales and finance numbers you need are mainly reporting, see ERP reports every finance team needs and ERP e-commerce integration for channel orders.
How to start your ERP and CRM integration
Prepare these before you talk to any integrator:
- The flows table above, marked with what you need now and what can wait.
- A field ownership map for customer records.
- Your quote-to-order rules: who approves discounts and credit overrides.
- Volumes: accounts, quotes and orders per month.
- Which CRM and ERP you use, with versions and whether either is custom.
The software requirements brief template helps you turn this into a scope. When you are ready, discuss the project with us. We build 2 to 3 key modules as a free pilot before the full project, typically the customer sync and quote-to-order flow, so you can test it with real users.