When Your Company Is Nine Companies: Who Owns the Customer Record?
When Your Company Is Nine Companies: Who Owns the Customer Record?

Key takeaways:

  • After acquisitions, the group runs as one company on paper while its ERPs and CRMs still behave like separate businesses.
  • There is no universal ERP-CRM integration design. The right one follows where prices are set, who approves what and where prospecting happens.
  • Four decisions decide everything: sync direction, what anchors a deal and when it is won, one standard or one per market, and what actually reaches the rep.
  • The details that break integrations live in how the ERP’s documents behave day to day, not in the specification.
  • Write down which system owns each fact, and get finance, sales and the ERP owner to agree before the build starts.

Short answer: when a group runs several ERPs and one CRM, no single system should own the whole customer record. Each field needs one owner. In most B2B groups the ERP owns pricing, credit holds, orders and invoices, while the CRM (for example HubSpot) owns deal stages, contacts and sales activity. The integration design follows from that ownership map, not the other way round.

One company on paper, nine underneath

Each business that joins brings its own ERP, its own CRM habits, its own definition of a customer. Years later, the group operates as one commercial organization on paper, while the systems underneath still behave like the separate companies they used to be.

There’s no universal answer. The right design follows how the business actually runs. Below are the four decisions every multi-ERP group has to make when connecting its ERPs to HubSpot, the options that work, and what should tip the choice. Where it helps, we share what we chose on a recent project and why, as one example rather than the rule.

  1. Where does the truth about money live? (sync direction)
  2. What anchors a deal, and when is it won? (matching key and Closed Won trigger)
  3. One standard, or one per market? (market model)
  4. What should actually reach the rep? (records and purchase history)

1. Where does the truth about money live?

In most B2B groups, the ERP, for example Microsoft Dynamics 365 Business Central, is where orders, pricing, credit and invoicing happen. The CRM is where reps prospect, log calls and manage relationships. How the two connect depends on where commercial decisions are actually made.

  • One-way, ERP to CRM. The ERP decides and the CRM displays. Fits when the ERP enforces discount approvals, credit holds or customer-creation rules that finance relies on, and a write-back would let reps bypass them.
  • Two-way, with clear field ownership. Reps create quotes in the CRM, and the ERP takes over once an order is placed. Fits when pricing is simple or controlled inside the CRM, and re-keying quotes in the ERP would slow the sale down.
  • CRM-led, ERP for fulfilment. The CRM owns the deal end to end and pushes a won order to the ERP. Fits businesses where the ERP is mainly a fulfilment and accounting engine.

On a recent multi-market project, we chose one-way because approvals, credit checks and customer creation all lived in the ERP, and the business wanted them to stay there. A company where reps price and quote in HubSpot would reasonably make the opposite call.

2. What anchors a deal, and when is it won?

The details that break integrations are rarely in the specification. They’re in how the ERP’s documents behave day to day, so the matching key has to follow that behaviour.

In Business Central, converting a quote to an order deletes the quote and carries its number forward. In that setup, keying the deal to the quote number keeps one opportunity as one deal from first quote to final order. If the ERP keeps quotes and orders as separate, linked documents, keying on the order and storing the quote reference works just as well. If deals start in the CRM, the CRM’s own deal ID can be the anchor, written back to the ERP.

The moment a deal counts as Closed Won is the same kind of choice: when the order is created, when it’s released to operations, or when it’s invoiced. The right answer is whatever the business already treats as committed revenue. On our project, orders could still be held for credit review or prepayment after entry, so we marked deals won on release.

None of this is visible on an architecture diagram. All of it comes out of an hour with the person who runs the ERP.

Connecting more than one ERP to HubSpot?

We’ll map how each market sells, approves and invoices, write down which system owns each fact, and design the sync before anyone writes a line of code. Book a free session with one of our experts.

Take HubSpot Readiness Check

Discover how ready your business is for HubSpot. Take our HubSpot Readiness Check to uncover your automation potential and get personalized next steps. It's a 7-question quizz that's done in under 30 seconds.  

3. One standard, or one per market?

When a group runs several ERP instances, connecting each as its own project is tempting. The risk is three integrations that each make sense alone and contradict each other in the CRM.

  • One shared standard, replicated per instance. One property model, one set of pipeline stages, one matching rule, built once and copied. Fits when markets sell the same products in broadly the same way.
  • A shared core with local extensions. Common definitions for companies, deals and stages, plus market-specific fields or steps where a market genuinely works differently.
  • Separate setups. Occasionally right, when business units truly don’t share customers, reps or reporting.

What matters most is that the choice is deliberate and written down before the build starts. A pipeline stage that quietly means different things in different markets makes every group-level report a guess.

4. What should actually reach the rep?

  • Customers only. Fits when the customer list is closed and prospecting already happens in the CRM.
  • All the companies reps sell to, prospects included. Fits when reps create prospects in the ERP first, so syncing only billed customers would hide most of their work. Bringing the people at each company across too lets reps log calls against real contacts.

Purchase history is its own decision:

  • A link to the reporting layer. Light and always current, best when reps just need to look.
  • Summary properties on the record, such as last order date or top product line. Best when marketing needs to segment on them.
  • Full transaction sync. Only when the CRM genuinely needs every line, and the storage and maintenance cost is accepted up front.

A quick reference: six ERP-HubSpot integration decisions

  • Sync direction - one-way, two-way or CRM-led. Tipped by where approvals and pricing are enforced.
  • Deal anchor - quote number, order number or CRM deal ID. Tipped by how the ERP’s documents change through the cycle.
  • Closed Won trigger - order created, released or invoiced. Tipped by what finance treats as committed revenue.
  • Market model -one standard, shared core or separate. Tipped by how differently each market sells.
  • Records synced - customers only or all companies. Tipped by where prospecting happens.
  • Purchase history - link, summary properties or full sync. Tipped by who needs it, and for what.

Start with how the business runs

Before choosing a connector or writing a line of code, map how the business actually sells, approves and invoices in each market. Then write down which system owns each fact, and get finance, sales and the ERP owner to agree. The right integration isn’t the one in someone else’s case study. It’s the one that matches how your business already works.

Once it’s live, someone has to own it, too. We cover that in Your CRM Integration Has a Resignation Date, and you can see how we approach CRM implementation and integrations end to end.

Frequently asked questions

Which system should own the customer record in an ERP and HubSpot integration?

Neither system should own the whole record. Assign an owner per field: typically the ERP owns pricing, credit holds, orders and invoices, and HubSpot owns deal stages, contacts and sales activity. Document that map and get finance, sales and the ERP owner to sign off before the build.

Should an ERP-HubSpot sync be one-way or two-way?

Choose one-way (ERP to CRM) when the ERP enforces approvals, credit checks or customer-creation rules that a write-back would bypass. Choose two-way with clear field ownership when reps quote in the CRM and pricing is simple or controlled there. Choose CRM-led when the ERP is mainly a fulfilment and accounting engine.

When should a HubSpot deal be marked Closed Won if orders come from the ERP?

Use whatever the business already treats as committed revenue: order created, order released to operations, or order invoiced. If orders can still be held for credit review or prepayment after entry, marking deals won on release is usually more accurate than on creation.

How do you connect several ERP instances to one HubSpot portal?

Decide the market model first: one shared standard replicated per instance, a shared core with local extensions, or separate setups. Building each connection as an isolated project risks integrations that each make sense alone but contradict each other in the CRM and break group-level reporting.

Should ERP purchase history sync into HubSpot?

Only as much as someone needs. A link to the reporting layer suits reps who just need to look; summary properties such as last order date suit marketing segmentation; full transaction sync is justified only when the CRM needs every line and the storage and maintenance cost is accepted.