CRM and ERP integration for distributors: who owns the customer, the quote and the order?
Which system owns each customer, contact, quote and order record, how an accepted CRM quote becomes one ERP order, which ERP facts sales reps need in the CRM, and ten tests to run before go-live.
- 01Prospect
- 02Quote
- 03Order
- 04Invoice
- 05Reorder
CRM and ERP integration works when each record has one owner. The CRM owns prospects, contacts, opportunities and sales activity. The ERP owns the approved customer account, prices, stock, credit, orders, invoices and balances. Connect them at three points: a prospect becoming a customer, an accepted quote becoming an ERP order, and ERP order, credit and buying history flowing back to the rep. Match records by the ERP customer number, never by name.
A sales rep at a distributor quotes a contractor, wins the order and hears nothing more. Two weeks later the customer calls the rep, angry: the order sat on credit hold, half of it is on backorder and an invoice is overdue. All of that was in the ERP. None of it was in the CRM the rep works from. Meanwhile customer service keyed the order a second time from the emailed quote, at last month’s price. This guide maps the records a distributor’s CRM and ERP share, who owns each one, and how to prove the connection works.
What does CRM and ERP integration connect?
A CRM (customer relationship management system) is where sales teams track prospects, contacts, opportunities, visits and calls. An ERP (enterprise resource planning system) is where the business records what it sells and what it is owed: customer accounts, prices, stock, orders, shipments, invoices and payments. CRM and ERP integration moves the records each side needs from the other, so that a rep and the back office describe the same customer the same way.
For a distributor, the connection is not a data copy for its own sake. It decides three practical things: whether a won quote becomes an order without being typed again, whether a rep knows that an account is on hold before promising a delivery, and whether the CRM can show what each customer actually buys so reps notice when a product line goes quiet. This guide is for wholesalers and distributors that sell through reps and inside sales and already run an ERP. Choosing the ERP itself is covered in the distribution ERP software guide.
Which system owns the customer, the quote and the order?
Most CRM and ERP problems start with two systems that can both edit the same record. Give each record one owner, the system where it is created and corrected, and let the other system display it or ask for a change.
| Record | Owner | What the other system does | Rule at the boundary |
|---|---|---|---|
| Lead and prospect | CRM | ERP has no record yet | A prospect only reaches the ERP through an approved account request. |
| Customer account: legal name, tax ID, bill-to, terms, credit limit | ERP (finance) | CRM displays it and can request changes | The ERP customer number is written back to the CRM account and used as the match key. |
| Ship-to locations | ERP | CRM displays them for visit planning | New sites are requested from the CRM and created in the ERP. |
| Contacts, roles and marketing consent | CRM | ERP receives only the contacts it needs, such as the accounts payable email | Agree which contact fields finance owns, so an invoice email is not overwritten from the CRM. |
| Opportunities, visits and calls | CRM | Not sent to the ERP | — |
| Items, customer prices and stock | ERP | CRM reads them for quoting | Reps quote from ERP prices and see the date the stock figure was taken. |
| Quote | CRM or ERP; choose one | The other side shows its status | Decide by where pricing rules and margin data live (see below). |
| Sales order, shipments and backorders | ERP | CRM shows status and history | Created in the ERP from the accepted quote, with the quote ID kept on the order. |
| Invoices, payments and balance | ERP | CRM shows open balance, overdue amount and hold status | Reps see credit position; they never change it. |
| Sales history and margin | ERP | CRM shows a summary by product line, with margin by role | Summarised nightly; not copied line by line. |
Should quotes live in the CRM or the ERP?
Quote in the CRM when reps need to work offline or on the road, quotes are mostly standard items at list or price-group prices, and the opportunity pipeline matters to management. Quote in the ERP when prices depend on cost, rebates, supplier special pricing, freight or project terms that only the ERP can calculate, or when quotes routinely turn into orders with many lines. In that case the CRM shows the ERP quote’s number, value, status and expiry against the opportunity. Avoid building the same pricing rules in both systems. They drift apart within months, and the customer receives an invoice that does not match the quote.
How should a CRM quote become an ERP order?
The illustrative case below is a plumbing and heating distributor. A rep quotes six lines to a mechanical contractor that is not yet a customer. The contractor accepts four lines with its purchase order 44120, and the order has to pass a credit check before anything ships.
- 01Price the quoteRep in the CRM, using ERP prices
Quote Q-3318 revision 2, six lines, price group, validity date, stock as of quote time
- 02Approve a margin below the floorSales manager in the CRM
Approver, approved lines and the reason
- 03Open the customer accountFinance in the ERP
Credit application approved; customer C-5120 with terms and limit; number written back to the CRM
- 04Create the order from the accepted linesERP
SO-60231 with PO 44120, four lines at quoted prices, quote ID and revision
- 05Release or holdERP credit check
Released, or held with a reason; status sent to the CRM opportunity and the rep
- 06Ship, invoice and close the opportunityERP, then CRM
Shipments, backorders and invoice; opportunity marked won at the invoiced value
Write down the quote rules before building the connection. They are business decisions, and the integration only enforces them:
| Situation | Rule to agree | Why it matters |
|---|---|---|
| Customer accepts some lines | Create the order for accepted lines; close or keep the rest open on the quote | Otherwise reps rekey a new quote and the history breaks. |
| Price changed after the quote | The quoted price stands until the validity date, then the ERP reprices and the rep is told | The invoice matches what the customer accepted. |
| Stock was available at quote time but is not now | Quotes do not reserve stock unless agreed; the order shows a backorder date | The rep sees the backorder before the customer does. |
| Quote edited after acceptance | Any edit creates a new revision; the order keeps the revision it came from | Nobody argues later about which version was accepted. |
| The conversion message is retried | The ERP checks the quote ID and revision before it creates an order | One accepted quote cannot become two orders. |
| The prospect is not yet a customer | The order waits until finance approves the account | Goods do not ship on terms nobody granted. |
The same order then follows the rest of the order-to-cash path, from release through dispatch and invoice. The order-to-cash guide sets out those handoffs and owners.
What ERP data should sales reps see in the CRM?
Reps need enough of the ERP to answer the customer and plan their next call, not a second copy of the ledger. The most useful view is order history summarised by product line or category, with the last purchase date and the usual buying interval. That is what shows a rep that a customer still buys pipe but stopped buying valves three months ago, which is often the first sign that a competitor has won a line.
Some ERP events should also create a task, not just update a field. A rep who learns about a credit hold from the customer has already lost the conversation.
| ERP event | CRM update | Who acts |
|---|---|---|
| Order placed on credit hold | Hold reason on the account and the opportunity; task for the account owner | Rep and credit controller agree what to tell the customer. |
| Line backordered beyond the promised date | Backorder line and new date on the account | Rep or inside sales offers a substitute or a split delivery. |
| Invoice overdue past an agreed number of days | Overdue amount and age on the account | Rep knows before the next visit; finance still owns collection. |
| Customer stops buying a product line it usually buys | Flag on the account with the line and the last purchase date | Rep calls before the customer’s next order goes elsewhere. |
| Quote reaches its expiry date | Task to follow up or re-issue | Rep. |
| Return or credit note raised | Return reason and value on the account | Rep follows up on product or delivery problems. |
Decide timing by use. Credit holds, order status and backorders should move when they happen. Sales history and balances can move once a night. Decide also who may see margin and cost: many distributors show margin to sales managers but only revenue and volume to reps.
How do you keep CRM and ERP records matched when something fails?
Match accounts on the ERP customer number, stored on the CRM account once finance approves the customer. Names fail as keys: “ABC Mechanical”, “A.B.C. Mechanical Ltd” and a branch trading name are the same customer to a rep and three customers to a sync. Before the first sync, clean both sides: merge duplicate accounts, link each CRM account to one ERP customer, and agree what happens to CRM accounts with no ERP match.
- Merges. When finance merges two ERP customers, the CRM must merge the matching accounts and keep both histories, or reps lose the record of past orders.
- Conflicting edits. If a field can be edited on both sides, it has no owner. Fix the ownership rule rather than writing a “last change wins” rule that silently overwrites one team’s work.
- Failed messages. Send every rejected record to a queue with the reason, such as a missing tax ID or an unknown price group, and give one person the job of clearing it daily.
- Retries. Use the quote ID and revision, or the source record ID, so that a retried message updates the existing record instead of creating a second one.
- Deletions. Close or deactivate records instead of deleting them, so that history and links survive.
Run these tests with copies of real accounts, quotes and orders, and write the expected result before each run:
| # | Test | Pass when | Fail signs |
|---|---|---|---|
| 1 | Convert a prospect whose name closely matches an existing ERP customer. | The request is flagged as a possible duplicate before finance creates an account. | A second ERP customer is created. |
| 2 | Accept four of six lines on a quote. | One ERP order with four lines; the other two stay visible on the quote. | The whole quote converts, or the order is keyed by hand. |
| 3 | Convert a quote after a price-list change but inside its validity date. | The order carries the quoted prices. | The order is repriced without anyone being told. |
| 4 | Retry the conversion after a timeout. | Still one ERP order. | Two orders for one quote. |
| 5 | Put the new order on credit hold. | The rep sees the hold reason and has a task within the agreed time. | The rep hears from the customer first. |
| 6 | Backorder one line. | The CRM shows the line and the new date. | The CRM shows the order as complete. |
| 7 | Finance changes the accounts payable email in the ERP. | The change stands after the next sync. | The CRM overwrites it with the old address. |
| 8 | Finance merges two ERP customers. | The CRM accounts merge and both order histories remain. | One history disappears. |
| 9 | Send an account with a missing tax ID. | It lands in the error queue with that reason, and the owner is alerted. | It fails silently, or loads without the field. |
| 10 | Compare a customer’s CRM sales summary with the ERP for last quarter. | Revenue and volume by product line agree. | Returns, credits or a merged account make the figures differ. |
Do distributors need a separate CRM if the ERP has one?
Many distribution ERPs include a CRM module, and for some businesses that removes the integration altogether. The choice depends on how sales works, not on which product has more features.
| Keep the ERP’s CRM module when | Add a separate CRM when |
|---|---|
| Most selling is inside sales and counter staff working in the ERP all day. | Field reps need mobile visit planning, routes and offline notes. |
| Quotes depend on ERP pricing, cost and stock, and reps already quote there. | The pipeline runs long, with many contacts and stages before an order. |
| Marketing is light: newsletters and trade promotions. | Marketing automation, lead scoring and campaign attribution matter. |
| A small team would struggle to own another system and its integration. | Several ERPs or companies feed one sales team that needs one customer view. |
A separate CRM adds a subscription and an integration that someone has to run, including the daily error queue. If the main reason for one is a better screen for reps, check first whether the ERP’s own CRM views or a reporting layer would do.
How do you roll out CRM and ERP integration without disrupting sales?
- 01Clean and match accounts
Merge duplicates on both sides and store the ERP customer number on every CRM account that has one.
- 02Agree owners and rules
Use the record map and the quote rules above. Name the person who clears the error queue.
- 03Send ERP facts to the CRM first
Account status, credit position, open orders and sales history. Reps get value before any order depends on the link.
- 04Connect quote to order for a pilot team
One branch or a few reps. Compare every converted quote with its ERP order daily.
- 05Add event tasks
Credit holds, backorders, overdue balances and lapsed product lines, tuned so reps act on them rather than ignore them.
- 06Expand and reconcile
Add teams in groups and keep a monthly comparison of CRM summaries with ERP sales.
For distributors whose orders also arrive by EDI, email and a buyer portal, the wholesale order management guide shows how those routes reach the same ERP order process, and the B2B customer portal guide covers the buyer-facing side of the same records. The integrations and automation service describes how Harmatiq maps and connects these systems.
Bring one real order, the systems it crosses and the exceptions your team handles manually. We can turn that journey into an implementation scope.